Endurecimento do Kubernetes: uma base prática

O Kubernetes tornou-se o plano de controle padrão para cargas de trabalho modernas e, com essa onipresença, também virou um alvo cobiçado. Um cluster não é um sistema único, mas uma coleção distribuída de APIs, controladores, caminhos de rede e identidades, e cada uma dessas camadas pode ser mal configurada de formas que ampliam silenciosamente o raio de impacto de um único contêiner comprometido. Este artigo apresenta uma base prática de endurecimento para defensores e engenheiros de plataforma que operam clusters em produção. O enquadramento, do início ao fim, é entender para defender: descrevemos como surgem as fraquezas, qual telemetria revela o abuso e quais controles reduzem a superfície de ataque sem tornar a plataforma impossível de operar.

Por que uma base de endurecimento importa

As instalações padrão do Kubernetes otimizam a funcionalidade e a velocidade de desenvolvimento, não o mínimo privilégio. De fábrica você pode encontrar tokens de conta de serviço montados de forma permissiva, contêineres rodando como root, nenhuma política de rede e um servidor de API alcançável de mais lugares do que se pretendia. Nada disso é um bug; é um ponto de partida que assume que você aplicará suas próprias barreiras. Uma base fornece uma definição escrita e verificável da postura mínima que todo cluster deve cumprir, de modo que a segurança seja uma propriedade da plataforma e não algo que cada equipe reinventa. Sem ela, a deriva é inevitável e as auditorias viram arqueologia.

Uma boa base é em camadas. Cobre o plano de controle, os nós, as cargas de trabalho, a rede, a cadeia de suprimentos e as identidades que ligam tudo. Além disso, é imposta por maquinaria e não por boas intenções: o controle de admissão, a política como código e a varredura contínua de configuração transformam a base em algo que o cluster se recusa a violar.

O plano de controle e o servidor de API

O servidor de API é a porta de entrada para tudo. A autenticação anônima deve estar desativada, e toda requisição deve carregar uma identidade verificável respaldada por credenciais de vida curta. O registro de auditoria do kube-apiserver é sua fonte de verdade mais valiosa; ative-o com uma política que registre metadados para leituras e corpos completos de requisição para escritas em recursos sensíveis como secrets, roles e role bindings. Armazene esses registros fora do cluster para que um atacante que aterrisse dentro não consiga aparar os próprios rastros. O etcd, que guarda todo o estado do cluster incluindo secrets, deve estar cifrado em repouso e ser alcançável apenas pelo servidor de API via TLS mútuo.

Restrinja no nível de rede quem pode alcançar o ponto de extremidade da API. Um plano de controle gerenciado com um ponto de extremidade privado e uma lista de redes autorizadas remove uma faixa larga do risco exposto à internet. Os certificados devem rotacionar automaticamente, e a kubeconfig de administrador do cluster deve ser tratada como uma credencial joia da coroa e não como um arquivo que vive em notebooks.

Identidade de carga de trabalho e RBAC

O controle de acesso baseado em papéis é onde a maioria dos clusters reais vaza privilégio. Os dois antipadrões a caçar são verbos ou recursos curinga em um papel e vínculos ao papel embutido cluster-admin para pessoas ou contas de serviço que não precisam de fato dele. Conceda o conjunto mais estreito de verbos sobre o conjunto mais estreito de recursos no escopo mais estreito, e prefira papéis com namespace em vez dos de todo o cluster. Toda conta de serviço capaz de criar pods, ler secrets ou modificar role bindings é na prática um caminho para controle mais amplo, porque esses verbos podem ser encadeados em escalada.

Desative o montagem automática de tokens de conta de serviço por padrão e habilite-o apenas para cargas que realmente chamam a API. Onde uma carga precisa de permissões de nuvem, use a federação de identidade de carga da plataforma para que os pods recebam tokens de vida curta e de audiência restrita em vez de chaves estáticas de vida longa incrustadas em secrets. Revise o RBAC continuamente; um vínculo razoável no trimestre passado pode ser perigoso após uma reorganização de equipe.

Endurecer as próprias cargas de trabalho

No nível do pod, o objetivo é transformar um contêiner comprometido em um beco sem saída em vez de uma rampa de lançamento. Execute como usuário não root com um sistema de arquivos raiz somente leitura, descarte todas as capacidades do Linux e adicione de volta apenas o estritamente necessário, e proíba a elevação de privilégios com allowPrivilegeEscalation: false. Contêineres privilegiados, o compartilhamento de namespaces do host (hostPID, hostNetwork, hostIPC) e montagens de caminhos do host são as funções que os atacantes mais desejam, porque cada uma corrói a fronteira entre o contêiner e o nó. Trate-as como exceções que exigem revisão explícita, não como padrões.

Aplique um perfil seccomp como RuntimeDefault para restringir as chamadas de sistema que um contêiner pode emitir e, onde suas cargas toleram, sobreponha AppArmor ou SELinux. Os Pod Security Standards dão a você três níveis nomeados — privileged, baseline e restricted — e o controlador embutido Pod Security Admission pode impor o nível restricted por namespace. Para regras mais ricas, um motor de políticas como o Kyverno ou uma instalação de OPA/Gatekeeper permite expressar e impor restrições específicas da organização como código.

Segmentação de rede

