Hardening em Clusters Kubernetes (GKE/EKS): Guia Prático do CIS Benchmark para Evitar Pod Escape

O orquestrador de containers Kubernetes (K8s) transformou-se no sistema operacional da nuvem moderna. Através dele, empresas escalam milhares de microsserviços e aplicações transacionando milhões de acessos diariamente em ambientes gerenciados como o Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) e Azure Kubernetes Service (AKS).

No entanto, a extraordinária flexibilidade arquitetural do Kubernetes traz consigo uma superfície de ataque imensa, complexa e altamente vulnerável quando o cluster é implantado com as configurações padrão de fábrica (Default Settings). Em uma instalação padrão não blindada, um cibercriminoso que consiga explorar uma vulnerabilidade simples de aplicação web (como um LFI ou RCE em uma API rodando dentro de um único container do cluster) é capaz de executar uma técnica letal conhecida como Pod Escape (Fuga do Pod): o invasor transpassa a barreira de isolamento de virtualização do container, assume poderes de superusuário (root) sobre a máquina física ou virtual hospedeira (o Worker Node) e, a partir dali, extrai as chaves secretas do banco de dados etcd para assumir o controle absoluto e irrevogável sobre 100% dos servidores, containers e dados corporativos da empresa rodando na nuvem.

O Guia Normativo: O Que é o CIS Kubernetes Benchmark?

Para impedir que desastres arquiteturais ocorram em clusters de produção, o consórcio de segurança mundial Center for Internet Security (CIS) desenvolveu o CIS Kubernetes Benchmark — o manual canônico mais rigoroso e respeitado do mundo, que estabelece centenas de controles de configuração e endurecimento de segurança (Hardening) para todos os componentes lógicos de um cluster.

O benchmark divide a segurança do ambiente em dois grandes domínios de proteção: o Plano de Controle (Control Plane — o cérebro do cluster, composto por kube-apiserver, etcd, kube-scheduler e kube-controller-manager) e os Nós de Trabalho (Worker Nodes — onde rodam o kubelet, kube-proxy e os pods das suas aplicações). Abaixo, detalhamos os quatro pilares de hardening mais críticos e inegociáveis implementados pelas equipes de engenharia da ByteAbyss em nuvens GKE e EKS:

1. Erradicação de Containers Privilegiados e Adoção do PSS (Pod Security Standards)

O erro mais fatal e destrutivo na escrita de manifestos de deployment YAML no Kubernetes é permitir que um container execute com a flag privileged: true ou como usuário root (UID 0) do sistema operacional. Um container privilegiado possui acesso direto a absolutamente todos os dispositivos de hardware físicos do host (via diretório /dev) e retém todos os recursos normais do kernel Linux (Linux Capabilities). Se um hacker entrar num container desses, rodar o comando de montagem de disco mount /dev/sda1 /mnt permite que ele acesse, altere e formate diretamente o sistema de arquivos do nó físico da nuvem!

Para garantir que nenhum desenvolvedor envie um YAML inseguro burlando essas regras, deve-se aplicar em todos os Namespaces do cluster a política de controle nativa Pod Security Standards (PSS) na diretiva enforce: restricted ou integrar admission controllers de políticas como Kyverno ou OPA Gatekeeper na esteira CI/CD.

2. Eliminação de Chaves Estáticas em Segredos com Workload Identity (GKE/EKS)

Um padrão defasado e perigoso é armazenar chaves JSON estáticas de contas de serviço (como chaves ServiceAccountKey do Google Cloud ou AccessKeyId do AWS IAM) em texto puro dentro dos Secrets do Kubernetes, ou injetadas em variáveis de ambiente dos pods para permitir que a API salve arquivos no S3 ou no Cloud Storage. Se o pod for comprometido por uma falha de SSRF ou LFI, o atacante lê a variável de ambiente, rouba a chave estática e invade a sua conta AWS/GCP a partir do seu computador na Rússia.

