Por que segurança em Kubernetes gerenciado é diferente
Quando você move workloads para EKS, AKS ou GKE, não está apenas “subindo pods na nuvem”.
Você está entrando em um modelo de responsabilidade compartilhada onde:
– O provedor (AWS, Azure, GCP) protege o control plane gerenciado.
– Você continua 100% responsável pelo que roda dentro dos nodes, dos pods e da própria configuração de segurança.
E é exatamente aí que muita gente escorrega.
Um ponto importante antes de ir para o passo a passo: kubernetes gerenciado segurança melhores práticas não é só “botar um scanner de imagens e pronto”. É uma combinação de arquitetura, configuração, cultura de time e monitoramento contínuo.
Vamos montar esse guia pensando em quem está começando e em quem já tem clusters em produção, mas quer elevar o nível de proteção.
—
Passo 1 – Comece pela base: contas cloud, redes e identidade
1.1. Separe ambientes e reduza blast radius
Antes mesmo de criar o cluster EKS, AKS ou GKE:
1. Separe contas/projetos/assinaturas por ambiente (dev, staging, produção).
2. Use VPCs/VNets/VPC-networks diferentes para reduzir impacto de um incidente.
3. Ative logs de auditoria no nível da conta/projeto desde o começo.
⚠️ Erro comum: um único projeto GCP com GKE “dev + prod” para “simplificar billing”.
Quando um atacante compromete um workload de dev, ganha visibilidade (e às vezes credenciais) que facilitam chegar na produção.
1.2. Identidade: IAM forte antes de RBAC
Kubernetes RBAC é importante, mas não resolve se o IAM da nuvem está frouxo.
– No EKS: use IAM Roles for Service Accounts (IRSA) em vez de dar permissões direto para nodes.
– No AKS: use Managed Identities para workloads que acessam recursos Azure.
– No GKE: implemente Workload Identity, evitando chaves de serviço estáticas.
Caso real:
Um time em EKS rodava pods com acesso à AWS via chaves gravadas em variáveis de ambiente.
Um atacante explorou uma vulnerabilidade de injeção em um container, deu um simples `env`, pegou as chaves e conseguiu listar buckets S3 de produção.
Migração para IRSA cortou a exposição, pois o token ficou isolado e escopado por service account.
—
Passo 2 – Projeto seguro do cluster (EKS, AKS, GKE)
2.1. Use o modo “privado” sempre que possível
– Prefira clusters com control plane privado (quando suportado pelo provedor).
– Restrinja a API do Kubernetes a um bastion/VPN ou a IPs específicos da empresa.
– Evite exposição pública da API para o mundo inteiro.
⚠️ Se você precisa de acesso remoto, use:
– VPN corporativa
– Identity-Aware Proxy no GCP
– Azure Bastion / AWS SSM Session Manager / OpenVPN em VPC
2.2. Desative o que não usa
Por padrão, muitos clusters vêm com recursos e add-ons que nem sempre você precisa:
– Desabilite cloud controller extras que não são utilizados.
– Revise add-ons como dashboards antigos ou instâncias de métricas sem autenticação.
– Verifique se não há webhooks de terceiros sem TLS adequado.
Erro real que já vi:
Um cluster AKS com Kubernetes Dashboard antigo publicado via LoadBalancer, sem autenticação, “para facilitar debug”.
Resultado: scanner de internet encontrou o endpoint, conseguiu token via configuração fraca e teve acesso administrativo ao cluster.
—
Passo 3 – Controle de acesso: RBAC, namespaces e multi-tenancy
3.1. Estruture com namespaces desde o início
Mesmo em times pequenos, crie uma organização mínima:
1. `kube-system` e namespaces internos: não mexa sem necessidade.
2. `dev`, `staging`, `prod` ou por domínio de negócio.
3. Namespaces dedicados para ferramentas de observabilidade e segurança.
Isso facilita aplicar políticas (NetworkPolicy, quotas, PodSecurity) por namespace.
3.2. RBAC prático (sem virar caos)
Linha de raciocínio para RBAC:
1. Crie roles específicas por tipo de ação (somente leitura, deploy, ops).
2. Use rolebindings por namespace.
3. Reserve clusterroles apenas para quem realmente precisa atuar em nível global.
⚠️ Evite `cluster-admin` para usuários humanos.
Use-o somente para contas técnicas sob forte controle, de preferência automatizadas (CI, pipelines).
Dica para iniciantes:
Comece concedendo permissão de somente leitura para desenvolvedores, depois vá adicionando ações específicas (como `create` em `deployments`) conforme as necessidades reais.
Isso evita “dar admin porque o time não consegue fazer X” antes de entender qual permissão falta.
—
Passo 4 – Isolamento de workloads: Pod Security, NetworkPolicy e nodes
4.1. Use Pod Security Standards (ou equivalentes)
Nos clusters mais novos, ative Pod Security Standards (baseline ou restricted):
– Proíba containers privilegiados.
– Bloqueie `hostNetwork`, `hostPID`, `hostIPC`, salvo exceções muito justificadas.
– Exija user não-root e filesystem read-only quando possível.
Caso real:
Uma equipe usou um DaemonSet “temporário” privilegiado para coletar logs de host.
Esqueceram de removê-lo.
Mais tarde, uma vulnerabilidade nesse DaemonSet permitiu acesso de root ao host, exposição de secrets de outros pods e até acesso ao plano de dados.
Com Pod Security Policy (na época) restritiva, o DaemonSet não teria subido assim.
4.2. NetworkPolicy não é opcional
Sem NetworkPolicy, todo pod fala com todo mundo dentro do cluster.
Estratégia simples:
1. Por padrão, negar tráfego entre namespaces sensíveis (ex.: `prod` isolado de `dev`).
2. Permitir explicitamente apenas o que é necessário (app → banco, app → cache).
3. Usar labels consistentes para agrupar workloads (ex.: `role=frontend`, `role=backend`).
Ferramentas de visualização de tráfego podem ajudar, mas mesmo uma política básica de “deny all e libera por serviço” já reduz muito a superfície de ataque.
4.3. Nodes e pools dedicados
– Separe node pools para workloads com perfis de segurança diferentes (por exemplo, pods que precisam de acesso a recursos de baixo nível).
– Use taints/tolerations para controlar o agendamento de pods sensíveis.
– Não misture workloads de clientes distintos (multi-tenant duro) no mesmo node sem uma estratégia séria de isolamento.
—
Passo 5 – Imagens, registries e supply chain
5.1. Imagens mínimas e confiáveis
– Evite imagens “gordas” como `ubuntu:latest` sem necessidade.
– Prefira distros minimalistas (`distroless`, `alpine` com cuidado, ou imagens oficiais reduzidas).
– Fixe versões (`tag` imutável) em vez de usar “latest”.
⚠️ Problema comum:
Alguém usa `FROM ubuntu:latest` no Dockerfile.
Alguns meses depois, a imagem base atualiza e uma lib crítica muda comportamento.
Deploy totalmente reprodutível? Não mais.
Além disso, novas vulnerabilidades aparecem sem que você perceba.
5.2. Scanner e políticas no registry
Aqui entram as ferramentas segurança para workloads em kubernetes:
– Scanners de imagem (Trivy, Clair, Anchore, ferramentas nativas do provedor).
– Assinatura de imagens (Cosign, Notation).
– Políticas de admissão (OPA/Gatekeeper, Kyverno) para bloquear imagens vulneráveis ou não assinadas.
Case real:
Um time integrava só scanner no CI, mas não tinha nada no cluster.
Quando um desenvolvedor fez deploy manualmente a partir da máquina local, usou uma imagem antiga e cheia de falhas.
A solução posterior foi incluir um webhook de admissão bloqueando imagens com CVEs acima de certo nível.
—
Passo 6 – Segredos, configurações e dados sensíveis
6.1. Nunca guarde segredos no Git puro
Isso vale mesmo para repositórios privados:
– Use ferramentas de criptografia (SOPS, Sealed Secrets).
– Integre com Secret Managers do provedor (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager).
– Evite colocar chaves diretamente em `ConfigMap` ou `Secret` sem considerar rota de comprometimento do etcd.
Exemplo prático:
Um repositório GitHub privado vazou quando um colaborador saiu da empresa e levou tokens pessoais.
Dentro dele, havia YAMLs com `Secret` em texto puro para acessar bancos de produção.
Quando o atacante conseguiu clonar o repo, pulou etapas e foi direto ao banco de dados.
6.2. Trate o etcd indiretamente
Em serviços gerenciados como EKS, AKS, GKE você normalmente não administra o etcd, mas:
– Qualquer `Secret` do cluster é salvo lá.
– Se alguém tiver `kubectl get secrets` com acesso amplo, é quase como ter acesso direto ao etcd.
Portanto, o foco deve ser:
1. Minimizar quem pode listar secrets.
2. Separar secrets por namespace conforme necessidade de acesso.
3. Fazer rotation periódica de credenciais importantes.
—
Passo 7 – Observabilidade e detecção de incidentes
7.1. Logs de auditoria do Kubernetes
Ative e envie audit logs para:
– CloudWatch / CloudTrail + serviços de log no EKS.
– Azure Monitor/Log Analytics no AKS.
– Cloud Logging no GKE.
Monitore especificamente:
– Criação/alteração de Roles, ClusterRoles, RoleBindings.
– Criação de ServiceAccounts com permissões amplas.
– Criação de pods privilegiados ou com mounts suspeitos.
7.2. Monitoramento de runtime
Ferramentas de runtime ajudam a detectar comportamentos anômalos:
– Execução de `bash`/`sh` em containers de produção.
– Acesso inesperado a paths sensíveis (`/etc`, `/var/run/secrets`).
– Conexões de saída para IPs maliciosos.
Case real:
Um cliente em GKE teve uma aplicação web explorada por RCE.
O atacante começou a instalar ferramentas (`curl`, `nc`).
Como havia um agente de runtime com regras simples (bloquear exec de shell em containers de prod), o incidente foi detectado e o pod foi automaticamente encerrado, enquanto um alerta disparou para o time de segurança.
—
Passo 8 – Automatização com CI/CD seguro
8.1. Pipeline é “usuário privilegiado”
Trate seu pipeline de deploy como uma identidade de alta sensibilidade:
– Tokens Kubernetes com escopo mínimo, de preferência atrelados a namespaces específicos.
– Deploy sempre via CI/CD; evite `kubectl apply` manual na máquina do desenvolvedor.
– Auditoria: logs de quem aplicou qual manifesto, em qual ambiente.
⚠️ Erro recorrente:
Usar um único token `cluster-admin` guardado em variável de ambiente do pipeline para todos os ambientes.
Se o pipeline de dev for comprometido, o atacante ganha cluster-admin em produção.
8.2. Gate de segurança no pipeline
Inclua estágios no CI/CD:
1. Lint de manifests (Kubeval, kubeconform, `kubectl apply –dry-run`).
2. Scan de imagens e dependências.
3. Checagem de políticas (OPA/Kyverno) antes de aplicar no cluster.
4. Deploy progressivo (blue/green ou canary) com rollback automático.
—
Passo 9 – Custos, consultoria e visão de longo prazo
9.1. Segurança vs custo: o equilíbrio certo
Muita gente olha apenas para “quanto custa o cluster” e esquece:
– Custo de ferramentas de observabilidade e segurança.
– Custo de horas de time para manter políticas e regras.
– Custo potencial de um incidente (multas, reputação, downtime).
Quando você compara serviços gerenciados kubernetes eks aks gke preço, inclua no cálculo:
– Se a oferta nativa de logging e segurança é suficiente ou precisará de terceiros.
– O esforço operacional de manter outros componentes (ingress, service mesh, etc.) seguros.
– Benefícios de features gerenciadas de upgrade e patching do control plane.
9.2. Quando buscar ajuda externa
Se o time ainda está aprendendo Kubernetes e cloud ao mesmo tempo, vale considerar consultoria segurança kubernetes eks aks gke para:
– Fazer uma revisão inicial de arquitetura.
– Definir baseline de políticas (RBAC, PodSecurity, NetworkPolicy).
– Configurar pipelines seguros e ferramentas de monitoramento desde o começo.
Isso evita anos de “dívida de segurança” acumulada que depois é muito cara de corrigir.
—
Passo 10 – Checklist resumido para proteger workloads
10.1. Foco prático: o que implementar primeiro
Se você quer saber como proteger aplicações em kubernetes gerenciado eks aks gke sem se perder, siga esta ordem recomendada:
1. Isolar ambientes
– Contas/projetos/assinaturas separados.
– Clusters por ambiente crítico (dev, stage, prod).
2. Fortalecer identidade e acesso
– IAM/Workload Identity/IRSA/Managed Identity configurados.
– RBAC com roles restritas, sem `cluster-admin` para humanos.
3. Restringir superfície do cluster
– API server privado ou restrito a IPs/VPN.
– Sem dashboards/serviços sensíveis expostos publicamente.
4. Aplicar políticas de pods e rede
– Pod Security Standards (baseline/restricted) ou equivalente.
– NetworkPolicies negando por padrão e permitindo explicitamente.
5. Proteger supply chain
– Imagens mínimas e versionadas.
– Scanners no CI e no registry, políticas de admissão no cluster.
6. Gerenciar segredos corretamente
– Sem segredos em texto puro no Git.
– Integração com secret manager, rotation periódica.
7. Configurar observabilidade de segurança
– Audit logs ativos, enviados a um backend central.
– Ferramentas de runtime para detectar comportamentos anômalos.
8. Endurecer CI/CD
– Deploy apenas via pipeline.
– Tokens de acesso com escopo mínimo e políticas de aprovação.
—
Fechando: segurança como processo contínuo
Segurança em Kubernetes gerenciado não é um “feature” que você ativa uma vez e esquece.
É um ciclo:
– Planejar a arquitetura com responsabilidade compartilhada clara.
– Implementar controles técnicos proporcionais ao risco.
– Revisar periodicamente configurações, permissões e ferramentas.
– Aprender com incidentes, near-misses e testes de penetração.
Se você começar pelos passos descritos aqui, já estará bem na frente de muitos clusters em produção que “simplesmente funcionam” – até o dia em que alguém decide testá-los de verdade.