Segurança do cluster

Segurança de cluster é defesa em camadas: identidade mínima, workloads restritos, segredos fora do manifest e políticas que tornam o caminho inseguro difícil de publicar. Base64 em um Secret é codificação, não criptografia; quem lê o objeto na API pode decodificá-lo.

Dê acesso ao workload, não ao namespace inteiro

Role limita permissões a um namespace; ClusterRole só deve ser usado quando o recurso realmente é do cluster. Crie uma ServiceAccount por aplicação e prenda apenas verbos e recursos necessários. Teste antes de conceder:

kubectl auth can-i get configmaps --as=system:serviceaccount:app:minha-api -n app
kubectl auth can-i '*' '*' --as=system:serviceaccount:app:minha-api -n app

O segundo comando deve retornar no. Evite cluster-admin, curingas e token montado por padrão. Quando o Pod não chama a API, defina automountServiceAccountToken: false; quando chama, use tokens projetados de curta duração e audiência restrita.

Restrinja o que pode executar

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities: { drop: [ALL] }

Combine isso com Pod Security Standards no modo restricted, primeiro em auditoria e aviso, depois em bloqueio. Privileged, hostNetwork, hostPID, volume hostPath e socket Docker removem barreiras importantes e devem exigir exceção curta, revisada e auditável.

Use cofre externo ou operador de segredos para material sensível; limite quem sincroniza e quem lê. Criptografia em repouso do etcd reduz impacto de disco comprometido, mas não substitui RBAC. Kyverno ou Gatekeeper podem exigir imagem por digest, usuário não-root, requests/limits e assinatura; teste políticas em modo audit antes de impedir deploys.

Próximo passo: implemente o mínimo necessário com o guia de RBAC e conecte políticas de imagem à trilha de DevSecOps.