14. Hardening de Kubernetes: Pod Security, admission control, network policies y runtime security

14.1 Introducción

Kubernetes permite ejecutar workloads muy diversos. Esa flexibilidad también permite configuraciones peligrosas: pods privilegiados, contenedores root, montajes del host, capabilities innecesarias, secretos expuestos, comunicación libre entre namespaces y despliegues de imágenes no confiables.

El hardening consiste en definir límites técnicos para que los equipos puedan desplegar sin romper controles básicos. Debe combinar políticas preventivas, validación en admisión, segmentación de red, configuración segura de pods y monitoreo de runtime.

La meta es que el cluster no dependa solo de buenas intenciones o revisión manual.

14.2 Qué significa hardening en Kubernetes

Hardening es reducir superficie de ataque y aplicar configuraciones seguras por defecto. En Kubernetes implica controlar cómo se crean, configuran y ejecutan los workloads.

Áreas principales:

• Seguridad del pod y del contenedor.
• Restricción de privilegios, capabilities y montajes.
• Políticas de admisión para validar manifiestos.
• Network policies para limitar comunicación.
• Control de imágenes permitidas.
• Límites de recursos y cuotas.
• Detección de comportamiento anómalo en runtime.

14.3 Pod Security Standards

Pod Security Standards define niveles de seguridad para pods. Ayudan a establecer una línea base de controles que evitan configuraciones peligrosas.

El nivel adecuado depende del tipo de workload, pero producción debería tender a Baseline o Restricted, dejando Privileged para excepciones justificadas.

14.4 SecurityContext

SecurityContext define opciones de seguridad para pods y contenedores. Es una herramienta central para reducir privilegios.

Controles importantes:

• runAsNonRoot: exige ejecución con usuario no root.
• runAsUser: define UID específico.
• readOnlyRootFilesystem: evita escritura en el filesystem raíz.
• allowPrivilegeEscalation: impide aumentar privilegios dentro del contenedor.
• capabilities.drop: elimina capabilities innecesarias.
• seccompProfile: limita llamadas al sistema.

14.5 Contenedores privilegiados y capabilities

Un contenedor privilegiado puede acceder a recursos del host con muy pocas restricciones. Esto rompe gran parte del aislamiento esperado y debe evitarse salvo casos excepcionales.

Las capabilities permiten otorgar privilegios específicos sin dar todo el poder de root. La práctica recomendada es quitar todas las capabilities y agregar solo las estrictamente necesarias.

14.6 Admission control

Admission control intercepta solicitudes al API server antes de persistir objetos. Permite validar, modificar o rechazar recursos según políticas.

Usos comunes:

• Bloquear pods privilegiados.
• Exigir imágenes de registries aprobados.
• Requerir límites de CPU y memoria.
• Agregar etiquetas o configuraciones obligatorias.
• Exigir SecurityContext seguro.
• Validar firmas de imágenes.
• Rechazar servicios expuestos sin anotaciones o aprobación.

14.7 Policy as code

Policy as code expresa reglas de seguridad en archivos versionados y revisables. Esto permite probar, auditar y evolucionar políticas como parte del ciclo DevSecOps.

Beneficios:

• Reglas consistentes entre clusters y ambientes.
• Revisión por pares antes de cambios de política.
• Pruebas en modo auditoría antes de bloquear.
• Evidencia para cumplimiento.
• Integración con CI/CD e IaC scanning.

Las políticas deben empezar midiendo impacto. Pasar directamente a bloqueo estricto puede romper despliegues legítimos si no se preparan los equipos.

14.8 Network policies

Las network policies controlan tráfico entre pods, namespaces y destinos externos. Son esenciales para reducir movimiento lateral.

Una estrategia típica:

1. Aplicar deny all por defecto en namespaces sensibles.
2. Permitir tráfico entrante solo desde servicios autorizados.
3. Permitir egreso solo hacia dependencias necesarias.
4. Separar tráfico de administración, aplicaciones y datos.
5. Monitorear conexiones bloqueadas para ajustar reglas.

Las network policies requieren soporte del plugin de red. Si el CNI no las implementa, los manifiestos pueden existir sin efecto real.

14.9 Control de egreso

El tráfico saliente desde pods suele recibir menos atención que el entrante. Sin control de egreso, un workload comprometido puede comunicarse con dominios externos, descargar herramientas o exfiltrar datos.

