Bastionado de Kubernetes: cerrar el clúster sin romper lo que funciona
Un clúster con los permisos justos, la red segmentada y las imágenes bajo control, con cada cambio en el repositorio y aplicado por fases.
Herramientas habituales
- Kubernetes
- Hetzner
- Vault
- Tailscale
- Helm
- k3s
En resumen
Bastionar un clúster de Kubernetes es reducir lo que un atacante o un error pueden hacer dentro de él. Revisamos y cerramos los permisos RBAC, las políticas de red, los estándares de seguridad de los pods, el origen de las imágenes, los secretos, el acceso a la API y el registro de auditoría. Cada cambio va al repositorio y se aplica por fases, primero en modo aviso.
- Idiomas
- Español, catalán o inglés
- Respuesta
- El siguiente día hábil, en horario laboral
- Método
- En vuestra cuenta y vuestro repositorio, en código y documentado
Qué incluye
- Revisión del clúster frente a las recomendaciones de seguridad de Kubernetes y los CIS Benchmarks.
- RBAC con permisos mínimos por equipo y por aplicación, sin cuentas de administración compartidas.
- Políticas de red: denegar por defecto y abrir solo lo necesario.
- Estándares de seguridad de pods (Pod Security Standards) por espacio de nombres.
- Control de imágenes: registros permitidos, escaneo y versiones fijadas.
- Secretos cifrados y fuera del repositorio.
- Acceso a la API restringido y registro de auditoría activado.
- Todo en código, con informe del antes y el después.
¿Por qué bastionar el clúster?
Un clúster recién creado funciona, pero no está pensado para limitar daños. Lo habitual cuando lo revisamos:
- Todo el equipo entra con el mismo usuario de administración del clúster.
- Cualquier pod puede hablar con cualquier otro, incluida la base de datos.
- Hay contenedores que corren como root o con privilegios que no necesitan.
- Las imágenes vienen de cualquier registro y con la etiqueta latest.
- Los secretos están en el repositorio en base64, que no es cifrado.
- Nadie sabe quién borró aquel despliegue el martes porque no hay registro de auditoría.
¿Qué controles aplicamos y en qué orden?
El orden importa: primero lo que reduce más riesgo con menos impacto en el día a día del equipo.
| Control | Riesgo que cubre | Cómo se aplica | Impacto en el equipo |
|---|---|---|---|
| RBAC por equipo y aplicación | Un error o una credencial robada con permisos totales | Roles por espacio de nombres y acceso con identidad nominal | Bajo, cada persona ve lo suyo |
| Registro de auditoría | No saber quién hizo qué | Activado y enviado a los logs centrales | Ninguno |
| Políticas de red | Movimiento lateral dentro del clúster | Denegar por defecto y abrir por servicio | Medio, se revisa en modo aviso |
| Seguridad de pods | Contenedores con privilegios o como root | Pod Security Standards por espacio de nombres | Medio, algunas imágenes se ajustan |
| Control de imágenes | Imágenes de origen desconocido o con fallos | Registros permitidos, escaneo y versiones fijas | Bajo, si el CI ya construye las imágenes |
| Secretos | Credenciales legibles en el repositorio | Cifrado con Sealed Secrets, SOPS o Vault | Bajo, cambia el flujo de alta de secretos |
El acceso a la API del clúster también cuenta: en lugar de dejarla abierta a internet, la ponemos detrás de una red privada con NetBird o Tailscale, con acceso nominal por persona.
¿Cómo se trabaja?
Revisión
Estado actual frente a las recomendaciones de seguridad y los CIS Benchmarks, con la lista de hallazgos.
Plan por fases
Qué control va primero, qué puede romper y cómo se comprueba.
Modo aviso
Las políticas se despliegan sin bloquear, para ver qué afectaría.
Activación
Se ajusta lo necesario y se activan, fase a fase, desde el repositorio.
Informe
El antes y el después, y lo que queda pendiente por decisión vuestra.
¿Y después del bastionado?
Un clúster bastionado deja de estarlo si nadie lo vigila: llegan versiones nuevas, aplicaciones nuevas y excepciones «temporales». Si queréis, lo mantenemos dentro del SRE como servicio, con las actualizaciones de versión del clúster y la revisión de excepciones en el informe mensual. El mantenimiento completo del clúster lo explicamos en Kubernetes gestionado, y el caso de Hetzner, sin plano de control gestionado, en Kubernetes en Hetzner.
¿Qué experiencia tenemos?
Trabajamos con Kubernetes y Helm en plataformas en producción, en proveedores gestionados y en clústeres propios, con más de diez años de experiencia como SRE y DevOps. También hemos montado bases seguras en la nube y gestionado secretos con HashiCorp Vault. Nuestro criterio: la seguridad que el equipo no entiende acaba desactivada, así que cada control va explicado.
Preguntas frecuentes
¿Se va a romper algo?
El riesgo se controla aplicando por fases: primero las políticas en modo aviso, se revisa qué bloquearían, se ajustan y solo después se activan. Cada fase se puede revertir desde el repositorio.
¿Sirve para un clúster gestionado como EKS, GKE o AKS?
Sí. En los gestionados el proveedor se ocupa del plano de control, pero los permisos, la red, los pods, las imágenes y los secretos siguen siendo cosa vuestra. En k3s o clústeres propios revisamos también los nodos y el plano de control.
¿Qué herramientas usáis para las políticas?
Lo que ya traiga Kubernetes siempre que alcance, como Pod Security Admission y NetworkPolicy. Si hace falta más, Kyverno u OPA Gatekeeper para reglas propias. Elegimos la opción con menos piezas que cubra lo necesario.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Revisado el