Seus contêineres são seguros o suficiente para produção?Os contêineres fornecem excelente isolamento entre aplicativos, mas configurações incorretas, imagens vulneráveis e configurações de tempo de execução inseguras podem transformar os contêineres de uma vantagem de segurança em uma desvantagem. Este guia aborda as práticas de segurança exigidas pelos ambientes de contêiner de produção.
Principais conclusões
- Comece com imagens mínimas:As imagens Distroless e Alpine reduzem a superfície de ataque em 90% em comparação com imagens completas do sistema operacional.
- Digitalize em todas as etapas:Crie, envie, implante e continuamente no registro. As vulnerabilidades são descobertas após a implantação.
- Nunca execute como root:Os contêineres raiz podem escapar para o host. Os contêineres não-raiz são contidos mesmo se comprometidos.
- Sistemas de arquivos somente leitura:Se o contêiner não precisar gravar, torne o sistema de arquivos somente leitura para evitar a persistência do malware.
- O monitoramento de tempo de execução detecta o que a varredura deixa passar:Explorações de dia zero, ataques à cadeia de suprimentos e ameaças internas exigem detecção em tempo de execução.
Segurança de imagem
Use imagens de base mínimas
Cada pacote em uma imagem de contêiner é uma superfície de ataque potencial. Uma imagem típica do Ubuntu contém mais de 100 pacotes; uma imagem sem distribuição contém apenas o tempo de execução do aplicativo. Use o Google Distroless para aplicativos Java, Python, Node.js e Go. Use Alpine (5 MB) quando precisar de um shell para depuração. Nunca use imagens completas do sistema operacional (Ubuntu, Debian, CentOS) em produção — elas contêm centenas de pacotes desnecessários com vulnerabilidades conhecidas.
Construções em vários estágios
Use Dockerfiles de vários estágios para separar dependências de compilação de imagens de tempo de execução. O estágio de construção inclui compiladores, gerenciadores de pacotes e ferramentas de desenvolvimento. O estágio final contém apenas o aplicativo compilado e dependências mínimas de tempo de execução. Isso evita que ferramentas de construção (que geralmente possuem CVEs de alta gravidade) apareçam em imagens de produção.
Pipeline de digitalização de imagens
- Tempo de construção:Faça a varredura no pipeline CI antes de enviar para o registro. Bloqueie compilações com vulnerabilidades críticas.
- Registro:A varredura contínua em ECR, ACR ou Harbour captura CVEs recém-descobertos em imagens existentes.
- Entrada:Os controladores de admissão Kubernetes verificam os resultados da varredura de imagem antes de permitir a implantação.
- Tempo de execução:Monitore o comportamento anômalo do contêiner que pode indicar a exploração de vulnerabilidades não corrigidas.
Segurança em tempo de execução
Endurecimento de recipientes
| Configuração | Valor recomendado | Por que |
|---|
| runAsNonRoot | verdade | Impede o escape do contêiner por meio de privilégios de root |
| readOnlyRootFilesystem | verdade | Impede que malware grave no sistema de arquivos |
| permitirPrivilegeEscalação | falso | Impede que processos obtenham privilégios adicionais |
| capacidades | soltar: ["TODOS"] | Remove todos os recursos do Linux, adiciona apenas o que é necessário |
| seccompProfile | Tempo de execuçãoPadrão | Restringe chamadas de sistema disponíveis para o contêiner |
| recursos.limites | Definir CPU e memória | Previne o abuso de recursos (mineração de criptografia, DoS) |
Monitoramento de tempo de execução com Falco
A Falco monitora o comportamento dos contêineres em relação às regras de segurança e alertas sobre violações. As regras padrão detectam: shell gerado dentro de um contêiner, acesso a arquivos confidenciais (/etc/shadow, /etc/passwd), conexões de rede inesperadas, tentativas de escalonamento de privilégios, execução do gerenciador de pacotes em contêineres de produção e processos de mineração de criptografia. Regras personalizadas podem ser adicionadas para o comportamento específico do seu aplicativo.
Segurança da cadeia de abastecimento
Assinatura e verificação de imagem
Assine imagens de contêiner no momento da construção usando cosign (Sigstore) ou Docker Content Trust. Verifique as assinaturas na implantação por meio de controladores de admissão Kubernetes. Isso garante que apenas as imagens criadas pelo pipeline CI/CD possam ser implantadas, evitando ataques à cadeia de suprimentos em que os invasores enviam imagens maliciosas para o seu registro.
Lista de materiais de software (SBOM)
Gere SBOMs para cada imagem de contêiner usando Syft ou Trivy. Um SBOM lista todos os componentes (pacotes de sistema operacional, bibliotecas, dependências) da imagem. Quando uma nova vulnerabilidade é divulgada, você pode identificar imediatamente quais imagens foram afetadas sem precisar verificar tudo novamente. Os SBOMs são cada vez mais exigidos por regulamentações e clientes empresariais.
Como Opsio protege contêineres
- Pipeline de imagem:Implementamos verificação, assinatura e aplicação de políticas em todo o ciclo de vida da imagem do contêiner.
- Segurança de tempo de execução:Implantamos e gerenciamos Falco/Sysdig para monitoramento contínuo do tempo de execução do contêiner.
- Kubernetes endurecimento:Reforçamos as configurações de cluster de acordo com os benchmarks do CIS com monitoramento contínuo de conformidade.
- Resposta ao incidente:Nossa equipe SOC responde a incidentes de segurança de contêineres com capacidade de contenção e perícia.
Perguntas Frequentes
Os contêineres são mais seguros que as VMs?
Os contêineres fornecem isolamento em nível de processo por meio de namespaces e cgroups Linux, enquanto as VMs fornecem isolamento em nível de hardware por meio de hipervisores. As VMs têm limites de isolamento mais fortes. Os contêineres oferecem implantação mais rápida e superfície de ataque menor (ao usar imagens mínimas). Na prática, os contêineres configurados corretamente com monitoramento de segurança em tempo de execução são seguros o suficiente para a maioria das cargas de trabalho de produção. Cargas de trabalho altamente confidenciais podem se beneficiar do isolamento de nível VM ou do sandbox de contêiner (gVisor, Kata Containers).
Qual é o maior risco de segurança de contêineres?
Executando contêineres como root com recursos irrestritos. Um contêiner raiz com todos os recursos pode escapar para o sistema host, acessando outros contêineres, recursos do host e, potencialmente, o servidor Kubernetes API. A correção é simples: defina runAsNonRoot: true, elimine todos os recursos e use sistemas de arquivos somente leitura. Essas três configurações eliminam a maior parte dos riscos à segurança do contêiner.
Como lidar com segredos em contêineres?
Nunca grave segredos em imagens de contêiner ou passe-os como variáveis de ambiente (visíveis em listagens e logs de processos). Use gerenciamento de segredos externo: HashiCorp Vault com injeção lateral, AWS Secrets Manager com integração ECS/EKS ou Azure Key Vault com driver CSI. Os segredos devem ser injetados em tempo de execução e armazenados apenas na memória, nunca no disco.
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
