A civic open-data exporter embeds database passwords in Dockerfile ENV and COPY layers. What should the team do instead?
Select an answer to reveal the explanation.
Short Explanation
Baking passwords into image layers is like writing the vault combo on the outside of the moving box—anyone who gets the box can read it. Keep images clean and hand credentials in at runtime with Kubernetes Secrets (or non-sensitive ConfigMaps).
Full Explanation
Civic open-data exporters must not embed database passwords in Dockerfile ENV or COPY layers. Image layers are widely cached and often readable by anyone who can pull the image, so credentials baked at build time leak. Remove secrets from the image entirely and inject them at runtime with Kubernetes Secrets (and non-sensitive config via ConfigMaps) as environment variables or mounted files. That keeps the exporter image portable across environments while rotating credentials without rebuilding.
Base64-encoding passwords in the Dockerfile fails because base64 is encoding, not encryption; layers remain trivially recoverable. Committing passwords only into :latest while keeping digests clean still ships secrets in mutable tags and encourages latest misuse. Storing passwords in Deployment annotation labels fails confidentiality: annotations are visible to many API readers and are not the Secret API.
Exam caveat: CKAD distinguishes build-time image content from runtime configuration. Prefer Secret volumes or envFrom for credentials; never treat ConfigMaps as a safe place for passwords.
Operational check: scan the image (docker history, trivy, or dive) for leftover credential strings; deploy with a Secret mount; kubectl exec only in a break-glass debug context to confirm env files exist without appearing in the image config.