26. Contenedores, Kubernetes y seguridad en pipelines de despliegue
Los contenedores y Kubernetes aceleran el despliegue de aplicaciones, pero también agregan nuevas superficies de riesgo: imágenes, registros, manifiestos, secretos, RBAC, redes internas, admission controllers y pipelines. En este tema aprenderás a evaluarlos con metodología y sin afectar la operación.
Objetivo
Entender cómo auditar contenedores, clusters Kubernetes y pipelines CI/CD dentro de un alcance autorizado.
Enfoque
Revisar configuración, permisos, imágenes, secretos, red, despliegues y controles preventivos.
Resultado
Identificar riesgos reales en la cadena de despliegue y proponer endurecimiento aplicable por equipos DevOps.
26.1 Introducción
Un contenedor empaqueta una aplicación con sus dependencias para ejecutarla de forma consistente. Kubernetes coordina muchos contenedores, administra despliegues, redes, servicios, secretos, escalado y disponibilidad. La cadena completa suele integrarse con repositorios, registros de imágenes y pipelines de CI/CD.
Desde la perspectiva de pentesting, el riesgo no está solo en una aplicación vulnerable. También puede estar en una imagen con secretos, un contenedor privilegiado, un rol de Kubernetes demasiado amplio, un namespace sin separación, una política de red inexistente o un pipeline capaz de desplegar cambios sin controles suficientes.
26.2 Alcance de una revisión de contenedores
El alcance debe indicar qué registros, repositorios, clusters, namespaces, aplicaciones, pipelines, cuentas de servicio y entornos pueden revisarse. También debe definir si se permite lectura de manifiestos, revisión de imágenes, análisis de secretos, consulta de configuración del cluster o ejecución de pruebas controladas.
Esta claridad es importante porque un cluster puede alojar cargas de múltiples equipos o clientes. Una acción invasiva, incluso accidental, puede afectar disponibilidad, costos, logs, escalado o datos productivos.
26.3 Modelo de amenaza en contenedores
El modelo de amenaza debe cubrir desde el código fuente hasta la ejecución. Un atacante podría intentar abusar de una dependencia vulnerable, una imagen manipulada, credenciales de registro, permisos de despliegue, configuración insegura del runtime, secretos expuestos o permisos excesivos dentro del cluster.
El pentester debe ordenar estos caminos por impacto. No todos los hallazgos tienen la misma severidad: una imagen con paquetes desactualizados no equivale necesariamente a control del cluster, pero puede ser crítica si contiene una vulnerabilidad explotable en un servicio expuesto.
26.4 Imágenes de contenedor
Las imágenes son la base de ejecución. Deben revisarse origen, capas, usuario por defecto, paquetes instalados, dependencias, archivos sensibles, historial de construcción, etiquetas, firmas y escaneos de vulnerabilidades. Una imagen insegura puede replicarse en muchos entornos.
| Aspecto | Riesgo | Control recomendado |
|---|---|---|
| Imagen base | Componentes obsoletos o no confiables | Usar bases mantenidas, mínimas y verificadas |
| Capas | Archivos sensibles en historial | Construcciones limpias y revisión de artefactos |
| Usuario | Ejecución como root sin necesidad | Usuarios no privilegiados y permisos restrictivos |
| Dependencias | Vulnerabilidades conocidas | Escaneo continuo y actualización controlada |
26.5 Dockerfiles y buenas prácticas de construcción
El Dockerfile revela decisiones de seguridad: imagen base, instalación de paquetes, permisos, variables, secretos, usuario de ejecución, puertos, comandos y copias de archivos. Una construcción descuidada puede incluir herramientas innecesarias, credenciales temporales o permisos excesivos.
Las prácticas recomendadas incluyen imágenes base pequeñas, builds multi-stage, usuario no root, dependencias fijadas, limpieza de artefactos, no incluir secretos, permisos mínimos sobre archivos y separación entre construcción y ejecución.
26.6 Registros de imágenes
Los registros almacenan y distribuyen imágenes. Deben protegerse con autenticación fuerte, permisos por proyecto, escaneo, firma, retención, auditoría y controles contra sobrescritura indebida de etiquetas. Una imagen manipulada en el registro puede llegar a producción por un despliegue legítimo.
Durante la auditoría se revisa quién puede subir, borrar, etiquetar, promover o descargar imágenes. También se debe verificar si existen imágenes antiguas con vulnerabilidades, etiquetas ambiguas, artefactos huérfanos o repositorios accesibles públicamente sin justificación.
26.7 Firma, procedencia y cadena de suministro
La seguridad de la cadena de suministro busca confirmar que el artefacto desplegado proviene del código correcto y del pipeline esperado. Para eso se usan firmas, verificaciones de procedencia, políticas de admisión, registros inmutables, revisiones de dependencias y controles de aprobación.
Un hallazgo relevante aparece cuando producción acepta imágenes no firmadas, construidas fuera del pipeline, provenientes de registros no autorizados o etiquetadas de forma mutable. En esos casos, el riesgo no es solo técnico: afecta confianza, trazabilidad y gobernanza del despliegue.
26.8 Kubernetes: componentes y conceptos clave
Kubernetes organiza cargas en pods, namespaces, deployments, services, configmaps, secrets, ingress, service accounts, roles y otros objetos. El control plane administra el estado del cluster, mientras los nodos ejecutan las cargas. Cada componente introduce decisiones de seguridad.
Para auditar Kubernetes es necesario comprender qué recursos existen, qué permisos tienen, cómo se exponen, qué secretos consumen, qué redes pueden alcanzar y qué políticas limitan su comportamiento. Una revisión superficial de puertos no alcanza.
26.9 Namespaces y separación de entornos
Los namespaces ayudan a organizar recursos, pero no son una frontera fuerte por sí solos. La separación real depende de RBAC, políticas de red, cuotas, controles de admisión, cuentas de servicio, secretos y prácticas de despliegue.
Un pentest debe revisar si desarrollo, pruebas y producción comparten cluster, identidades o secretos; si una carga de un namespace puede comunicarse con servicios de otro; y si los permisos permiten observar o modificar recursos fuera del ámbito esperado.
26.10 RBAC y cuentas de servicio
RBAC define qué puede hacer una identidad sobre los recursos de Kubernetes. Las cuentas de servicio son usadas por pods y automatizaciones. Si una cuenta tiene permisos amplios, una vulnerabilidad en la aplicación puede convertirse en acceso a secretos, despliegues, configmaps o incluso administración del cluster.
La revisión debe buscar roles con comodines, permisos de escritura innecesarios, capacidad de crear pods, acceder a secretos, modificar bindings, usar cuentas privilegiadas o operar en todos los namespaces sin necesidad. La recomendación debe apuntar a permisos mínimos por carga.
26.11 Secrets y ConfigMaps
Kubernetes Secrets y ConfigMaps suelen contener configuración sensible o semisensible. Aunque los Secrets estén codificados y puedan integrarse con cifrado en reposo, el riesgo principal es quién puede leerlos, montarlos, copiarlos o exponerlos en variables de entorno y logs.
Una práctica madura usa gestores externos de secretos, rotación, permisos por aplicación, cifrado, auditoría y separación por entorno. En el pentest se debe evitar revelar valores completos cuando no es necesario para demostrar el riesgo.
26.12 Contexto de seguridad de pods
El contexto de seguridad define cómo se ejecuta un pod o contenedor: usuario, grupo, capacidades, sistema de archivos, privilegios, escalamiento, perfiles y restricciones. Ejecutar como root, permitir privilegios elevados o montar rutas sensibles del host aumenta el impacto de una vulnerabilidad.
La evaluación debe revisar si los pods usan usuarios no privilegiados, sistema de archivos de solo lectura cuando sea posible, capacidades mínimas, perfiles de aislamiento y restricciones que impidan comportamientos peligrosos por defecto.
26.13 Políticas de admisión
Los admission controllers permiten aceptar, rechazar o modificar objetos antes de que entren al cluster. Son útiles para impedir imágenes no confiables, contenedores privilegiados, ejecución como root, ausencia de límites de recursos, namespaces sin etiquetas o configuraciones que violen políticas internas.
En un entorno maduro, estas políticas no dependen solo de revisión manual. Deben automatizar controles mínimos para que errores frecuentes no lleguen a producción. El pentest puede verificar si las políticas existen, si se aplican a todos los namespaces relevantes y si generan evidencia auditable.
26.14 Políticas de red
Por defecto, muchos clusters permiten comunicación amplia entre pods. Las políticas de red ayudan a limitar qué cargas pueden comunicarse entre sí y hacia dónde pueden salir. Sin segmentación, una aplicación comprometida puede explorar servicios internos que nunca estuvieron pensados para exposición amplia.
La revisión debe identificar comunicaciones necesarias, reglas demasiado permisivas, ausencia de restricciones entre namespaces, acceso a bases de datos desde cargas no relacionadas y tráfico de salida sin control. La meta es reducir movimiento lateral y abuso de servicios internos.
26.15 Ingress, servicios y exposición externa
Los objetos Service e Ingress publican aplicaciones dentro o fuera del cluster. Deben revisarse TLS, autenticación, rutas, cabeceras, balanceadores, certificados, controladores de ingress, restricciones de origen y consistencia entre entornos.
Un riesgo común es exponer servicios administrativos, dashboards, métricas, endpoints internos o aplicaciones de prueba. La auditoría debe diferenciar exposición intencional, exposición accidental y exposición necesaria pero mal protegida.
26.16 Nodos y runtime de contenedores
Los nodos ejecutan las cargas y dependen del sistema operativo, runtime, configuración, parches, credenciales, integración cloud y agentes instalados. Una debilidad en el nodo puede afectar muchas aplicaciones, por lo que su endurecimiento es parte central de la seguridad del cluster.
La revisión debe considerar parches, acceso administrativo, separación de pools, etiquetas, taints, permisos de kubelet, logs, agentes de seguridad y exposición de servicios del nodo. En clusters administrados, parte de esta responsabilidad puede estar delegada al proveedor, pero la configuración del cliente sigue siendo clave.
26.17 Pipelines CI/CD como superficie de ataque
Un pipeline puede compilar, probar, firmar, publicar y desplegar aplicaciones. Si sus credenciales o permisos son excesivos, un cambio no revisado, una dependencia manipulada o una variable expuesta pueden terminar en producción. Por eso, CI/CD es parte de la superficie de pentesting.
Deben revisarse permisos de repositorio, aprobaciones, variables secretas, runners, artefactos, ramas protegidas, ambientes, roles de despliegue, integraciones externas y separación entre construir, publicar y desplegar.
26.18 Runners, agentes y permisos de despliegue
Los runners ejecutan trabajos de pipeline. Si están mal aislados, pueden mezclar proyectos, conservar artefactos sensibles, exponer variables o ejecutar código con permisos que exceden el repositorio. Los agentes de despliegue también deben limitarse al entorno y namespace correspondiente.
Una buena práctica es separar runners por criticidad, aplicar permisos mínimos, limpiar entornos entre jobs, evitar credenciales persistentes, registrar acciones y exigir aprobación para despliegues de alto impacto.
26.19 Escaneo y controles automatizados
Los controles automatizados pueden detectar vulnerabilidades en dependencias, secretos, imágenes, manifiestos, licencias, configuraciones inseguras y desviaciones de políticas. Sin embargo, el escaneo por sí solo no reemplaza el criterio: los resultados deben priorizarse por exposición, exploitabilidad e impacto.
Una revisión madura evalúa si los escaneos bloquean riesgos críticos, si existen excepciones documentadas, si los hallazgos se corrigen en tiempos razonables y si los equipos entienden el motivo de cada control.
26.20 Evidencia durante la auditoría
La evidencia debe incluir el recurso afectado, namespace, cuenta de servicio, manifiesto relevante, permiso, imagen, pipeline, configuración observada e impacto. Si se identifican secretos, se deben enmascarar y reportar de forma responsable, sin copiarlos ni usarlos fuera del alcance.
En Kubernetes y CI/CD, muchos hallazgos se demuestran mejor con configuración que con explotación. Un rol que permite leer secretos o un pipeline que puede desplegar a producción sin aprobación ya son evidencias suficientes si se explica el camino de impacto.
26.21 Riesgos típicos y controles
| Riesgo | Impacto | Control |
|---|---|---|
| Contenedor privilegiado | Mayor impacto si la aplicación se compromete | Políticas de admisión y contexto restrictivo |
| RBAC amplio | Lectura o modificación de recursos críticos | Roles mínimos por aplicación y namespace |
| Secretos en variables o logs | Exposición de credenciales reutilizables | Gestor de secretos, rotación y enmascaramiento |
| Imagen sin control | Despliegue de artefactos vulnerables o no confiables | Firma, procedencia y escaneo bloqueante |
| Pipeline sin aprobaciones | Cambios de alto impacto sin revisión | Ramas protegidas, revisiones y ambientes controlados |
26.22 Remediación y endurecimiento
La remediación debe tratar la cadena completa. Corregir un manifiesto ayuda, pero también se necesitan plantillas seguras, políticas de admisión, controles en CI/CD y monitoreo para impedir regresiones.
- Usar imágenes base mínimas, mantenidas y verificadas.
- Ejecutar contenedores con usuarios no privilegiados y capacidades mínimas.
- Aplicar RBAC por necesidad real y revisar cuentas de servicio.
- Separar namespaces, entornos, secretos y permisos de despliegue.
- Implementar políticas de red con criterio de mínimo acceso.
- Firmar imágenes y validar procedencia antes de desplegar.
- Proteger runners, variables, artefactos y aprobaciones de pipelines.
- Centralizar logs, alertas y auditoría de cambios críticos.
26.23 Flujo práctico de revisión
Un flujo de pentesting para contenedores y Kubernetes empieza por inventario y permisos de lectura, luego avanza sobre imágenes, manifiestos, RBAC, secretos, red, exposición, nodos, políticas y CI/CD. Los hallazgos se agrupan por camino de impacto y no solo por objeto técnico.
- Confirmar alcance de clusters, namespaces, registros, repositorios y pipelines.
- Inventariar imágenes, workloads, servicios, ingress, secretos y cuentas.
- Revisar Dockerfiles, imágenes base, dependencias, firmas y vulnerabilidades.
- Analizar RBAC, cuentas de servicio y permisos entre namespaces.
- Validar contexto de seguridad, privilegios y políticas de admisión.
- Evaluar políticas de red, exposición externa y acceso administrativo.
- Revisar pipelines, runners, variables, aprobaciones y roles de despliegue.
- Documentar evidencia, impacto, causa y remediación priorizada.
26.24 Errores frecuentes
Un error común es confiar en que Kubernetes protege automáticamente las aplicaciones. Kubernetes ofrece mecanismos, pero si RBAC, red, admission control, secretos y runtime quedan abiertos, el cluster puede amplificar el impacto de fallas de aplicación.
Otro error es tratar el pipeline como una herramienta administrativa externa al pentest. En realidad, quien controla el pipeline puede controlar lo que se construye, firma, publica y despliega. Por eso debe formar parte de la revisión cuando está dentro del alcance.
26.25 Qué debes recordar
La seguridad de contenedores no termina en la imagen. Incluye construcción, registro, firma, despliegue, ejecución, red, identidad, secretos, monitoreo y gobierno del cambio. Cada etapa puede reducir o aumentar el riesgo de la siguiente.
En Kubernetes, los hallazgos más importantes suelen combinar permisos, contexto de ejecución, exposición de red y secretos. En CI/CD, el riesgo se concentra en quién puede introducir cambios y con qué credenciales se despliegan.
26.26 Conclusión
Contenedores, Kubernetes y pipelines permiten desplegar con velocidad, pero requieren controles consistentes en toda la cadena. Un pentest efectivo debe mirar artefactos, configuración, permisos, separación, secretos, exposición y trazabilidad, siempre con autorización y evidencia responsable.
En el próximo tema veremos ingeniería social autorizada, phishing controlado y concientización, una dimensión distinta del ethical hacking donde el factor humano debe evaluarse con cuidado, límites y objetivos formativos.