Por qué Kubernetes amplía la superficie de ataque
Un clúster añade componentes propios que antes no existían: el servidor de API, etcd con toda la configuración y los secretos, el kubelet de cada nodo y la red entre pods. Cada uno es un objetivo, y una exposición o un permiso mal puesto en cualquiera de ellos puede comprometer cargas de trabajo completas.
Vectores de ataque más habituales
RBAC demasiado permisivo que permite escalar de un pod al clúster completo, contenedores privilegiados o con el socket de Docker montado, imágenes con vulnerabilidades conocidas o procedentes de registros no confiables, secretos guardados como variables de entorno, y ausencia de políticas de red que deja a todos los pods hablando entre sí.
Cómo endurecer un clúster
Aplicar mínimo privilegio en RBAC y cuentas de servicio, imponer Pod Security Standards restringidos, escanear imágenes antes del despliegue y firmarlas, definir NetworkPolicies que denieguen por defecto, gestionar secretos con un almacén externo, y mantener el plano de control fuera de internet. Validar después con pruebas activas contra CIS Benchmarks.
