O baseline de segurança Kubernetes alinhado ao CIS que entregamos no primeiro dia

A maioria dos clusters Kubernetes em produção não foi endurecida — foi implantada. Configurações padrão, permissões padrão de service account, sem políticas de admissão, sem network policies, sem audit log. Funcionam. Também passam por um pen test básico em cerca de 12 minutos.

Este é o baseline de segurança que entregamos no primeiro dia para cada cluster que gerenciamos. Alinhado ao CIS Kubernetes Benchmark, mas pragmático.

Pod Security Standards em modo restricted

apiVersion: v1
kind: Namespace
metadata:
  name: workloads
  labels:
    pod-security.kubernetes.io/enforce: "restricted"
    pod-security.kubernetes.io/audit: "restricted"
    pod-security.kubernetes.io/warn: "restricted"

restricted rejeita pods que rodam como root, permitem escalada de privilégio, usam host networking ou omitem seccompProfile: RuntimeDefault. Para a pequena minoria de workloads que precisam de privilégios elevados (um driver CSI, um agente CNI), nós os colocamos em um namespace separado com o perfil privileged e tratamos o conteúdo desse namespace como parte da TCB do cluster.

O artigo completo cobre:

• Políticas Kyverno como código — e por que preferimos a OPA Gatekeeper
• Assinaturas de imagem requeridas e verificadas no momento da admissão via Cosign keyless
• NetworkPolicies default-deny — o modelo de conectividade opt-in
• Política de auditoria: capturar tudo o que importa, alertar sobre as coisas certas
• Tokens de ServiceAccount: desabilitar auto-mount padrão, SAs específicos por propósito
• Criptografia etcd em repouso com rotação de chaves apropriada

Implantamos este baseline no primeiro dia para cada cliente Kubernetes gerenciado.