Controles posibles:

• Network policies de egreso por namespace y aplicación.
• Proxy o gateway de salida controlado.
• DNS policy y monitoreo de dominios sospechosos.
• Firewall cloud para tráfico saliente desde nodos.
• Listas de destinos permitidos para servicios críticos.

14.10 Límites y cuotas de recursos

Los límites de recursos reducen riesgo de denegación de servicio interna. Un pod sin límites puede consumir CPU, memoria o almacenamiento hasta afectar otros workloads del nodo o namespace.

Controles recomendados:

• Definir requests y limits de CPU y memoria.
• Usar ResourceQuota por namespace.
• Aplicar LimitRange para valores por defecto.
• Separar workloads críticos de cargas experimentales.
• Monitorear throttling, OOMKilled y consumo anómalo.

14.11 Runtime security

Runtime security observa el comportamiento real de contenedores y nodos. Detecta acciones que no deberían ocurrir aunque el manifiesto haya pasado validaciones.

Ejemplos de señales:

• Ejecución de shells en contenedores productivos.
• Acceso inesperado a archivos sensibles.
• Conexiones salientes hacia destinos anómalos.
• Instalación de paquetes en runtime.
• Procesos no esperados para la imagen.
• Intentos de escape o uso de syscalls inusuales.
• Modificación de binarios o configuración dentro del contenedor.

14.12 Filesystem inmutable

Un filesystem raíz de solo lectura reduce la capacidad de un atacante para modificar el contenedor, instalar herramientas o persistir cambios. No todas las aplicaciones lo soportan sin ajustes, pero es una meta recomendable.

Para aplicarlo:

• Configurar readOnlyRootFilesystem.
• Definir volúmenes temporales para rutas que requieren escritura.
• Evitar que la aplicación escriba logs en archivos locales si puede enviarlos a stdout.
• Validar que caches y temporales usan rutas permitidas.
• Combinar con usuario no root y permisos de archivo correctos.

14.13 Imágenes permitidas

El cluster debería desplegar solo imágenes provenientes de fuentes confiables. Esto se logra combinando registries aprobados, firmas, digest y políticas de admisión.

14.14 Estrategia de adopción

Aplicar hardening de golpe puede romper cargas existentes. Conviene avanzar por etapas.

1. Inventariar workloads y configuraciones actuales.
2. Aplicar políticas en modo auditoría.
3. Corregir aplicaciones incompatibles con requisitos mínimos.
4. Activar bloqueos para riesgos críticos.
5. Ampliar controles por namespace y ambiente.
6. Medir excepciones y reducirlas con el tiempo.

14.15 Errores frecuentes

• Permitir pods privilegiados como solución general a problemas de permisos.
• Aplicar policies sin verificar que el CNI las soporta.
• No controlar egreso de pods.
• Usar admission control solo en producción y no en ambientes previos.
• Bloquear políticas sin proceso de excepción.
• No registrar eventos de runtime ni acciones sospechosas.
• Permitir imágenes de cualquier registry.
• Confiar solo en escaneo de imágenes y no observar comportamiento en ejecución.

14.16 Lista de verificación

• ¿Los namespaces tienen Pod Security Standards definidos?
• ¿Se bloquean contenedores privilegiados salvo excepción aprobada?
• ¿Los workloads usan usuario no root y capabilities mínimas?
• ¿Admission control valida imágenes, permisos y recursos?
• ¿Las network policies limitan tráfico entre namespaces y aplicaciones?
• ¿El egreso de workloads críticos está controlado?
• ¿Existen requests, limits y quotas por namespace?
• ¿Runtime security genera alertas accionables?

14.17 Qué debes recordar de este tema

• El hardening reduce riesgo antes y durante la ejecución de workloads.
• Pod Security y SecurityContext limitan privilegios del contenedor.
• Admission control convierte políticas en validaciones automáticas.
• Network policies son clave para contener movimiento lateral.
• Runtime security detecta comportamientos que no se ven solo leyendo manifiestos.

14.18 Conclusión

Endurecer Kubernetes implica establecer controles técnicos que impidan configuraciones peligrosas, limiten comunicación, reduzcan privilegios y detecten actividad anómala. Estos controles convierten al cluster en una plataforma más segura para ejecutar aplicaciones.

En el próximo tema estudiaremos la seguridad de workloads: service accounts, límites, aislamiento, sidecars y service mesh.