m/Assistant
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

security: load Creator secrets from files
CI / test (pull_request) Successful in 10s
Details
CI / test (push) Successful in 10s
Details

Browse Source
This commit was merged in pull request #1.
This commit is contained in:
m
2026-08-16 17:57:32 +03:00
parent e9594306e5
commit 03dde8c196
7 changed files with 190 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/CREDENTIALS_AND_SECRETS.md
+2
View File
@@ -20,3 +20,5 @@ Do not guess Portainer credentials and do not search other project source trees
## Production services
Each privileged runtime gets only its required secret/capability bindings. `commit-runtime` is intentionally isolated from the general Core Runtime.
Creator authentication secrets are stored in the external Docker volume `assistant_core_secrets` and mounted read-only only at `/run/secrets` in `core-runtime`. The production container environment contains `_FILE` paths, not the secret values. Files are owned by runtime uid 100/gid 101 with mode 0400. `CREATOR_USERNAME` is not secret and remains an environment value. Development may continue to use direct environment values, but a direct value and its matching `_FILE` setting must never be configured together.
docs/DEPLOYMENT.md
+2
View File
@@ -18,6 +18,8 @@ Credentials/API deployment automation is deliberately not embedded. Use `PORTAIN
The single Creator login is configured with external `CREATOR_USERNAME` and `CREATOR_PASSWORD` values. They issue the same bounded Creator session and never select Actor, Principal, Scope or Authority. Keep `CREATOR_BOOTSTRAP_TOKEN` as a separate recovery/automation credential; none of these values belongs in Git, compose defaults for production, image layers or logs.
In production, `CREATOR_PASSWORD`, `CREATOR_BOOTSTRAP_TOKEN`, and `CREATOR_SESSION_SIGNING_KEY` are materialized as files in the external `assistant_core_secrets` Docker volume. `core-runtime` receives only the corresponding `_FILE` paths and mounts that volume read-only. Direct environment values remain a development compatibility path and fail closed if combined with `_FILE`.
## PostgreSQL recovery
Production backups run only on `docker.cin.su`; this project must not use the shared `docker-test` host. `deploy/backup-postgres.sh` creates an atomic, mode-0600 logical backup under `/home/m/assistant-backups/postgres`. Each completed directory contains the application database, cluster roles without role passwords, database/owner metadata, and `SHA256SUMS`. Partial output is never promoted to a completed backup directory, and no automatic retention deletion is performed.