APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma imagem distribuída pode transportar mais do que o código pretendido. Passar credenciais por argumentos ou variáveis persistentes de build é inadequado; secret mounts permitem disponibilizar o segredo temporariamente à instrução que o necessita. Isso não dispensa evitar que o próprio comando o copie para ficheiros ou logs. Se uma credencial já foi exposta, corrigir o Dockerfile não a revoga. A resposta deve tratar validade, consumidores, cópias e uso anterior. Distingue prevenir nova inclusão de resolver uma exposição existente. Um novo tag aponta para outra imagem, mas não apaga automaticamente cópias antigas nem reduz as permissões do token divulgado.
Aplicação guiada
Num pipeline fictício, coordena substituição do token com os consumidores, limita o alcance e examina registos de uso. Regista que imagens e runners tiveram acesso para orientar limpeza e investigação. Na execução, um contentor não fica isolado por definição: privileged e hostPath podem conceder acesso desnecessário ao nó. Se a aplicação não precisa dessas capacidades, remove-as e valida o funcionamento sob uma política adequada. Limites de memória e nomes de namespace não substituem esse controlo. O handover deve incluir o processo de rotação, localização dos segredos, permissões do runtime e critérios para aceitar exceções. Assim, APS consegue manter a configuração depois da entrega.
Código corrigido, token válido e imagem antiga acessível: a exposição continua por tratar.
Armadilhas comuns
Tag como eliminação; secret mount como impossibilidade de fuga; namespace como isolamento suficiente; recursos como privilégios.
Tópicos relacionados: Âmbito, autorização e relatório de risco · Reconhecimento e limites da observação · Sistemas, vulnerabilidades e evidência
Controla o ciclo de vida do segredo e as capacidades de execução.
Referência: Docker build secrets · CEH 312-50, Exam Blueprint v5.0 effective2024-04-10; Candidate Handbook v7.3 (2026-09-21)