A blindagem arquitetural moderna em nuvens GKE e EKS exige a adoção mandatória do Workload Identity (na GCP) ou IAM Roles for Service Accounts - IRSA (na AWS). Essa tecnologia cria uma federação criptográfica sem chaves estáticas entre o Service Account do Kubernetes (KSA) e o Service Account nativo da nuvem (GSA / IAM Role):

• O pod é executado sem nenhuma chave de acesso gravada em disco ou variável de ambiente.
• Quando a aplicação web precisa autenticar-se em um banco de dados da nuvem ou bucket S3, ela solicita uma credencial diretamente ao serviço de metadados local do nó (via STS - Security Token Service).
• O provedor de nuvem emite um token de acesso efêmero (que expira em poucos minutos) e vinculado exclusivamente àquela identidade do pod. Mesmo que o invasor roube esse token da memória, ele perde a validade antes que o criminoso consiga explorá-lo fora da rede da nuvem corporativa.

3. Microsegmentação Leste-Oeste via Network Policies e eBPF/Cilium

Por padrão de fábrica, em um cluster Kubernetes recém-instalado, a rede interna opera com confiança implícita total (Flat Network): absolutamente qualquer pod em execução no cluster possui permissão de rede para se comunicar, enviar pacotes e fazer ping para qualquer outro pod no mesmo cluster, independentemente do Namespace. Isso significa que, se um hacker invadir o container do "Blog WordPress de Marketing" na porta 80, ele conseguirá conectar-se livremente na porta interna 5432 do container do "Banco de Dados de Pagamentos Financeiros" localizado no namespace ao lado!

Para estancar a movimentação lateral (Lateral Movement), deve-se implementar o conceito de Zero Trust no tráfego Leste-Oeste do cluster através da aplicação rigorosa de Network Policies (Políticas de Rede):

Com essa regra de "Negar Tudo por Padrão" ativada, cada pod fica trancado em uma bolha de isolamento impenetrável. O arquiteto de segurança cria então políticas granulares adicionais liberando estritamente as conexões indispensáveis (ex: permitir que apenas o pod api-backend conecte-se na porta 3306 do pod mysql-db). Em infraestruturas de altíssimo desempenho, nós substituímos o antigo plugin de rede kube-proxy/iptables pela adoção de plataformas CNI baseadas em tecnologia eBPF (Extended Berkeley Packet Filter — como Cilium ou GKE Dataplane V2), que filtram o tráfego e bloqueiam pacotes maliciosos na camada mais profunda do kernel Linux em tempo de microssegundo com impacto zero na performance da CPU.

4. Isolamento do Plano de Controle e GKE Private Clusters

Por fim, o erro de hardening de rede externo mais elementar — e frequentemente pego no nosso scanner AbyssScan ASM — é expor a API de gerenciamento do plano de controle do cluster (kube-apiserver na porta 443/6443) abertamente para a internet pública com a regra 0.0.0.0/0. Se uma vulnerabilidade Zero-Day for descoberta no servidor de API do Kubernetes, seu cluster inteiro será capturado em minutos.

Em deployments de nuvem no Google Cloud (GKE) e AWS (EKS), exigimos a implementação obrigatória de Clusters Privados (Private Clusters):

• Os Nós de Trabalho (Worker Nodes) e suas máquinas virtuais não recebem endereços IP públicos expostos na internet; eles operam 100% isolados em subredes privadas, saindo para a internet quando necessário apenas através de gateways NAT controlados por firewalls de borda.
• O endpoint da API do Plano de Controle (Control Plane) é desativado para o tráfego público, permitindo conexões de administração via kubectl única e exclusivamente a partir das redes privadas internas da empresa, conexões VPN IPsec corporativas com MFA FIDO2 ou túneis de Zero Trust como GCP Identity-Aware Proxy (IAP) ou AWS Session Manager.