O seu cluster Kubernetes está seguro ou apenas em execução?As configurações padrão Kubernetes priorizam a facilidade de uso em vez da segurança. Sem proteção deliberada, os clusters ficam vulneráveis a fugas de contêineres, escalonamento de privilégios, movimentação lateral e roubo de dados. Esta lista de verificação abrange todos os controles de segurança que você precisa implementar em ambientes de produção Kubernetes.
Principais conclusões
- O padrão Kubernetes não é seguro:Configurações prontas para uso permitem contêineres privilegiados, acesso irrestrito à rede e amplas permissões de servidor API.
- RBAC é sua primeira defesa:Restrinja o acesso ao servidor API ao mínimo necessário para cada conta de serviço e usuário.
- As políticas de rede impedem o movimento lateral:Sem políticas de rede, cada pod pode se comunicar com todos os outros pods — uma rede plana dentro do seu cluster.
- Os padrões de segurança do pod substituem o PSP:A Admissão de Segurança do Pod (PSA) impõe restrições de segurança em todos os pods.
- A segurança da cadeia de abastecimento é importante:Verifique a proveniência da imagem, procure vulnerabilidades e aplique políticas de imagem por meio do controle de admissão.
Kubernetes Lista de verificação de segurança
API Segurança do Servidor
- Habilite o RBAC e desabilite a autenticação anônima
- Use autenticação forte (OIDC, baseada em certificado) — não autenticação básica ou tokens estáticos
- Restringir o acesso do servidor API a intervalos de IP conhecidos (gerenciado Kubernetes: usar redes autorizadas)
- Habilite o registro de auditoria para todas as solicitações do servidor API
- Desativar recursos alfa/beta em clusters de produção
- Configurar controladores de admissão: PodSecurity, ResourceQuota, LimitRange
Melhores práticas de RBAC
- Siga o privilégio mínimo: sem ligações ClusterAdmin para contas de serviço
- Use funções com namespace em vez de ClusterRoles sempre que possível
- Audite o RBAC regularmente com ferramentas como kubectl-who-can e rbac-lookup
- Nunca conceda permissões curinga (verbos: ["*"], recursos: ["*"])
- Restrinja o acesso aos segredos — conceda get/list em segredos apenas aos pods que precisam deles
- Use contas de serviço separadas por aplicativo (não a conta de serviço padrão)
Segurança de Rede
- Implementar NetworkPolicies de negação padrão em todos os namespaces
- Permitir apenas o tráfego de entrada e saída necessário por aplicação
- Use um CNI que suporte NetworkPolicies (Calico, Cilium, Antrea)
- Criptografe a comunicação entre pods com service mesh mTLS (Istio, Linkerd)
- Restringir a saída a endpoints externos conhecidos (evitar a exfiltração de dados)
- Isole cargas de trabalho confidenciais em namespaces dedicados com políticas rígidas
Segurança do pod
- Ativar a admissão de segurança do pod no nível do namespace (impor perfil "restrito")
- Execute contêineres como não-root (runAsNonRoot: true)
- Use sistema de arquivos raiz somente leitura (readOnlyRootFilesystem: true)
- Elimine todos os recursos, adicione apenas o que for necessário (descarte: ["ALL"])
- Desativar escalonamento de privilégios (allowPrivilegeEscalation: false)
- Defina limites de recursos (CPU, memória) em todos os contêineres para evitar abuso de recursos
- Não monte o token da conta de serviço, a menos que seja necessário (automountServiceAccountToken: false)
Segurança de imagem
- Verifique todas as imagens em busca de vulnerabilidades antes da implantação (Trivy, Snyk)
- Use imagens de base mínimas (sem distribuição, Alpine) para reduzir a superfície de ataque
- Assinar imagens de contêineres e verificar assinaturas na admissão (fiança, Notação)
- Permitir apenas imagens de registros confiáveis (aplicar por meio de controle de admissão)
- Nunca use a tag :latest — fixe em resumos de imagens específicos para reprodutibilidade
- Reconstrua e atualize regularmente as imagens base para incorporar patches de segurança
Gestão de Segredos
- Não armazene segredos em variáveis de ambiente ou ConfigMaps
- Use gerenciamento de segredos externo (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Se estiver usando segredos Kubernetes, habilite a criptografia em repouso (EncryptionConfiguration)
- Alterne segredos regularmente com rotação automatizada por meio de operadores secretos externos
- Restringir o acesso do RBAC aos segredos — a maioria dos pods não deve ser capaz de listar todos os segredos
Monitorização e Detecção
- Habilite o log de auditoria Kubernetes e encaminhe para SIEM
- Implantar monitoramento de segurança em tempo de execução (Falco, Sysdig)
- Monitore: execução inesperada de processos, conexões de rede, modificações de arquivos, escalonamento de privilégios
- Alerta sobre: nova criação de ClusterRoleBinding, acesso secreto por pods inesperados, comandos executivos de contêiner
- Implementar violações da política de segurança do pod como alertas SIEM
Referência CIS Kubernetes
O Center for Internet Security (CIS) publica benchmarks de segurança detalhados para Kubernetes. Use o kube-bench para avaliar automaticamente seu cluster em relação aos benchmarks CIS. Aborde todas as descobertas críticas e importantes antes da implantação da produção. Os serviços Kubernetes gerenciados (EKS, AKS, GKE) lidam com alguns itens de benchmark automaticamente, mas os itens responsáveis pelo cliente ainda exigem configuração.
Como Opsio protege Kubernetes
- Avaliação de segurança do cluster:Avaliamos seus clusters Kubernetes em relação aos benchmarks CIS e às melhores práticas dos provedores de nuvem.
- Implementação de proteção:Implementamos todos os itens da lista de verificação, incluindo RBAC, políticas de rede, segurança de pod e monitoramento.
- Monitoramento de tempo de execução:Nosso SOC monitora clusters Kubernetes em busca de eventos de segurança e comportamento anômalo.
- Aplicação da política:Implementamos OPA/Gatekeeper ou Kyverno para aplicar políticas de segurança automaticamente.
- Gestão contínua:Revisões regulares de segurança, reavaliação de benchmark CIS e atualizações de configuração de segurança.
Perguntas Frequentes
Qual é o controle de segurança Kubernetes mais importante?
Políticas de rede com negação padrão. Sem políticas de rede, cada pod pode se comunicar com todos os outros pods — um pod de aplicativo web comprometido pode acessar diretamente o pod do banco de dados, a pilha de monitoramento e o servidor Kubernetes API. As políticas de rede de negação padrão reduzem imediatamente o raio de explosão de qualquer comprometimento de contêiner.
Devo usar uma malha de serviço para segurança?
Service mesh (Istio, Linkerd) adiciona mTLS entre serviços, fornecendo criptografia e autenticação para todas as comunicações entre pods. Se você lida com dados confidenciais ou precisa atender aos requisitos de conformidade para criptografia em trânsito, a malha de serviço é valiosa. Para ambientes mais simples, apenas as políticas de rede podem ser suficientes.
Como lidar com segredos em Kubernetes com segurança?
Use um gerenciador de segredos externo (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) com um operador de segredos Kubernetes (Operador de segredos externos, Operador de segredos do Vault). Isso mantém os segredos fora do Git, fornece registro de auditoria, permite a rotação e centraliza o gerenciamento de segredos em cargas de trabalho Kubernetes e não Kubernetes.