Segurança em EKS e Kubernetes: controles essenciais para clusters
Kubernetes concentra identidade, rede e cargas em um só lugar. Veja os controles que mais reduzem risco em clusters EKS.
Kubernetes é poderoso e complexo, e essa complexidade é a própria superfície de ataque. Em um cluster EKS, segurança envolve várias camadas que precisam estar alinhadas: a identidade que conecta o cluster à AWS, o controle de acesso interno via RBAC, o isolamento de rede entre pods, a gestão de secrets, a procedência das imagens e a forma como serviços são expostos. Uma falha em qualquer camada pode comprometer as demais.
Este guia organiza os controles essenciais para clusters EKS de forma defensiva. O objetivo não é cobrir tudo, e sim priorizar o que mais reduz risco e costuma estar mal configurado: identidade, RBAC, rede, secrets e imagens.
Identidade: IAM e IRSA
A pior prática em EKS é dar permissões amplas da AWS para os nós e deixar todos os pods herdarem isso. O caminho correto é o IRSA, que associa uma role IAM específica a uma service account de Kubernetes, dando a cada carga apenas as permissões AWS que ela precisa. Assim, um pod comprometido não ganha acesso ao que outras cargas podem fazer.
Restrinja também o acesso ao endpoint da API do cluster. Endpoint público sem restrição amplia a exposição; prefira endpoint privado ou, quando público for necessário, limite por origem e proteja o acesso com autenticação forte.
RBAC, network policies e secrets
O RBAC controla o que cada identidade pode fazer dentro do cluster. Evite conceder cluster-admin amplamente e modele papéis por necessidade real. Por padrão, todos os pods podem se comunicar entre si; network policies introduzem segmentação, permitindo apenas os fluxos esperados e contendo o movimento lateral caso um pod seja comprometido.
- Modelar RBAC por necessidade e evitar cluster-admin amplo
- Aplicar network policies com negação por padrão entre namespaces
- Criptografar secrets em repouso e evitar secrets em texto claro no manifesto
- Usar namespaces para isolar ambientes e equipes
- Restringir o acesso ao endpoint da API do cluster
Secrets do Kubernetes são codificados, não criptografados por padrão. Habilite a criptografia de secrets em repouso e considere uma solução de gestão de segredos externa para dados mais sensíveis, evitando deixá-los em manifestos versionados.
Imagens, admission control e atualização
Controle a procedência das imagens: use registries confiáveis, faça scan de vulnerabilidades e considere admission control para bloquear imagens que não atendam à política, como rodar como root ou vir de origem não aprovada. Mantenha o plano de controle e os nós atualizados, porque o Kubernetes evolui rápido e versões antigas acumulam vulnerabilidades conhecidas.
Habilite os logs do plano de controle e direcione para análise. Sem auditoria do que acontece na API do cluster, investigar um incidente em Kubernetes fica praticamente inviável.
Checklist prático
- Usar IRSA para permissões AWS por carga, não permissões amplas no nó
- Restringir o acesso ao endpoint da API do cluster
- Modelar RBAC por necessidade e evitar cluster-admin amplo
- Aplicar network policies com negação por padrão
- Habilitar criptografia de secrets em repouso
- Evitar secrets em texto claro em manifestos versionados
- Usar registries confiáveis e fazer scan de imagens
- Aplicar admission control para política de imagens e pods
- Manter plano de controle e nós atualizados
- Habilitar logs de auditoria do plano de controle
Boas práticas
- Conceda permissões AWS por carga via IRSA, com menor privilégio
- Segmente a rede do cluster com network policies
- Isole ambientes e equipes com namespaces e RBAC
- Controle a procedência das imagens com scan e admission control
- Mantenha versões suportadas e atualize com regularidade
- Audite a API do cluster e centralize os logs
Erros comuns
Permissões AWS amplas no nó herdadas por todos os pods
Um pod comprometido ganha acesso de toda a carga do nó na AWS.
cluster-admin concedido amplamente
Qualquer comprometimento de identidade vira controle total do cluster.
Sem network policies
Movimento lateral livre entre pods após um comprometimento inicial.
Secrets em texto claro em manifestos no Git
Credenciais expostas no repositório, fora de qualquer controle de acesso.
Versões antigas sem atualização
Vulnerabilidades conhecidas do Kubernetes permanecem exploráveis.
Quando procurar apoio especializado
Alinhar identidade, RBAC, rede e procedência de imagens em clusters EKS é um trabalho de arquitetura de segurança. A GUARDIASEC apoia isso nos serviços de Segurança AWS e de Hardening, avaliando o cluster por camadas e priorizando os controles de maior impacto.
Perguntas frequentes
O que é IRSA e por que ele importa?
IRSA associa uma role IAM a uma service account de Kubernetes, permitindo que cada pod receba apenas as permissões AWS que precisa. Sem ele, a tendência é dar permissões amplas ao nó, que todos os pods herdam. Com IRSA, um pod comprometido fica limitado às suas próprias permissões, reduzindo bastante o raio de impacto.
Network policies são obrigatórias?
Não são obrigatórias, mas são altamente recomendadas. Por padrão, todos os pods conseguem se comunicar, o que facilita o movimento lateral após um comprometimento. Network policies permitem definir explicitamente quais fluxos são permitidos, contendo um pod comprometido e segmentando o tráfego interno do cluster.
Secrets do Kubernetes são criptografados?
Por padrão eles são apenas codificados em base64, o que não é criptografia. É preciso habilitar a criptografia de secrets em repouso no cluster e evitar versionar secrets em texto claro em manifestos. Para dados mais sensíveis, vale usar uma solução externa de gestão de segredos.
Preciso atualizar o cluster com frequência?
Sim. O Kubernetes tem ciclo de versões relativamente rápido e versões antigas deixam de receber correções. Manter o plano de controle e os nós em versões suportadas é parte essencial da segurança, porque evita acumular vulnerabilidades conhecidas que já têm correção disponível.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.