Secrets & Hot Reload — Series 2

Preview — 3 of 10 questions

What determines whether a secret can be rotated while the process runs?

javascript

Candidates: DATABASE_PASSWORD, JWT_SIGNING_KEY, STRIPE_API_KEY, REDIS_URL

AOnly secrets shorter than 256 bytes can be swapped in place

BAny secret can rotate live, since ConfigService re-reads the environment on each get()

CNone can: every rotation requires a restart, which is why rolling deploys exist

DWhether the consumer re-reads it. An API key passed per request rotates trivially if the client reads it each time; a connection string captured when a pool was built does not, unless the pool is rebuilt — and a signing key needs an overlap period, since tokens signed with the old key must stay verifiable until they expire

Why encrypt with a data key rather than calling KMS for every value?

javascript

KMS holds the key-encryption key.
Each secret is encrypted with a generated data key, which is itself
encrypted by KMS and stored alongside the ciphertext.

ABulk data is encrypted locally with the data key, so KMS is called once per data key rather than once per value — bounding latency and API cost — while the key-encryption key never leaves KMS, so rotating it means re-wrapping data keys rather than re-encrypting all the data

BBecause KMS cannot decrypt payloads larger than one kilobyte, making direct encryption impossible in every case

CBecause data keys are stored in plaintext, which is required for fast startup

DBecause envelope encryption removes the need to protect the data key at all

What is the honest assessment of this approach?

javascript

secrets.enc.yaml committed to git, decrypted at deploy time with a KMS key

AIt is equivalent to a secret manager in every respect, with the repository acting as the store

BIt is unsafe under all circumstances, because ciphertext in a public history can eventually be broken

CIt gives secrets the review, history and rollback properties of code, and keeps a GitOps workflow self-contained — at the cost that rotation requires a commit and a deploy, that the ciphertext is permanently public to anyone with repository access, and that access control is coarser than a secret manager's per-secret policies

DIt is preferable to a secret manager because it removes a runtime dependency, with no meaningful downside

Answer all 10 questions (7 more), see explanations for every answer, and track your score.