Configuration, passwords and Vault

01

1. What belongs in .env

• Service URL, mode selection, time zone, database names, and other non-secret parameters.
• Full image reference with digest if the file is a release-controlled component.
• Feature switches that the release explicitly supports and validates.
• Never put your actual password, private key, access token, client secret, or registry login in a Git versioned file.

02

2. Recommended layout on the host

/etc/sifybox/
├── env/
│   ├── release.env       # image + digest, bez hesel
│   └── site.env          # URL, režimy a nesekretní parametry
└── secrets/              # root:root, adresář 0700, soubory 0400
    ├── db_password
    └── oidc_client_secret

Note: The .env file is not a secret manager. Login to the registry is handled by a credential helper or a managed docker login with a deploy token; the Compose secret itself does not authorize image downloads. Sensitive values ​​remain outside of Git, with minimal permissions and the rotation described.

03

3. Docker secrets variant

Target standard — filenames and support for _FILE variables must be confirmed by the manifest of a specific release.

1. DERS will provide a list of expected secrets and a confirmed method for retrieving them.
2. The administrator creates each secret outside of checkout and sets ownership and permissions.
3. Compose will only attach a secret to the service that needs it.
4. The application must not print the value at startup or upon validation error.
5. The rotation is performed according to the service runbook and verified by a new login or connection.

04

4. HashiCorp Vault Variant

Target standard — the method of authentication, lease renewal, and reload must be confirmed by the specific service and release.

1. The service or Vault Agent authenticates with a machine identity tied to a specific environment; it does not use a shared personal token.
2. The policy will only allow specific paths and operations needed for a given service.
3. The Vault Agent writes the secret to a tmpfs file or provides it to the application through a supported mechanism.
4. Restoring short-term data will trigger a supported reload or controlled restart.
5. Vault audit, application audit, and operational logs are correlated without writing the secret value itself.

05

5. Order of loading and validation

1. Load default values ​​built into the release for non-secret options only.
2. Load release.env and site.env.
3. Take secrets from files or Vault; the secret value never has a secure universal default.
4. If a mandatory value is missing, end before starting with the parameter name, not its content.
5. Print a sanitized configuration summary: mode, target URL, version, and secret source, but not the secret.
6. Run connectivity tests and only then accept operational requirements.

06

6. Rotation without manual rewriting

• Each secret has an owner, source, expiration date, and recovery method.
• Dynamic Vault data has a lease and automatic renewal.
• OIDC client secrets are changed by overlaying the old and new values, if supported by the IdP and application.
• Emergency rotation has its own procedure and is independent of the person who originally performed the installation.
• After rotation, the service function and audit are verified; the old value is invalidated only after confirmation.