LEARN. PRACTICE. GROW.Concept and mechanism
A distributed image can carry more than intended code. Passing credentials through persistent build arguments or variables is unsuitable; secret mounts make a secret temporarily available to the instruction needing it. This does not remove the need to prevent the command itself copying it into files or logs. If a credential has already been exposed, fixing the Dockerfile does not revoke it. Response should address validity, consumers, copies, and earlier use. Distinguish preventing new inclusion from resolving existing exposure. A new tag points to another image but does not automatically erase old copies or reduce the disclosed token’s permissions.
Guided application
In a fictional pipeline, coordinate token replacement with consumers, limit scope, and inspect usage records. Record which images and runners had access to guide cleanup and investigation. At runtime, a container is not isolated by definition: privileged and hostPath can grant unnecessary node access. If the application does not need those capabilities, remove them and validate operation under suitable policy. Memory limits and namespace names do not replace that control. Handover should include rotation process, secret locations, runtime permissions, and exception acceptance criteria. APS can then maintain the configuration after delivery.
Fixed code, valid token, and accessible old image: exposure still needs treatment.
Common pitfalls
Tag as deletion; secret mount as impossible leakage; namespace as sufficient isolation; resources as privileges.
Related topics: Scope, authorization, and risk reporting · Reconnaissance and observation limits · Systems, vulnerabilities, and evidence
Control secret lifecycle and execution capabilities.
Reference: Docker build secrets · CEH 312-50, Exam Blueprint v5.0 effective2024-04-10; Candidate Handbook v7.3 (2026-09-21)