Hardening de Kubernetes

Kubernetes orquesta contenedores a escala y su superficie de ataque es enorme: API server, RBAC, red entre pods, secretos y el runtime. Un clúster mal configurado permite escalar de un pod comprometido al control total. Esta ficha cubre el bastionado de los puntos críticos.

Superficie y puntos críticos

API server     el cerebro; exponerlo o un RBAC laxo = control del clúster
etcd           almacén de TODO (incl. secretos); cifrar y restringir acceso
kubelet        en cada nodo; su API mal protegida da ejecución en el nodo
RBAC           quién puede hacer qué; el exceso de permisos es el fallo nº1
red            por defecto TODO pod habla con todos -> necesita NetworkPolicies

RBAC y cuentas de servicio

- mínimo privilegio en Roles/ClusterRoles; evitar cluster-admin y comodines (*)
- ServiceAccount por carga, sin montar el token si no se usa (automountServiceAccountToken: false)
- cuidado con verbos peligrosos (create pods, exec, secrets get) -> rutas de escalada
- auditar permisos: `kubectl auth can-i`, herramientas (rbac-tool, kubescape)

Pod Security y admisión

Pod Security Standards (PSS)   baseline/restricted via Pod Security Admission
  -> no privileged, no hostPath/hostNetwork, no root, drop capabilities (ver dso-containers)
Admission control (OPA Gatekeeper / Kyverno)  políticas: solo imágenes firmadas, etiquetas,
  límites de recursos, no :latest, registries permitidos

Red y secretos

NetworkPolicies   default-deny entre pods/namespaces -> microsegmentación (ver def-red)
Secrets           base64 ≠ cifrado: cifrar etcd en reposo, external-secrets/sealed-secrets (dso-secrets)
Ingress/mTLS      TLS en los bordes; service mesh (mTLS) para tráfico este-oeste si aplica

Rutas de ataque típicas (que el hardening cierra)

- pod comprometido + SA con permisos amplios -> tomar el clúster vía API
- contenedor privilegiado/hostPath -> escape al nodo (ver dso-containers)
- metadata de la nube desde el pod (IMDS) -> credenciales del nodo (ver cloud)
- etcd o kubelet expuestos; dashboards sin auth

Herramientas

Postura     kube-bench (CIS), kubescape, kube-hunter, Trivy (misconfig)
Políticas   OPA Gatekeeper, Kyverno
Runtime     Falco; auditoría del API server (audit logs -> def-siem)

Blue Team / AppSec

RBAC de mínimo privilegio (sin cluster-admin ni *) y SA sin token si no se usa: es el fallo nº1.
Pod Security restricted + admisión (Gatekeeper/Kyverno): no privileged, no root, solo imágenes firmadas.
NetworkPolicies default-deny (microsegmentación) y cifrado de etcd/secretos.
Evaluar postura con kube-bench/kubescape y auditar el API server hacia el SIEM.

CVEs y casos reales

Tesla (2018): Kubernetes dashboard expuesto sin auth → cryptojacking en su clúster.
Ataques que pivotan de un pod a IMDS de la nube para robar credenciales del nodo (ver cloud).
CVEs del propio Kubernetes (p. ej. CVE-2018-1002105, escalada por el API server) subrayan parchear el plano de control.

Checklist de prueba

RBAC de mínimo privilegio; sin cluster-admin/comodines; auditar can-i
ServiceAccounts sin token automontado si no se usa
Pod Security restricted + admisión (Gatekeeper/Kyverno)
NetworkPolicies default-deny (microsegmentación)
etcd cifrado; secretos gestionados (Gestión de secretos)
API server/kubelet/etcd no expuestos; dashboards con auth
Postura con kube-bench/kubescape; audit logs al SIEM
Solo imágenes firmadas (Seguridad en CI/CD/Seguridad de contenedores)