Por padrão, todo pod pode falar com qualquer outro, o que significa que um único ponto de apoio enxerga toda a superfície leste-oeste. Uma NetworkPolicy de negação padrão por namespace, seguida de regras de permissão explícitas para os fluxos de que cada aplicação realmente precisa, é um dos controles de maior alavancagem que você pode aplicar. Ela converte o movimento lateral de um salto trivial em uma atividade que precisa cruzar uma fronteira imposta, e torna visíveis as conexões anômalas. Para garantias mais fortes, uma malha de serviços pode acrescentar TLS mútuo entre serviços e autorização consciente de identidade, de modo que uma posição de rede roubada não seja o mesmo que uma identidade roubada.

Não esqueça a saída. Restringir o que os pods podem alcançar para fora limita a exfiltração de dados e cega o malware que liga para casa a um host de comando e controle. Combine a política de rede com o registro de DNS e de saída para que destinos de saída inesperados se tornem eventos detectáveis.

Detecção: sinais que revelam o abuso

O endurecimento reduz a superfície de ataque; a detecção diz quando alguém sonda o que resta. O sinal mais rico é o registro de auditoria da API. Vigie requisições para enumerar secrets através de namespaces, a criação ou modificação de objetos ClusterRoleBinding, exec ou attach dentro de pods em execução, e pods criados com ajustes privilegiados ou de namespace do host. Uma rajada súbita de respostas 403 Forbidden de uma única conta de serviço muitas vezes significa que credenciais foram roubadas e estão sendo testadas contra recursos que nunca deveriam tocar.

Em tempo de execução, um sensor de comportamento como o Falco ou um agente EDR com consciência de contêineres pode sinalizar um shell aberto dentro de um contêiner, um processo inesperado lendo /etc/shadow, uma escrita em um caminho normalmente somente leitura ou uma conexão de saída para um endereço suspeito. Correlacione os eventos do cluster com os registros de nível de nó e do provedor de nuvem; um atacante que escapa para o nó ou pivota para o ponto de extremidade de metadados da nuvem deixa rastros em mais de um lugar, e a correlação é o que transforma o ruído isolado em uma história clara.

Armadilhas comuns

As equipes com frequência entregam uma política forte num cluster de homologação e depois concedem amplas exceções em produção porque um prazo ameaçava, e a exceção nunca é revisitada. Outro erro recorrente é impor a segurança de pods enquanto se deixa o servidor de API alcançável de qualquer lugar, de modo que o muro mais forte não tem portão. Secrets de pull de imagem amplos demais, secrets passados como variáveis de ambiente onde afloram em registros e despejos de falha, e clusters que nunca rotacionam credenciais são lacunas comuns. E desligar o registro de auditoria por ser barulhento troca seu melhor ativo forense por um pouco menos de armazenamento: uma barganha que você lamentará durante um incidente.

Uma lista de verificação prática

Use isto como base de partida e adapte ao seu risco. Plano de controle: auth anônima desligada, auditoria ligada e enviada para fora do cluster, etcd cifrado, ponto de extremidade de API privado com lista de redes. Identidade: sem cluster-admin permanente, sem RBAC curinga, automontagem de tokens desligada por padrão, identidade de carga para acesso à nuvem. Cargas: não root, sistema de arquivos raiz somente leitura, capacidades descartadas, sem elevação de privilégios, seccomp RuntimeDefault, Pod Security Admission restricted, sem namespaces do host sem revisão. Rede: negação padrão de entrada e saída por namespace, regras de permissão explícitas, mTLS de malha onde viável. Cadeia de suprimentos: imagens assinadas, verificação na admissão, varredura de vulnerabilidades como portão. Detecção: alertas do registro de auditoria, sensor de comportamento em execução, retenção de registros que sobreviva ao tempo de permanência.

FAQ: O Pod Security Admission basta sozinho?

É uma base embutida e sólida para impor o perfil restricted, e todo cluster deveria usá-la. Mas é deliberadamente limitada a um conjunto fixo de controles no nível do pod. Para regras específicas da organização — rótulos exigidos, registries permitidos, verificação de assinaturas de imagem ou cotas de recursos atadas a política — você vai querer um motor de políticas geral como o Kyverno ou o Gatekeeper ao lado. Pense no Pod Security Admission como o piso e no motor de políticas como as paredes que você constrói por cima.

FAQ: Como endureço sem bloquear os desenvolvedores?

Comece em um modo de auditoria ou aviso para que as equipes vejam o que seria bloqueado antes de algo realmente quebrar, e publique a base com um guia de remediação claro. Ofereça caminhos dourados — imagens base endurecidas, processos de isenção prontos e modelos que já satisfazem as regras — para que a opção segura seja também a fácil. A imposição pousa com suavidade quando a equipe de plataforma remove atrito em vez de simplesmente dizer não.

Conclusão

Uma base de endurecimento do Kubernetes não é um projeto único, mas um contrato vivo entre a segurança e as equipes que entregam na plataforma. Tranque o plano de controle, restrinja a identidade com RBAC de mínimo privilégio e identidade de carga, transforme contêineres comprometidos em becos sem saída, segmente a rede por padrão, verifique sua cadeia de suprimentos e instrumente tudo para que o abuso seja visível. Imponha com controle de admissão e política como código para que a postura não derive em silêncio. Bem feito, o endurecimento é invisível para quem constrói sobre o cluster e decisivo contra quem tenta invadir.