Boas práticas de segurança no Kubernetes: um checklist prático

Proteger o Kubernetes não é um único controle que você liga — é um conjunto de boas práticas de segurança no Kubernetes aplicadas de forma consistente em cada camada da stack. A comunidade descreve essas camadas como os 4 C's: Cloud, Cluster, Container e Code (Código). Uma fraqueza em qualquer uma delas pode comprometer as demais, e é por isso que o fortalecimento precisa ir da conta de nuvem que hospeda seus nós até o código da aplicação nos seus pods, atravessando todo o ciclo de vida do build ao deploy e ao runtime.

Este artigo é o checklist prático. Em vez de reexplicar cada conceito em profundidade, ele agrupa as ações concretas que você deve tomar para fortalecer um cluster Kubernetes e traz links para aprofundamentos focados quando você quiser o panorama completo. Percorra cada seção, marque os itens que se aplicam ao seu ambiente e revise-os em uma cadência regular — o Kubernetes evolui rápido, e um cluster que estava seguro no trimestre passado não é automaticamente um cluster seguro hoje. Se você quer a visão estratégica por trás dessas táticas, comece pelo nosso pilar de segurança no Kubernetes.

Uma observação rápida sobre como usar esta lista. Não existem dois clusters idênticos, então trate estes itens como uma linha de base a adaptar, e não como um mandato rígido. Priorize os controles que reduzem o raio de impacto — menor privilégio, segmentação de rede e fortalecimento do control plane — porque eles limitam o dano dos incidentes que você não consegue prevenir. E sempre que um passo manual aparecer abaixo, pergunte se ele não pode ser aplicado automaticamente. Checklists que vivem apenas em um wiki se deterioram rápido; checklists codificados como política e gates de CI continuam funcionando enquanto seu time foca em entregar.

Cluster e control plane

O control plane é o cérebro do seu cluster. Se um atacante alcança o API server ou o etcd, ele efetivamente domina tudo o que roda ali, então é aqui que o fortalecimento traz mais retorno. Serviços gerenciados de Kubernetes cuidam de parte disso por você, mas a responsabilidade é compartilhada — você continua responsável pela autenticação, pela configuração de auditoria e pelo grau de exposição do endpoint.

• Atualize o Kubernetes com regularidade e mantenha-se em uma versão suportada que ainda receba patches de segurança.
• Restrinja o acesso de rede ao API server — nunca o exponha à internet pública sem controles rígidos, e prefira endpoints privados ou uma allowlist.
• Desabilite a autenticação anônima (--anonymous-auth=false) para que toda requisição esteja vinculada a uma identidade.
• Habilite e centralize o audit logging para ter um registro resistente a adulteração de quem fez o quê.
• Proteja o etcd: habilite mutual TLS, restrinja o acesso apenas aos nós do control plane e ative a criptografia em repouso dos seus dados.
• Meça seu cluster em relação ao CIS Kubernetes Benchmark e remedie os achados que importam para o seu modelo de ameaças.
• Rotacione certificados e credenciais do control plane em um cronograma definido.

Controle de acesso

A maioria dos incidentes reais de Kubernetes escala porque uma identidade comprometida tinha muito mais poder do que precisava. O menor privilégio é o antídoto: o objetivo é que um token roubado ou um workload sequestrado consiga alcançar apenas a fatia estreita do cluster que legitimamente utiliza, e nada além disso.

• Aplique o menor privilégio no RBAC — conceda o conjunto mais restrito de verbos e recursos que um sujeito realmente precisa.
• Evite vincular cluster-admin a usuários, grupos ou workloads, exceto em cenários genuínos de break-glass.
• Mantenha a higiene de ServiceAccount: dê a cada workload sua própria ServiceAccount e desabilite o automount de token onde ele não for necessário.
• Audite ClusterRoleBindings e RoleBindings periodicamente para detectar acúmulo de privilégios.
• Integre a autenticação do cluster ao seu provedor de identidade em vez de depender de credenciais estáticas de longa duração.

Para o passo a passo completo de roles, bindings e armadilhas comuns, veja boas práticas de RBAC no Kubernetes.

Fortalecimento de workloads e pods

Um pod que roda como root, monta o sistema de arquivos do host ou pode escalar privilégios transforma um único bug de aplicação em um comprometimento de nó. Restrinja o que seus workloads têm permissão de fazer e faça da configuração segura o padrão que os desenvolvedores herdam, em vez de algo que cada time precisa lembrar.

• Aplique o Pod Security Admission no nível restricted para os namespaces de produção.
• Defina um securityContext em todo workload: runAsNonRoot, remova todas as capabilities do Linux, proíba a escalada de privilégios e use um sistema de arquivos raiz somente leitura onde for possível.
• Nunca execute containers privilegiados nem monte os namespaces de rede, PID ou IPC do host, a menos que haja uma exigência inegociável.
• Defina resource requests e limits para que um único workload não possa privar os vizinhos de recursos nem viabilizar uma negação de serviço.
• Use um perfil seccomp (comece com RuntimeDefault) para limitar as syscalls que os containers podem fazer.

Aprofunde-se nos detalhes em segurança de pods no Kubernetes.

Rede

Por padrão, todo pod em um cluster consegue conversar com qualquer outro pod. Essa rede plana é conveniente e perigosa — ela permite que um atacante se mova lateralmente no momento em que aterrissa em um workload. As NetworkPolicies são a forma de transformar essa planta baixa aberta em um conjunto de salas trancadas, para que um ponto de apoio em um serviço de frontend não entregue também a camada de banco de dados.

