Tema 15
Un workload seguro no depende solo de una imagen sin vulnerabilidades. También requiere identidad mínima, límites de recursos, aislamiento, comunicación controlada, secretos bien entregados y observabilidad durante la ejecución.
Un workload es una carga de trabajo que ejecuta una aplicación o componente dentro de la plataforma. En Kubernetes suele materializarse como pods gestionados por deployments, statefulsets, daemonsets, jobs u otros controladores.
La seguridad de workloads se centra en cómo se ejecuta la aplicación: con qué identidad, qué permisos tiene, qué recursos consume, qué secretos recibe, con quién se comunica y qué ocurre si se compromete.
El objetivo es diseñar workloads que puedan operar con el menor privilegio posible y que, ante un fallo o ataque, no comprometan todo el cluster.
La seguridad de workloads une controles de aplicación, contenedor, Kubernetes y red. No reemplaza el hardening del cluster, sino que lo aplica al nivel donde vive cada servicio.
Cada workload debería usar una service account específica. Usar la service account default dificulta aplicar mínimo privilegio y complica auditoría.
| Práctica | Riesgo | Enfoque recomendado |
|---|---|---|
| Service account default | Permisos genéricos y baja trazabilidad | Crear identidad por aplicación o componente |
| Permisos amplios | Lectura de secretos o modificación de recursos innecesaria | RBAC mínimo por namespace y acción |
| Token montado sin uso | Credencial disponible para un atacante | Deshabilitar montaje automático si no se necesita |
| Identidad compartida | Dificultad para atribuir acciones | Separar por servicio, ambiente y propósito |
Muchas aplicaciones en Kubernetes necesitan acceder a servicios cloud: colas, bases, almacenamiento, KMS o secretos. La práctica insegura es montar claves estáticas dentro del pod.
El enfoque preferible es usar identidad de workload integrada con el proveedor cloud. Así el pod obtiene credenciales temporales asociadas a su service account y rol autorizado.
Beneficios:
Requests y limits definen cuánto recurso necesita y puede consumir un contenedor. Son controles de disponibilidad y también de seguridad, porque reducen el impacto de abuso o fallas.
| Control | Función | Riesgo si falta |
|---|---|---|
| CPU request | Reserva esperada para scheduling | Ubicación ineficiente o degradación |
| CPU limit | Máximo de CPU permitida | Consumo excesivo por bug o abuso |
| Memory request | Memoria esperada para ejecutar | Scheduling incorrecto |
| Memory limit | Máximo de memoria permitida | OOM o afectación a otros workloads |
| Ephemeral storage | Uso de almacenamiento temporal | Llenado de disco del nodo |
El aislamiento busca que workloads de distinto riesgo no compartan demasiados recursos o permisos. Puede aplicarse en varias capas.
La ubicación de workloads influye en seguridad y disponibilidad. No siempre conviene que servicios críticos compartan nodo con workloads experimentales o de menor confianza.
Usos comunes:
Un sidecar es un contenedor auxiliar que corre en el mismo pod que la aplicación principal. Puede aportar proxy, logging, seguridad, sincronización de secretos o funciones de service mesh.
Riesgos de sidecars:
Un sidecar debe tener imagen confiable, permisos mínimos, límites de recursos y monitoreo igual que cualquier otro contenedor.
Los init containers se ejecutan antes de los contenedores principales. Sirven para preparar archivos, esperar dependencias o realizar inicialización. Como pueden acceder a volúmenes compartidos, deben controlarse con cuidado.
Buenas prácticas:
Un service mesh agrega una capa de comunicación entre servicios, normalmente mediante proxies sidecar o componentes de dataplane. Puede ofrecer mTLS, control de tráfico, observabilidad y políticas de autorización.
Capacidades típicas:
mTLS permite que dos servicios se autentiquen mutuamente y cifren comunicación. En un service mesh, los certificados suelen emitirse y rotarse automáticamente.
| Beneficio | Qué aporta | Cuidado necesario |
|---|---|---|
| Confidencialidad | Cifra tráfico entre servicios | Validar cobertura real del mesh |
| Autenticidad | Verifica identidad de servicio | Proteger autoridad certificadora del mesh |
| Autorización | Permite reglas por identidad | No confiar solo en nombres de red |
| Rotación | Certificados de corta duración | Monitorear expiración y errores de emisión |
Una vez que los servicios tienen identidad, se pueden definir políticas de autorización: qué servicio puede llamar a cuál, usando qué método, ruta o puerto.
Ejemplos:
Estas reglas reducen movimiento lateral y complementan network policies.
Los secretos deben entregarse al workload de forma controlada y con el menor alcance posible. No todos los contenedores del pod necesitan acceder a los mismos secretos.
Controles recomendados:
La observabilidad permite detectar problemas de seguridad y operación. Un workload seguro debe producir señales útiles sin exponer datos sensibles.
Se recomienda capturar:
La seguridad de workloads conecta identidad, permisos, recursos, red, secretos y observabilidad. Cuando estos controles se diseñan juntos, un servicio comprometido tiene menos capacidad de escalar, moverse lateralmente o afectar a otros componentes.
En el próximo tema estudiaremos DevSecOps: integración de seguridad en el ciclo de vida de desarrollo.