Segurança de containers e Kubernetes: imagens, runtime e RBAC

Containers e Kubernetes viraram o padrão para rodar software em escala. Colocar cargas de trabalho em produção com eles é um problema já bastante documentado. O que ainda tropeça muita equipe é uma pergunta diferente: como manter esse ambiente seguro. Um cluster mal configurado é uma superfície de ataque generosa, porque concentra, num só lugar, imagens de origem duvidosa, permissões amplas, tráfego interno livre e segredos mal guardados.

A boa notícia é que a segurança de containers segue princípios claros e se organiza em camadas bem definidas. Este guia percorre a segurança do ciclo de vida inteiro: da imagem que você constrói, ao runtime que a executa, ao controle de acesso (RBAC) que governa quem faz o quê no cluster, passando por network policies e gestão de secrets. O foco aqui é exclusivamente segurança, não o passo a passo de ir para produção.

A imagem: sua primeira e mais barata linha de defesa

Todo container nasce de uma imagem. Se a imagem já vem insegura, tudo o que roda a partir dela herda o problema. Por isso a defesa começa aqui, e é a mais barata de aplicar.

Imagens mínimas reduzem a superfície de ataque

Uma imagem baseada em um sistema operacional completo carrega centenas de pacotes, bibliotecas e utilitários que sua aplicação nunca usa. Cada um deles é uma vulnerabilidade potencial e uma ferramenta a mais na mão de um atacante que consiga acesso. A prática recomendada é o oposto do "por via das dúvidas, inclua tudo":

• Imagens base mínimas: prefira variantes enxutas (como as slim), distroless (sem shell nem gerenciador de pacotes) ou construídas do zero. Menos software instalado significa menos CVEs e menos ferramentas para o invasor.
• Multi-stage builds: compile em um estágio pesado e copie só o artefato final para uma imagem mínima. As ferramentas de build ficam de fora do que vai para produção.
• Não rode como root: defina um usuário sem privilégios na imagem. Um container que roda como root e é comprometido facilita muito a fuga para o host.

Escaneie vulnerabilidades antes do deploy

Mesmo uma imagem mínima traz dependências, e dependências envelhecem. O scan de vulnerabilidades de imagens (com ferramentas como Trivy, Grype ou as integradas ao registry) cruza os componentes da imagem com bases de CVEs conhecidas. As boas práticas:

• Escaneie no pipeline, a cada build, e bloqueie o deploy quando surgirem falhas críticas.
• Escaneie também o que já está em produção, porque uma imagem "limpa" na semana passada pode ter uma CVE nova hoje.
• Assine as imagens e verifique a assinatura antes de rodar, garantindo que só imagens confiáveis e íntegras cheguem ao cluster.

O runtime: proteger o container em execução

Passada a imagem, o foco vai para o runtime, o container rodando. O objetivo é limitar o que ele pode fazer, de modo que um comprometimento não vire acesso ao host ou ao cluster inteiro.

Controles essenciais no Kubernetes, aplicados via Security Context e políticas de admissão:

• Sistema de arquivos somente leitura: se o container não precisa escrever em disco, monte a raiz como read-only. Isso atrapalha a instalação de malware.
• Descarte de capabilities do Linux: remova privilégios do kernel que a aplicação não usa. Comece do mínimo e adicione só o necessário.
• Proibir contêineres privilegiados: um container privilegiado praticamente equivale a root no host. Bloqueie por política.
• Seccomp e políticas de admissão: restrinja as chamadas de sistema permitidas e use um admission controller (como o Kyverno ou o OPA Gatekeeper) para recusar, na entrada, qualquer pod que viole as regras de segurança.

A ideia central se repete em toda a stack: menor privilégio. Um container deve poder fazer exatamente o que precisa, e nada além disso.

RBAC: quem pode fazer o quê no cluster

O RBAC (Role-Based Access Control) do Kubernetes governa quais ações cada usuário, grupo ou conta de serviço pode executar na API do cluster. É um dos pontos mais negligenciados e mais perigosos, porque permissões amplas aqui dão as chaves do reino.

Os erros clássicos e como evitá-los:

