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
Rede: negar por padrão entre pods
Como todo pod fala com todo pod por padrão, a segmentação começa por uma network policy que nega o tráfego de entrada e libera apenas os fluxos esperados. Aplicada por namespace, ela contém o movimento lateral: um pod comprometido não alcança serviços que não deveriam recebê-lo. Introduza a negação por padrão com cuidado, mapeando antes os fluxos legítimos, para não interromper a comunicação que a aplicação de fato precisa.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: app
spec:
podSelector: {}
policyTypes:
- IngressSecrets 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.
Pod Security: contexto de segurança e admissão
Um pod que roda como root, com privilégio elevado ou com o sistema de arquivos gravável fica bem mais perto de afetar o nó caso o contêiner seja comprometido. O contexto de segurança do pod define esses limites: rodar como usuário sem privilégio, impedir o escalonamento, descartar capabilities e usar o sistema de arquivos somente leitura. São ajustes declarados no próprio manifesto e valem para praticamente qualquer carga.
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]Para que esses limites não dependam da disciplina de cada manifesto, o Pod Security Admission aplica um padrão no nível do namespace e recusa pods que não o atendem. O nível restricted cobre as práticas mais importantes de uma vez. Marque os namespaces de carga com o rótulo de enforcement e abra exceção apenas com justificativa, em vez de deixar cada equipe decidir isoladamente.
kubectl label namespace app \
pod-security.kubernetes.io/enforce=restrictedImagens, 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.
Detecção em runtime e resposta no cluster
Prevenção reduz o que pode dar errado, mas parte da segurança do cluster está em perceber quando algo já aconteceu. Os logs de auditoria da API mostram quem criou, alterou ou apagou recursos, e alguns eventos merecem alerta imediato: um comando de execução dentro de um pod de produção, a criação de uma role ampla, uma tentativa de rodar um pod privilegiado ou o acesso repetido a secrets. Direcione esses eventos para um destino de análise com dono e prazo de resposta.
A detecção em tempo de execução complementa o log da API observando o comportamento dentro dos contêineres, como processos inesperados ou conexões de rede fora do padrão. No EKS, o GuardDuty oferece um plano de monitoramento em tempo de execução que se integra a essa camada. O objetivo é reduzir o tempo entre um comportamento anômalo e a resposta, seja isolar um pod, revogar uma credencial ou conter um namespace.
- Alertar sobre execução de comandos dentro de pods de produção
- Alertar sobre criação de roles amplas e mudanças de RBAC sensíveis
- Observar processos e conexões inesperadas dentro dos contêineres
- Definir dono e prazo de resposta para os alertas do cluster
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
- Aplicar Pod Security Admission em nível restricted nos namespaces de carga
- Definir securityContext com runAsNonRoot e readOnlyRootFilesystem
- Descartar capabilities e impedir escalonamento de privilégio nos pods
- Aplicar uma network policy de negação por padrão e liberar só os fluxos esperados
- Habilitar detecção em runtime e alertar sobre exec em pods de produção
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
- Aplique Pod Security Admission em restricted e abra exceção só com justificativa
- Monitore a execução dentro dos pods, não apenas a configuração do cluster
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.
Pods rodando como root e com privilégios elevados
Um comprometimento no contêiner fica mais perto de afetar o nó e o cluster.
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.
O que é o Pod Security Admission e ele substituiu o PodSecurityPolicy?
O Pod Security Admission é o mecanismo nativo que aplica os Pod Security Standards no nível do namespace, recusando pods que não atendem ao padrão definido. Ele substituiu o PodSecurityPolicy, que foi descontinuado. O uso comum é marcar cada namespace com um rótulo de enforcement, sendo o nível restricted o que cobre de uma vez as práticas mais importantes, como impedir root, privilégio elevado e escalonamento.
Como aplico negação de rede por padrão sem quebrar o cluster?
Mapeie antes os fluxos legítimos entre os serviços, depois introduza a network policy de negação de entrada por namespace e libere explicitamente cada fluxo necessário. Comece por um namespace de menor risco para validar o comportamento e observe os logs da aplicação em busca de comunicação bloqueada indevidamente. A negação por padrão é o alvo, mas chegar lá com etapas evita interromper a comunicação que a aplicação precisa.
Como detecto atividade suspeita dentro de um pod?
Duas fontes se complementam. Os logs de auditoria da API mostram ações sobre recursos do cluster, como criar roles ou executar comandos em pods, e alguns desses eventos merecem alerta imediato. A detecção em tempo de execução observa o comportamento dentro do contêiner, como processos ou conexões fora do padrão. No EKS, o GuardDuty oferece um plano de monitoramento em tempo de execução. O importante é que os alertas cheguem a alguém com prazo de resposta, não apenas a um painel.
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.