Secrets Management
Tiffin talks to a payment provider, a database, an email service and a container registry. Each one needs a password, token or key: a secret. Where those secrets live decides whether one mistake is a shrug or a breach. The answer is never "in the code".
The rule
Store secrets centrally, inject them late, rotate them often, scan for leaks.
- Store centrally. Keep secrets in a secrets manager, such as HashiCorp Vault or your cloud's secrets service, not in code, config files, container images or chat. Every read is access-controlled and logged.
- Protect the keys with a KMS. A key management service holds master keys that never leave it; you ask it to encrypt, decrypt or sign. Big data is protected by envelope encryption: a data key encrypts the data, and the KMS master key encrypts the data key.
- Inject late. The app or pipeline job fetches the secret at runtime using its own identity. Many CI systems can swap a short-lived identity token (OIDC) for cloud credentials that expire within the hour, so there is no long-lived key to steal.
- Rotate. Change secrets on a schedule and immediately after any suspected leak. Automated rotation makes this routine instead of scary.
- Scan. Run a secret scanner as a pre-commit hook and in the pipeline, because someone will eventually paste a key.
deploy:
permissions: { id-token: write } # job gets a short-lived identity
steps:
- run: cloud-login --oidc --role tiffin-deploy
- run: deploy --db-password-from secrets://tiffin/prod/dbThe shortcut
Follow one secret's life and check each stop: where is it stored, who can read it, how long does it live, what if it leaks?
Stored
In the secrets manager at
tiffin/prod/payments, encrypted under a KMS key. Not inconfig.py.
The biggest trap: deleting a leaked secret in a new commit and calling it fixed. Git keeps every earlier version. A secret that touched a repository is compromised; rotate it.
Drills
Answer fast — trust the rule.
A token was committed and then removed in the next commit. What must happen first?
What is a key management service mainly for?
Tiffin's Dockerfile has ENV DB_PASSWORD=hunter2. Why is this a problem?
Why is a short-lived OIDC credential for the deploy job better than a stored cloud key?
In envelope encryption, what does the KMS master key encrypt?
Remember
- Store centrally, inject late, rotate often, scan for leaks.
- Trace a secret: stored where, read by whom, lives how long, what if it leaks?
- A secret that touched Git is compromised; rotate it before anything else.