Como os segredos do Docker funcionam e onde os desenvolvedores os usam indevidamente
Os segredos do Docker foram introduzidos para gerenciar com segurança dados confidenciais, como chaves de API, senhas de banco de dados e tokens. Eles funcionam montando segredos como arquivos em /executar/segredos dentro de um contêiner, acessível apenas ao serviço em contêiner. Esse mecanismo mantém segredos fora das variáveis de ambiente e logs, pelo menos em teoria. O problema começa quando os desenvolvedores ignoram esse mecanismo. Em vez de usar os segredos do Docker Compose apresentam adequadamente, os segredos são frequentemente codificados em dockerfile, committados ao Git ou injetados por meio de variáveis de ambiente. Esses atalhos tornam os segredos vulneráveis à exposição acidental por meio de logs, camadas de contêiner ou histórico de versões.
# Risky
ENV DB_PASSWORD=mysecretpassword
⚠️ Exemplo inseguro, não usar em produção
Uma vez adicionada, esta linha é inserida na imagem. Qualquer pessoa com acesso à imagem (cache de compilação, registro ou CI/CD logs) podem extraí-lo. Pior ainda, esse padrão muitas vezes passa despercebido durante as análises porque "simplesmente funciona".
Segredos do Docker Compose e os riscos ocultos em configurações compartilhadas
O Docker Compose simplifica aplicativos multicontêineres, mas Segredos do Docker Compose vêm com riscos ocultos. Os desenvolvedores geralmente compartilham Docker Compose.yml or .env arquivos entre equipes e ambientes, via Git, Slack ou unidades compartilhadas.
services:
app:
image: myapp
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt
⚠️ Exemplo demonstrativo, não inclua segredos reais em arquivos versionados
O problema? Estes Docker Compose segredos! As referências pressupõem arquivos locais, mas, na prática, esses arquivos são versionados ou distribuídos de forma insegura. Segredos se infiltram em repositórios do Git, aparecem em pull requests, ou ser copiado para outras pastas. A suposição de que “todos nós sabemos que não devemos commit “segredos” não é uma política de segurança.
Pior, ambientes como preparação e produção podem reutilizar o mesmo docker-compose.yml, criando uma falsa sensação de separação. Um mal configurado .env arquivo e segredos de produção são injetados em um ambiente de teste.
CI/CD Pipelines: Onde o tratamento secreto do Docker falha
In CI/CD, Segredos do Docker desmoronar se não for isolado. Segredos muitas vezes vazam em três lugares: logs, camadas de imagem e corredores compartilhados.
Logs:Impressão de etapas do CI eco $CHAVE_SECRETA para depurar problemas. Mas esses logs são armazenados, às vezes publicamente. Ferramentas como Ações do GitHub or GitLab armazenar registros por dias ou semanas.
Camadas de imagem: Se um Dockerfile adicionar um segredo durante a compilação:
RUN echo "$SECRET_KEY" > /app/config.txt
⚠️ Exemplo inseguro, isso expõe segredos em camadas de imagem
Aquele Segredo do Docker agora faz parte de uma camada de imagem. Mesmo que você exclua o arquivo posteriormente, a camada anterior permanece no histórico da imagem.
Corredores Compartilhados: Vários CI/CD Plataformas usam executores compartilhados. Se os segredos não forem devidamente delimitados ou limpos, outras compilações poderão acessá-los. Pior ainda, os segredos às vezes são passados como variáveis de ambiente para todas as etapas por padrão.
Protegendo o Docker no código, Pipelines e Registros
Para bloquear Segredos do Docker, as equipes de desenvolvimento precisam de defesas em camadas:
- Use gerenciadores secretos como AWS Secrets Manager, HashiCorp Vault ou Doppler. Essas ferramentas rotacionam e injetam segredos com segurança em seus contêineres em tempo de execução.
- Limitar escopos: Nunca exponha segredos de produção em ambientes de desenvolvimento/teste. Use o controle de acesso baseado em funções (RBAC) para restringir quem pode injetar ou ler segredos.
- Evite variáveis ENV para segredos. Usar Segredo do Docker volumes ou montar segredos como arquivos explicitamente.
- Limpar compilações: Certifique-se de que os segredos não sejam incorporados às imagens ou deixados em arquivos intermediários.
- Escanear contêineres e repositórios: Use ferramentas que inspecionam imagens, histórico do git e CI/CD configurações para segredos vazados.
Melhores práticas para evitar a exposição de segredos do Docker
- Segredos efêmeros: Gere segredos únicos durante execuções de CI. Eles expiram e não podem ser reutilizados se forem roubados.
- Segredos selados: Use Kubernetes Sealed Secrets ou SOPS para criptografar segredos no Git. Isso garante que os segredos sejam versionados com segurança.
- CI/CD políticas: Aplicar políticas como sem segredos no Dockerfile, o bloco se baseia na detecção de segredos e no uso de logs de Segredos do Docker para pipeline.
- Pre-commit hooks: Quadra commits com segredos usando ferramentas como segredos do git or detectar-segredos.
- Infraestrutura imutável: Não modifique segredos em contêineres. Reconstrua e reimplante com novos Segredos do Docker ao invés.
Conclusão
Quando mal utilizado, Segredos do Docker tornar-se uma responsabilidade em vez de um recurso de segurança. De Segredos do Docker Compose vazando através de arquivos YAML para CI/CD pipelineAo expor segredos em logs ou camadas, os riscos são reais e evitáveis.
Usando ferramentas como Xygeni, as equipes podem detectar pessoas expostas segredos! cedo, aplicar políticas de tratamento secreto e verificar desvios de segurança em códigos, contêineres e pipelines. Trate seu Dsegredo ocker estratégia como infraestrutura crítica. Proteja-a como você realmente quer.
