Deployment & Infra
Secrets at deploy: multiple-choice review
Crux Multiple-choice synthesis across the secrets-at-deploy unit: image hygiene, base64 vs encryption, etcd at rest, injection style, sealed secrets, and rotation.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a real call you make at deploy time — not a definition to recite, but a threat model to reason through under audit.
Goal
Confirm you can connect image hygiene, the base64 trap, etcd encryption, injection style, sealed secrets, and rotation into one coherent stance on where a secret enters and where it leaks.
Quiz
Completed
A Dockerfile sets ENV API_KEY=sk-live-abc in an early layer, then a later layer runs `unset API_KEY`. Is the key safe in the pushed image?
Heads-up Runtime env state and on-disk layers are different things. The build-time ENV is baked into a layer that survives in the registry regardless of what a later layer does at runtime.
Heads-up There is no automatic squash, and even a squashed image leaks if the build cache or intermediate layers are pulled. The rule is never to put the secret in the build at all.
Heads-up Anyone with registry read access pulls and replays layers. Private registries still leak to every account, CI job, and cached node that can pull the image.
Quiz
Completed
A teammate insists the cluster is safe because every Kubernetes Secret value is base64-encoded. What is the precise correction?
Heads-up base64 is fully reversible, not a hash. Anyone with the encoded string trivially gets the plaintext back.
Heads-up Encoding and encryption are separate. The base64 value sits unencrypted in etcd by default; no cluster key is applied unless you configure encryption at rest.
Heads-up base64 stops nothing. There is no key and no work factor; reversing it is a single command, so it offers zero confidentiality even against casual access.
Quiz
Completed
You configure an EncryptionConfiguration so the API server encrypts Secrets at rest in etcd. An auditor still finds an old Secret in plaintext in an etcd backup. Why, and what was missed?
Heads-up New Secrets written after the change are encrypted; the gap is specifically the pre-existing values, which are never touched until rewritten.
Heads-up Encryption at rest means the API server encrypts before writing to etcd, so a backup of encrypted Secrets is ciphertext. The plaintext here is leftover unconverted data.
Heads-up base64 is just the encoding of the value field; it does not interact with or override the etcd encryption-at-rest layer.
Quiz
Completed
An error tracker shows a live DB password indexed in plaintext inside a stack trace. The secret was injected as an environment variable. What is the root cause and the structural fix?
Heads-up Capturing process state on error is intended SDK behaviour, not a bug. As long as the secret lives in the environment, any crash-state capture can leak it.
Heads-up Length is irrelevant. The leak comes from env being global, inherited, and dumped on crash — a file you read once and never re-export avoids all three.
Heads-up Deny-lists are brittle band-aids that miss renamed or nested keys. The structural fix is to keep the secret out of the environment entirely via a file mount.
Quiz
Completed
A small GitOps team must commit secret config to a private repo so Argo CD can apply it, and they want minimal external dependencies. Which approach is correct, and why is it genuinely safe to commit?
Heads-up base64 is encoding, not encryption. Anyone with repo read access runs base64 -d and reads the plaintext; forks and history make the leak irreversible. This is the exact trap the unit opens with.
Heads-up A ConfigMap is plaintext by design and meant for non-sensitive config. Committing secrets there is strictly worse than a base64 Secret — no encoding, no encryption, no access separation.
Heads-up ESO is excellent at scale but adds an external manager the team did not ask for, and it does not put a self-contained committable artifact in the repo. Heavier than the prompt needs.
Quiz
Completed
Security wants secrets rotated every 30 days, and they want a stolen credential to be useless fast. You run on Kubernetes with Vault available. What pairing best meets both goals?
Heads-up Env vars are frozen at container start, so rotation needs a restart, and a static 30-day credential is fully valid for 30 days if stolen. Neither goal is met well.
Heads-up Faster rotation of a static long-lived secret shrinks the window, but a stolen credential is still valid until the next rotation. Dynamic short-lived creds remove the long-lived secret entirely.
Heads-up Encryption at rest protects stored Secrets from etcd theft; it does nothing about rotation cadence or limiting the lifetime of a leaked credential.
Recap
The through-line of the unit is one decision path: the secret enters at deploy or runtime (never in the image), it must be genuinely encrypted rather than base64-encoded, etcd needs encryption at rest configured and existing Secrets rewritten, file mounts beat env vars on leak surface and in-place rotation, Sealed Secrets make a committable GitOps artifact, and dynamic short-lived credentials make a stolen secret expire before it is useful. Every wrong answer here is a real incident someone has already lived through.