• Aplique uma NetworkPolicy de default-deny em cada namespace e, então, permita explicitamente apenas o tráfego necessário.
• Restrinja o egress para que pods comprometidos não consigam alcançar livremente a internet ou serviços internos.
• Segmente workloads sensíveis (bancos de dados, gerenciadores de secrets) em seus próprios namespaces com políticas mais rígidas.
• Confirme que seu plugin CNI de fato aplica NetworkPolicies — nem todos aplicam.
• Criptografe o tráfego pod a pod nos caminhos sensíveis, usando mTLS ou um service mesh quando apropriado.

Veja network policies no Kubernetes para padrões e exemplos.

Secrets

Os Secrets são alvos de alto valor. Os Kubernetes Secrets são apenas codificados em base64 por padrão, não criptografados, então precisam de proteção deliberada.

• Habilite a criptografia em repouso para Secrets no etcd, idealmente respaldada por um provedor KMS.
• Restrinja o acesso a Secret com RBAC para que apenas os workloads e as pessoas que precisam de um dado secret consigam lê-lo.
• Nunca deixe secrets em hardcode em manifests, imagens de container, variáveis de ambiente no controle de versão ou logs de CI.
• Prefira um gerenciador externo de secrets e injete os valores em runtime em vez de armazená-los a longo prazo no cluster.
• Rotacione os secrets com regularidade e revogue-os imediatamente quando houver suspeita de exposição.

O guia completo está em gerenciamento de secrets no Kubernetes.

Imagens e cadeia de suprimentos

Tudo o que você executa começa como uma imagem de container. Se essa imagem estiver inchada, sem patches ou não verificada, nenhum grau de fortalecimento em runtime compensa isso por completo. A cadeia de suprimentos por trás dessa imagem — camadas base, dependências de terceiros e o pipeline que a constrói — faz parte da sua superfície de ataque tanto quanto o próprio cluster.

• Escaneie imagens em busca de vulnerabilidades conhecidas antes do deployment e continuamente no seu registry.
• Use imagens base mínimas (distroless ou slim) para reduzir a superfície de ataque e a carga de patches.
• Assine imagens e verifique assinaturas para que apenas artefatos confiáveis rodem no seu cluster.
• Aplique política com um admission controller — rejeite imagens não assinadas, imagens de registries não confiáveis ou imagens com vulnerabilidades críticas não corrigidas.
• Fixe imagens por digest em vez de tags mutáveis como latest.

Mais sobre isso em segurança de imagens no Kubernetes e na página da nossa plataforma de segurança de containers.

Observabilidade e runtime

A prevenção nunca é perfeita, então você também precisa enxergar o que está acontecendo em um cluster em execução e responder rápido quando algo parecer errado. O runtime é onde uma configuração incorreta que você deixou passar, um zero-day em uma dependência ou uma credencial roubada realmente se materializa — e a diferença entre um incidente contido e uma violação costuma estar em quão rápido você percebe e age.

• Colete e centralize logs e métricas do control plane, dos nós e dos workloads.
• Implante detecção de ameaças em runtime para capturar atividades anômalas de processos, arquivos e rede dentro dos containers.
• Gere alertas em eventos suspeitos — novos pods privilegiados, exec inesperado em containers ou mudanças no RBAC.
• Mantenha e ensaie um plano de resposta a incidentes específico para Kubernetes, incluindo como isolar um pod ou nó comprometido.
• Retenha os audit logs e os dados de runtime por tempo suficiente para dar suporte a uma investigação forense.

Shift-left e automação

O lugar mais barato para corrigir uma configuração incorreta no Kubernetes é antes que ela seja aplicada. Automatize suas verificações para que a segurança viaje junto com cada mudança em vez de ser acoplada no final. Um achado detectado em um pull request é uma edição rápida; o mesmo achado detectado em produção é uma revisão de incidente, uma janela de mudança e um redeploy. O shift-left é o que torna todas as outras seções deste checklist sustentáveis em escala.

• Escaneie manifests do Kubernetes e Helm charts em busca de configurações incorretas no CI e faça o build falhar em achados de alta severidade.
• Escaneie sua infraestrutura como código (Terraform e similares) que provisiona clusters e recursos de nuvem.
• Condicione merges e deployments à aprovação das verificações de segurança para que nada inseguro chegue à produção silenciosamente.
• Acompanhe os achados ao longo do tempo e reduza o backlog em vez de carimbar exceções.

Este é o cerne da mudança do DevOps para o DevSecOps. Nosso ferramental de segurança de IaC ajuda você a capturar esses problemas na origem.

Como a Rainforest ajuda

Percorrer um checklist como este manualmente em dezenas de clusters e centenas de repositórios não escala. A Rainforest reúne esses controles em uma única plataforma: escaneando imagens de container em busca de vulnerabilidades, verificando manifests do Kubernetes e infraestrutura como código em busca de configurações incorretas antes que sejam enviados e trazendo os achados diretamente para o fluxo de trabalho do desenvolvedor, de modo que os problemas sejam corrigidos cedo. Em vez de perseguir problemas por ferramentas desconectadas, seus times ganham uma visão consistente e priorizada de onde um cluster se desvia dessas boas práticas — e uma orientação clara de como fechar a lacuna. Como a mesma plataforma cobre código, imagens e infraestrutura como código, você pode rastrear um risco de runtime até o manifest ou a dependência que o introduziu e corrigi-lo uma única vez na origem, em vez de remendar a mesma classe de problema cluster por cluster.

Se você quer ver como isso funciona no seu próprio ambiente, explore nossa plataforma de application security testing ou agende uma demo.