• Evite o papel cluster-admin distribuído: conceder admin de cluster "para agilizar" é entregar controle total. Reserve-o para pouquíssimas identidades.
• Escopo por namespace: prefira Role (limitada a um namespace) a ClusterRole (todo o cluster) sempre que possível.
• Contas de serviço com permissão mínima: cada aplicação roda com uma ServiceAccount. Por padrão, ela não deveria poder ler secrets de outros namespaces nem listar todos os pods. Conceda só o que aquela carga precisa.
• Desative o token automático quando não usado: pods que não falam com a API do Kubernetes não precisam de um token montado. Desligá-lo remove um alvo.

Uma ServiceAccount com permissões excessivas é a ponte preferida entre "comprometi um container" e "controlo o cluster". Tratar RBAC com o mesmo rigor de IAM na nuvem fecha essa ponte.

Network policies: o tráfego interno não deve ser livre

Por padrão, no Kubernetes, todos os pods podem se comunicar com todos os outros. Isso é uma rede plana interna, exatamente o cenário que facilita a movimentação lateral de um atacante. As Network Policies corrigem isso, funcionando como um firewall interno que define quais pods podem falar com quais.

A abordagem recomendada:

• Negar por padrão: comece com uma política que bloqueia todo o tráfego e libere explicitamente só os fluxos necessários (por exemplo, o frontend fala com a API, a API fala com o banco, e nada mais).
• Segmente por função: trate cada serviço como uma zona e permita apenas as conexões que fazem sentido no seu desenho.
• Isole namespaces sensíveis: ambientes que lidam com dados críticos devem ter fronteiras de rede rígidas.

O efeito é o mesmo da microssegmentação em redes tradicionais: comprometer um pod deixa de significar acesso a todos os outros.

Secrets no cluster: o ponto que mais vaza

Aplicações precisam de senhas de banco, chaves de API e certificados. No Kubernetes, esses dados vão para objetos Secret, e aqui mora uma armadilha: por padrão, Secrets são apenas codificados em base64, não criptografados. Base64 não é segurança, é só uma forma de representação. Quem lê o objeto lê o segredo.

Boas práticas para não transformar seus secrets em vazamento:

• Criptografia em repouso (encryption at rest): habilite a criptografia dos Secrets no armazenamento do cluster (etcd), para que um dump do banco de estado não entregue tudo.
• RBAC restrito a Secrets: limite drasticamente quem e quais contas podem ler objetos Secret.
• Gestores externos de segredos: integre o cluster a um cofre dedicado (como Vault, ou os secret managers de AWS, Azure e GCP) via operadores que injetam o segredo em runtime, sem gravá-lo em manifestos versionados.
• Nunca comite secrets no Git: manifestos com senhas embutidas no repositório são um clássico vazamento. Use referências, não valores.

Panorama das camadas de segurança

Camada	Risco principal	Controle central
Imagem	CVEs e software desnecessário	Imagem mínima, scan no pipeline, assinatura
Runtime	Fuga do container para o host	Menor privilégio, read-only, sem root, admission control
RBAC	Escalonamento no cluster	Papéis mínimos por namespace, ServiceAccounts restritas
Rede	Movimentação lateral	Network policies com negação por padrão
Secrets	Exposição de credenciais	Criptografia em repouso, cofre externo, RBAC restrito

Segurança de container é o mesmo princípio repetido em cada camada

Se há uma lição que atravessa tudo o que vimos, é esta: a segurança de containers e Kubernetes não depende de um único controle mágico, e sim da aplicação disciplinada do menor privilégio em cada camada. Imagem mínima, container sem root, ServiceAccount restrita, rede que nega por padrão e secrets fora do repositório. Cada uma dessas decisões é simples isoladamente. Juntas, transformam um cluster de porta aberta em um ambiente onde um comprometimento fica contido, em vez de virar controle total.

Na ConstructorTI, ajudamos times a fechar essas camadas como parte da engenharia: revisão de segurança de imagens e pipeline, hardening de runtime e admission control, auditoria de RBAC e ServiceAccounts, desenho de network policies e integração de gestão de secrets com cofres externos. Se você roda Kubernetes em produção e quer saber onde o seu cluster cederia num ataque antes que alguém descubra, converse com o nosso time de CyberSecurity.