El baseline de seguridad de Kubernetes alineado con CIS que entregamos desde el día uno

La mayoría de clústeres Kubernetes en producción no fueron endurecidos — fueron desplegados. Configuraciones por defecto, permisos de service account por defecto, sin políticas de admisión, sin network policies, sin audit log. Funcionan. También pasan un pen test básico en unos 12 minutos.

Este es el baseline de seguridad que entregamos en el día uno para cada clúster que gestionamos. Alineado con el CIS Kubernetes Benchmark, pero pragmático.

Pod Security Standards en 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 rechaza pods que corren como root, permiten escalada de privilegios, usan host networking u omiten seccompProfile: RuntimeDefault. Para la pequeña minoría de workloads que necesitan privilegios elevados (un driver CSI, un agente CNI), los ponemos en un namespace separado con el perfil privileged y tratamos el contenido de ese namespace como parte de la TCB del clúster.

El artículo completo cubre:

• Políticas Kyverno como código — y por qué la preferimos sobre OPA Gatekeeper
• Firmas de imagen requeridas y verificadas en admisión vía Cosign keyless
• NetworkPolicies default-deny — el modelo de conectividad opt-in
• Política de auditoría: capturar todo lo importante, alertar sobre lo correcto
• Tokens de ServiceAccount: deshabilitar el auto-montaje por defecto, SAs dedicados al propósito
• Cifrado de etcd en reposo con rotación de claves adecuada

Desplegamos este baseline en el día uno para cada cliente Kubernetes gestionado.