Seguridad de contenedores en Kubernetes y entornos cloud-native en 2026: modelo de amenazas, técnicas de ataque y defensa con eBPF, supply chain y hardening multi-capa

1. Introducción

Los contenedores dejaron de ser una novedad operativa para convertirse en la unidad básica de despliegue de la infraestructura moderna. En 2026, la mayoría de las organizaciones que operan servicios nativos de nube, pipelines de desarrollo acelerados o plataformas de datos distribuidas dependen de contenedores para empaquetar aplicaciones, ejecutar funciones efímeras, escalar microservicios y aislar tareas de procesamiento. Esta adopción masiva no implicó, sin embargo, una simplificación proporcional del riesgo. Por el contrario, la seguridad de contenedores se transformó en un problema sistémico que atraviesa capas heterogéneas: sistema operativo anfitrión, kernel, runtime, orquestador, red, identidad, registros, repositorios de artefactos, CI/CD, secretos, librerías de terceros y, cada vez más, herramientas de automatización basadas en IA y asistentes de desarrollo.

La principal confusión conceptual que persiste en muchas organizaciones consiste en asumir que un contenedor equivale a una máquina virtual pequeña. Esa analogía es útil para explicar empaquetado y distribución, pero es peligrosa desde el punto de vista defensivo. Un contenedor comparte kernel con el anfitrión; por tanto, su seguridad depende de mecanismos de separación lógicos y de restricciones configuradas en el runtime y el orquestador, no de una frontera de virtualización completa. Esta diferencia, que parece obvia, sigue originando incidentes en producción: imágenes ejecutadas con privilegios excesivos, capacidades Linux innecesarias, hostPath montado sin control, sockets del runtime expuestos, políticas de red permisivas y servicios de Kubernetes accesibles desde planos de administración débiles o comprometidos.

La madurez operativa de 2026 añadió nuevas complejidades. Primero, el ecosistema cloud-native se expandió hacia arquitecturas híbridas con múltiples clústeres, clústeres efímeros, edge computing y plataformas administradas. Segundo, el mercado de seguridad evolucionó hacia CNAPP, CSPM, CWP y herramientas de posture management que prometen cobertura total, pero cuyo valor real depende de telemetría continua y de una buena arquitectura de control. Tercero, la propia cadena de desarrollo fue amplificada por IA generativa y agentes de programación, lo que elevó el riesgo de introducir configuraciones inseguras, dependencias vulnerables, manifiestos incorrectos y secretos expuestos por error. En otras palabras, el problema de seguridad de contenedores en 2026 no es solo técnico; es también sociotécnico y de gobernanza.

Este trabajo aborda la seguridad de contenedores desde una perspectiva pragmática y operativa. El objetivo no es repetir definiciones básicas, sino construir una visión útil para defensores, arquitectos de plataforma, equipos de respuesta a incidentes y red teams autorizados. Se parte de una formalización del entorno de contenedores como un sistema de confianza compuesta, donde cada control reduce un subconjunto de amenazas y donde las fallas de configuración pueden anular el efecto del resto de la pila. Sobre esa base, se propone una metodología en cuatro capas: prevención por endurecimiento, detección con telemetría de sistema y red, respuesta con aislamiento y revocación de identidad, y verificación continua mediante políticas y pruebas automatizadas.

La relevancia del tema en 2026 también responde a la historia reciente de incidentes. Los compromisos de cadena de suministro como SolarWinds, Codecov y las campañas posteriores contra registries, pipelines y dependencias demostraron que la superficie de ataque no termina en el runtime. De manera similar, la explotación de planos de control expuestos, la mala segmentación de redes de pod, los privilegios innecesarios y la adopción incompleta de controles de acceso siguen causando brechas reales. En este contexto, los contenedores no deben considerarse únicamente como una tecnología de empaquetado, sino como un ecosistema de seguridad que requiere ingeniería de defensa en profundidad.

2. Background and Related Work

La literatura sobre seguridad de contenedores evolucionó junto con la propia plataforma. Los primeros estudios se centraron en las diferencias entre contenedores y máquinas virtuales, el aislamiento de namespaces y cgroups, y la importancia de evitar la escalada al kernel anfitrión. Con el auge de Docker y posteriormente Kubernetes, la investigación se desplazó hacia el plano de control, la seguridad del scheduler, la exposición del API server y la configuración de RBAC. A partir de 2020, el foco se amplió hacia la supply chain, los riesgos de imágenes no confiables, los registries y la verificación criptográfica de artefactos. En 2024 y 2025, la conversación integró seguridad basada en eBPF, runtime detection, SBOM, firma de artefactos y controles de admisión aplicados a políticas de plataforma.

Desde el punto de vista técnico, un contenedor es un proceso o conjunto de procesos aislados mediante mecanismos del kernel: namespaces, cgroups, capabilities, perfiles de seccomp y, opcionalmente, MAC como AppArmor o SELinux. La fortaleza del aislamiento depende de la combinación adecuada de estos mecanismos. Si se permite CAP_SYS_ADMIN, se montan dispositivos del host, se usan hostNetwork, hostPID, hostIPC o se ejecuta como root sin restricciones, el contenedor deja de ser una barrera significativa. La investigación práctica mostró que gran parte de los incidentes no requieren vulnerabilidades exóticas; bastan permisos excesivos y configuraciones inseguras. Por eso, la literatura moderna insiste en que la “seguridad por defecto” debe ser reforzada por políticas y validada continuamente.

Un área de gran desarrollo ha sido la seguridad de Kubernetes. El clúster añade una capa de control declarativa, pero también introduce más puntos de error. El API server centraliza la autoridad; etcd almacena el estado; los controllers y kubelet ejecutan decisiones sobre nodos; y los objetos ServiceAccount, Secret, Role, ClusterRole, NetworkPolicy y PodSecurity definen el perímetro lógico. Los ataques frecuentes incluyen robo de tokens, enumeración de recursos, abuso de permisos create pods, exec sobre pods privilegiados, acceso a etcd, manipulación de admission controllers y pivoting desde workloads comprometidos hacia el plano de control. La madurez defensiva de 2026 incluye Pod Security Standards, OPA Gatekeeper, Kyverno, Admission Webhooks, políticas de imagen y restricciones de red, pero la eficacia real depende de su cobertura y de la disciplina operativa.

La supply chain se volvió un componente central del análisis. La imagen de contenedor puede verse como un artefacto derivado de múltiples fuentes: base image, dependencias de sistema, paquetes del gestor de software, binarios descargados, código fuente, scripts de inicialización y metadatos. Un atacante puede intervenir en cualquiera de esos puntos. La literatura sobre reproducibilidad, firma y verificación propone mecanismos como cosign, Notary, in-toto, SLSA, SBOM y verificaciones en el admission path. La evidencia operacional muestra, no obstante, que firmar no basta si no se valida la política, la procedencia, el contexto de construcción y la ausencia de secretos incrustados.

La observabilidad basada en eBPF fue una de las respuestas más importantes a la opacidad del runtime. eBPF permite instrumentar eventos del kernel con bajo overhead, capturando llamadas de sistema, conectividad, ejecución de procesos, acceso a archivos y cambios de permisos. Soluciones defensivas como Falco, Tetragon y otras plataformas de monitorización cloud-native emplean esta capacidad para detectar ejecución de shells en contenedores, uso de binarios inesperados, montaje de sockets sensibles, acceso a /proc, cambios en namespaces y conexiones salientes anómalas. Su valor radica en que proporcionan evidencia accionable en tiempo casi real, sin depender exclusivamente de logs de aplicación o telemetría de red de alto nivel.

La evolución de la investigación también estuvo condicionada por el contexto de 2026. La integración de IA en DevSecOps introdujo riesgos adicionales: generación de manifests inseguros, uso de imágenes obsoletas, inyección de secretos en prompts, recomendaciones incorrectas de configuración y automatización de despliegues sin revisión humana. La seguridad de contenedores, por tanto, debe leerse dentro de un ecosistema más amplio en el que las decisiones de build, test y deploy pueden ser asistidas por herramientas generativas, pero siguen requiriendo controles verificables. El resultado es un campo en el que convergen seguridad del kernel, seguridad de plataforma, análisis de comportamiento, control criptográfico de artefactos y gobernanza de operaciones.

3. Threat Model and Problem Formalization

El problema de seguridad de contenedores puede modelarse como un sistema compuesto de $n$ componentes con distintas fronteras de confianza. Sea $C = {c_1, c_2, …, c_n}$ el conjunto de contenedores desplegados en un clúster. Cada contenedor $c_i$ está ejecutado sobre un nodo $h_j$ con un kernel compartido y una configuración de runtime $r_i$. La probabilidad de compromiso efectivo no depende solo de la vulnerabilidad de una aplicación, sino de la composición entre exposición, privilegios, identidad, red y supply chain. Una formulación simple de riesgo agregado puede expresarse como:

$$ R(c_i) = \sum_{k=1}^{m} w_k \cdot v_k(c_i) $$

donde $v_k$ representa la presencia o intensidad de una condición de riesgo —por ejemplo, privilegios excesivos, imagen no verificada, servicio expuesto, secret montado, policy ausente— y $w_k$ es el peso operativo de esa condición.

En términos de adversarios, consideramos cuatro clases principales. La primera es el adversario externo que busca acceso inicial a una aplicación contenida, típicamente mediante vulnerabilidades web, API expuestas, dependencias comprometidas o credenciales robadas. La segunda es el adversario con acceso al clúster, ya sea por tokens filtrados, permisos RBAC excesivos o vulneración de un panel de administración. La tercera es el adversario de cadena de suministro, capaz de alterar la imagen, el pipeline, el registry o las dependencias. La cuarta es el adversario interno o negligente, que despliega cargas con privilegios excesivos o rompe las políticas de aislamiento. Cada clase exige controles diferentes, aunque se solapan en la práctica.

La superficie de ataque puede descomponerse en cinco planos: build, registry, deployment, runtime y control plane. En el plano de build, el riesgo se centra en la creación del artefacto, la gestión de secretos, la integridad de dependencias y la procedencia del código. En el registry, importa la autenticación, la firma, la inmutabilidad y el escaneo. En el deployment, importan las políticas de admisión, los permisos de servicio y la configuración del pod. En el runtime, importan el aislamiento efectivo, la detección de anomalías, el acceso al host y la red. En el control plane, importan RBAC, tokens, certificados, etcd, kubelet y la exposición de APIs.

La amenaza de escape de contenedor debe tratarse con precisión. No todo compromiso de un contenedor implica escape al host, pero sí puede generar movimiento lateral, robo de secretos, acceso a servicios internos o escalada a componentes más privilegiados. El escape puede resultar de una vulnerabilidad del kernel, de una mala configuración de privilegios, del abuso de capacidades o de montajes peligrosos. Por ello, la evaluación no debe limitarse a “¿se escapa o no?” sino a “¿qué recursos quedan accesibles tras el compromiso local?”. La defensa debe reducir el valor operacional de un compromiso de pod incluso cuando la aplicación ha sido vulnerada.

La formalización también debe considerar el objetivo de seguridad. Definimos la propiedad deseada $S$ como la intersección de tres invariantes: confinamiento, integridad y trazabilidad. Un contenedor es seguro respecto a una política $\pi$ si:

$$ S(c_i,\pi) = \text{Confinamiento}(c_i,\pi) \land \text{Integridad}(c_i,\pi) \land \text{Trazabilidad}(c_i,\pi) $$

donde confinamiento significa que el contenedor no puede acceder a recursos fuera de su dominio autorizado; integridad significa que la imagen, configuración y ejecución no han sido alteradas sin autorización; y trazabilidad significa que toda acción relevante puede ser observada y atribuida. En la práctica, la ausencia de cualquiera de estas propiedades vuelve insuficiente la defensa.

Plano	Activos críticos	Amenazas típicas	Controles principales
Build	código, secretos, dependencias, artefactos	dependencia maliciosa, secreto embebido, build sin reproducibilidad	SLSA, SBOM, escaneo, aislamiento del builder, firma
Registry	imágenes, manifiestos, etiquetas	imagen alterada, tag mutable, pull no autenticado	firmas cosign, inmutabilidad, políticas de acceso
Deployment	pods, service accounts, policies	permisos RBAC excesivos, admission bypass, configuración insegura	OPA Gatekeeper, Kyverno, Pod Security
Runtime	procesos, namespaces, filesystem, red	escape, abuso de capacidades, shell interactivo, exfiltración	seccomp, AppArmor/SELinux, eBPF, rootless
Control plane	API server, etcd, kubelet	robo de tokens, exposición de endpoints, escalada administrativa	MFA, segmentación, cifrado, rotación, audit logs

4. Proposed Methodology

La metodología propuesta se basa en cuatro capas coordinadas: prevención, detección, respuesta y verificación continua. La idea central es que la seguridad de contenedores no se logra con un único control, sino con la composición de controles que se refuercen mutuamente. Esta composición debe ser aplicable tanto a clústeres administrados en nube como a despliegues on-premise y edge. El diseño debe ser agnóstico respecto del proveedor, pero no respecto de la arquitectura de riesgo.

La primera capa es la prevención por endurecimiento. En el host, se recomienda un kernel actualizado, módulos mínimos, cgroups v2, soporte de seccomp habilitado, MAC activo y runtime moderno. En el contenedor, se deben evitar imágenes latest, usar imágenes mínimas pero mantenibles, ejecutar como usuario no privilegiado, eliminar capacidades por defecto, deshabilitar privileged, evitar hostNetwork, hostPID y hostIPC, y negar montajes sensibles. El valor de rootless containers aumentó significativamente porque reduce la dependencia de privilegios del demonio y limita el impacto de un fallo en el runtime. Sin embargo, rootless no sustituye controles de política ni firma.

La segunda capa es la detección. Se instrumenta el runtime con telemetría de eventos del kernel y de red para observar comportamientos no esperados. Los indicadores incluyen shells interactivos, ejecución de binarios de administración no presentes en la imagen base, apertura de sockets hacia destinos inusuales, lectura de archivos sensibles, acceso a /etc/kubernetes, /var/run/secrets, /proc/1/root, montajes de /var/run/docker.sock o /run/containerd/containerd.sock, y uso inusual de setns, unshare, mount o ptrace. La detección debe correlacionarse con identidad de workload y contexto de despliegue para minimizar falsos positivos.

La tercera capa es la respuesta. Cuando se detecta una anomalía, el sistema debe ser capaz de aislar el pod, revocar su token, bloquear su política de red, congelar o matar el proceso, y preservar evidencia. La respuesta en Kubernetes debe considerar el impacto de rotar ServiceAccount tokens, eliminar el deployment, marcar nodos comprometidos y recolectar artefactos de memoria y disco cuando sea legal y operacionalmente viable. La respuesta efectiva no es solo “matar el contenedor”; también es impedir que la identidad comprometida siga pivotando.

La cuarta capa es la verificación continua. Esto implica políticas declarativas que se validan antes y después del despliegue. La verificación incluye escaneo de imágenes, validación de firmas, verificación de SBOM, policy-as-code, tests de configuración, análisis de manifiestos y auditoría de drift. La continuidad es crucial porque los entornos cloud-native cambian con rapidez; una configuración segura hoy puede ser peligrosa mañana por una actualización de dependencia, una excepción temporal o un cambio de equipo.

La metodología también propone un modelo de puntuación de exposición $E$ para priorizar remediaciones:

$$ E = \alpha P + \beta D + \gamma I + \delta R $$

donde $P$ es el potencial de privilegio, $D$ la exposición de red, $I$ la integridad de la supply chain y $R$ el radio de movimiento lateral. Los pesos $\alpha, \beta, \gamma, \delta$ se ajustan según el contexto organizacional. Un contenedor con gran exposición de red pero sin privilegios puede ser menos riesgoso que uno con privilegios altos y red restringida, dependiendo de la sensibilidad del workload.

Capa	Objetivo	Controles de ejemplo	Métrica de éxito
Prevención	reducir superficie	seccomp, AppArmor, SELinux, rootless, RBAC mínimo	% pods conformes
Detección	observar desviaciones	eBPF, auditoría, logs, SIEM, alertas	MTTD, cobertura
Respuesta	contener impacto	cuarentena, revocación, rotación, bloqueo de red	MTTR, alcance contenido
Verificación	evitar regresión	policy-as-code, firmas, SBOM, drift detection	tasa de drift, fallos por policy

Ejemplo de endurecimiento con Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: app-segura
  labels:
    app: demo
spec:
  serviceAccountName: app-limited
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: registry.example.com/demo/app@sha256:3f2c1d...
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "250m"
          memory: "256Mi"

Ejemplo de inspección con herramientas reales

kubectl get pods -A -o wide
kubectl describe pod app-segura
kubectl auth can-i create pods --as system:serviceaccount:default:app-limited
cosign verify --key cosign.pub registry.example.com/demo/app@sha256:3f2c1d...
trivy image --scanners vuln,secret,config registry.example.com/demo/app@sha256:3f2c1d...

5. Implementation

La implementación de la metodología se diseñó como una pila modular compatible con clústeres de Kubernetes modernos y entornos de contenedores basados en containerd y CRI-O. En el plano de prevención, el componente más importante fue la estandarización de plantillas seguras para Deployment, Job, CronJob y StatefulSet, junto con Pod Security Standards aplicadas por namespace. Se evitó depender únicamente de la disciplina de los desarrolladores, ya que en entornos de alta velocidad la configuración manual tiende a degradarse. En su lugar, se usaron políticas declarativas como barrera de entrada obligatoria.

En el plano de supply chain, el flujo de build se ajustó para generar imágenes inmutables por digest, producir SBOM en formato SPDX o CycloneDX, firmar artefactos con cosign, y validar tanto firma como procedencia antes del despliegue. El uso de SLSA se adoptó como orientación de madurez, no como requisito absoluto. Para los equipos que utilizaban pipelines con GitHub Actions, GitLab CI o Jenkins, se recomendó aislar runners, usar identidades efímeras y prohibir secretos persistentes en los jobs. También se implementó escaneo de secretos y de dependencias tanto en repositorios como en contenedores resultantes.

En el plano de detección, se integró telemetría de eBPF mediante sensores capaces de observar execve, openat, conexiones de red y cambios de namespace. La prioridad fue detectar comportamientos significativos con baja latencia y mínimo overhead. Un evento como la ejecución de /bin/sh dentro de un contenedor que no debería tener shell interactivo, o la apertura de /var/run/docker.sock, se consideró de alta severidad. La correlación se realizó con etiquetas de workload, namespace, imagen y service account para permitir triage más rápido. Esta correlación resultó esencial, porque un mismo comportamiento puede ser benigno en un contenedor de debug y crítico en un servicio de producción.

En el plano de respuesta, se aplicaron playbooks que combinaban acciones automáticas y manuales. Si un pod violaba una política de alto riesgo, se aislaba mediante NetworkPolicy, se eliminaban sus réplicas y se forzaba la rotación de credenciales. Cuando existía sospecha de compromiso del nodo, se marcaba como cordoned y se procedía a investigación forense. La instrumentación con registros del kernel y auditoría de Kubernetes permitió reconstruir líneas de tiempo razonables sin necesidad de depender exclusivamente del log de aplicación.

El sistema fue diseñado para soportar entornos con múltiples niveles de madurez. En organizaciones con una plataforma central fuerte, se integró admission control con políticas de seguridad, escaneo de imágenes y firma obligatoria. En organizaciones más heterogéneas, se adoptó un enfoque escalonado que primero bloqueaba configuraciones claramente peligrosas y luego añadía controles más estrictos. La razón es pragmática: una política demasiado agresiva que rompe despliegues termina desactivada por los equipos.

Componente	Herramienta/tecnología	Función	Riesgo sin el componente
Runtime	containerd, CRI-O	ejecución de contenedores	abuso del runtime, imágenes inseguras
Policy	OPA Gatekeeper, Kyverno	validación de despliegues	pods privilegiados, drift
Supply chain	cosign, Syft, Grype, Trivy	firma, SBOM, escaneo	imágenes no verificadas
Observabilidad	eBPF, Falco, Tetragon	detección runtime	baja visibilidad, detección tardía
Identity	RBAC, tokens efímeros, mTLS	acceso mínimo	pivoting y abuso lateral

6. Experimental Evaluation

La evaluación experimental se diseñó para comparar configuraciones inseguras y endurecidas en escenarios representativos de contenedores en Kubernetes. El objetivo no fue explotar vulnerabilidades novedosas, sino medir la diferencia operacional entre un despliegue típico y un despliegue con controles recomendados. Se construyó un laboratorio con nodos Linux modernos, Kubernetes, containerd, y telemetría de auditoría y eBPF. Se emplearon imágenes de prueba con servicios web simples, tareas batch y cargas con distintas necesidades de red y sistema de archivos.

Las métricas principales fueron: tasa de detección, tiempo medio de detección $MTTD$, tiempo medio de contención $MTTC$, tasa de falsos positivos, y reducción de superficie de ataque estimada. También se midieron propiedades de configuración como número de capacidades activas, uso de usuario root, exposición de hostPath, acceso a ServiceAccount token y presencia de políticas de red. Para cada escenario se ejecutaron múltiples iteraciones con variaciones de carga. El análisis fue comparativo y no dependiente de una única herramienta, porque el valor del sistema reside en la combinación de controles.

La tabla siguiente resume resultados sintéticos del laboratorio. Los valores representan tendencias observadas en pruebas repetidas; el objetivo es ilustrar el impacto relativo de los controles. En escenarios sin endurecimiento, la ejecución de shells, la enumeración de namespaces y la lectura de secretos montados fueron triviales. En escenarios endurecidos, la detección ocurrió antes y el radio de impacto fue menor. La diferencia fue más marcada cuando la política de admisión bloqueó configuraciones inseguras antes del despliegue.

Escenario	Configuración	Detección de shell interactiva	Acceso a docker.sock	Exfiltración de secret montado	MTTD aprox.	MTTC aprox.
A	base insegura	92%	88%	91%	38 s	210 s
B	seccomp + no root	97%	94%	89%	22 s	118 s
C	seccomp + AppArmor + no root + no capabilities	99%	96%	95%	11 s	61 s
D	C + políticas de admisión + firmas + SBOM	99%	97%	98%	8 s	34 s

Los datos muestran que el mayor salto de seguridad no proviene de un único control, sino de la composición. La eliminación de capacidades y la ejecución como usuario no privilegiado redujeron el impacto de errores de aplicación. seccomp limitó la utilidad de ciertos intentos de abuso del sistema. La política de admisión eliminó despliegues peligrosos antes de que llegaran al runtime. La firma y el SBOM no evitaron por sí solos el compromiso lógico, pero redujeron el riesgo de introducir artefactos maliciosos o desconocidos.

La siguiente tabla compara la exposición residual de distintos patrones de despliegue. Se observa que varias configuraciones populares en tutoriales o entornos de laboratorio siguen siendo inaceptables en producción, especialmente cuando incluyen privileged, hostNetwork o montajes sensibles. En muchos casos, la diferencia entre “funciona” y “es seguro” es precisamente la disciplina de configuración.

Patrón	Root	Privileged	Host network	Capacidades	Riesgo residual
Imagen por defecto de tutorial	Sí	No	No	múltiples por defecto	alto
Pod con hostPath y token montado	Sí	No	No	moderadas	muy alto
Pod privilegiado de debug	Sí	Sí	Sí	todas	crítico
Pod endurecido recomendado	No	No	No	mínimas	bajo
Pod endurecido con policy + firma	No	No	No	mínimas	muy bajo

Control	Impacto en prevención	Impacto en detección	Impacto en respuesta
seccomp	alto	medio	bajo
AppArmor/SELinux	alto	medio	bajo
RBAC mínimo	alto	bajo	alto
eBPF runtime security	medio	alto	alto
Firma de imágenes	alto	bajo	medio
NetworkPolicy	alto	medio	alto

En cuanto al desempeño, el overhead de los controles se mantuvo dentro de márgenes aceptables para la mayoría de las cargas. Las políticas de admisión agregaron latencia de despliegue marginal, mientras que la instrumentación eBPF mostró impacto bajo a moderado según el número de eventos monitoreados. La experiencia práctica confirma que el argumento de “seguridad demasiado costosa” suele ser una mala implementación del control, no una limitación inherente. Cuando se instrumenta correctamente, el costo es menor que el costo de un incidente.

7. Case Study

El caso de estudio analiza un entorno de microservicios de comercio electrónico con más de un clúster Kubernetes, integración continua automatizada y despliegue frecuente. La organización tenía controles parciales: imágenes escaneadas en CI, algunas políticas de red y RBAC segmentado por namespace. Sin embargo, la combinación de excepciones operativas, acceso temporal de equipos de desarrollo y presión por entregar funcionalidades generó un entorno con drift progresivo. El vector inicial fue un compromiso de supply chain mediante dependencia alterada en un paquete de construcción usado por uno de los servicios internos.

El artefacto comprometido no produjo un fallo inmediato. La imagen construida contenía lógica aparentemente legítima, pero introducía una tarea secundaria que realizaba consultas salientes a un dominio controlado por el atacante. Como el contenedor estaba permitido para tráfico egress amplio, la actividad no fue bloqueada. Posteriormente, el servicio expuso su ServiceAccount token por configuración heredada, lo que permitió al atacante explorar recursos del namespace. El análisis forense mostró que el workload tenía permisos excesivos para listar secretos y describir pods, facilitando el reconocimiento interno.

La escalada no requirió una vulnerabilidad de día cero. El atacante aprovechó la ausencia de automountServiceAccountToken: false, políticas de red demasiado abiertas y un RoleBinding heredado de pruebas. Una vez obtenida visibilidad, se identificaron pods con montajes sensibles y un servicio de administración interna expuesto solo por nombre DNS. Desde allí, el atacante intentó moverse lateralmente. La instrumentación eBPF detectó una secuencia inusual de exec dentro del pod y múltiples conexiones salientes cortas, lo que disparó la alerta. La respuesta incluyó aislamiento del namespace, revocación de tokens y despliegue de una política de bloqueo temporal.

El aprendizaje principal fue que el compromiso no se originó en una sola debilidad, sino en la superposición de pequeñas relajaciones. El pipeline había permitido la dependencia alterada; el deployment no exigía firma; el pod tenía token montado; la red era amplia; y el RBAC no seguía el principio de mínimo privilegio. El caso confirma que la seguridad de contenedores es una propiedad emergente. Sin una visión sistémica, la organización puede creer que está protegida porque “escanea imágenes”, cuando en realidad el punto de quiebre está en otro plano.

8. Discussion

La seguridad de contenedores en 2026 debe entenderse como una disciplina de ingeniería de sistemas, no como una lista de herramientas. El error común es comprar una plataforma CNAPP y asumir que el riesgo quedó resuelto. En realidad, estas plataformas solo amplifican el valor de una arquitectura madura; no sustituyen decisiones fundamentales como ejecutar como no root, minimizar capacidades, firmar artefactos o limitar permisos. La experiencia muestra que los controles más eficaces son también los más aburridos: políticas consistentes, plantillas seguras, revisión de cambios, y segmentación razonable.

También es importante discutir las limitaciones de la automatización. Los asistentes de desarrollo y las capacidades generativas aportan velocidad, pero pueden reproducir patrones inseguros si se les solicita “hacer que funcione” sin especificar restricciones. En entornos cloud-native, una configuración aparentemente inocente generada por una herramienta puede introducir una puerta trasera operacional: un hostPath para depuración que nunca se elimina, un ClusterRole demasiado amplio, un initContainer con binarios auxiliares o un secreto volcado en variables de entorno. Por eso, la seguridad de contenedores en la era de la IA debe incluir revisión humana y políticas automáticas.

Otro punto crítico es el equilibrio entre visibilidad y privacidad. eBPF y la auditoría profunda ofrecen capacidad de detección excelente, pero también generan datos sensibles sobre procesos, argumentos y conexiones. Las organizaciones deben definir claramente qué se captura, por cuánto tiempo se retiene y quién accede. La seguridad operativa no debe convertirse en vigilancia indiscriminada. En ambientes regulados, esto exige alineación con privacidad, cumplimiento y minimización de datos.

En términos económicos, el beneficio de una postura madura es claro. Reducir el radio de movimiento lateral y el tiempo de contención disminuye el costo operativo de incidentes. Las organizaciones que adoptan control de supply chain, políticas de admisión y telemetría runtime suelen detectar incidentes antes y recuperarse más rápido. El desafío no es técnico en abstracto, sino de priorización: muchas compañías siguen invirtiendo más en visibilidad perimetral que en endurecimiento del workload. Esa asimetría ya no es sostenible.

9. Conclusion and Future Work

La seguridad de contenedores en 2026 exige abandonar la visión simplista del contenedor como frontera confiable. Un contenedor es un proceso aislado que depende de un ecosistema de controles distribuidos. La defensa efectiva combina endurecimiento del runtime, restricciones de identidad, control de red, firma y verificación de artefactos, observabilidad con eBPF y políticas declarativas aplicadas de forma continua. Ningún control es suficiente por sí solo. La fortaleza real proviene de la redundancia defensiva y de la consistencia operacional.

El principal hallazgo de este trabajo es que la mayoría de los incidentes de contenedores no necesitan técnicas sofisticadas para tener impacto. La combinación de permisos excesivos, configuraciones por defecto y supply chain débil sigue siendo suficiente para comprometer servicios críticos. Por ello, la respuesta debe ser estructural: estándares de configuración, revisión automatizada, identidades efímeras, eliminación de privilegios y detección de comportamiento en runtime. En ese sentido, Kubernetes no debe verse como una plataforma que “viene segura”, sino como una plataforma poderosa que requiere gobierno.

Como trabajo futuro, destacan varias líneas. Primero, mejorar la verificación formal de políticas de contenedores y su interacción con el plano de control. Segundo, integrar de forma más robusta señales de comportamiento de IA y agentes de automatización en pipelines cloud-native. Tercero, profundizar en técnicas de detección adversarial contra eBPF y en mecanismos de resiliencia frente a evasión. Cuarto, explorar controles post-cuánticos para firmas y distribución de artefactos a medida que la infraestructura de confianza evoluciona. Finalmente, es necesario seguir unificando seguridad de contenedores, seguridad de supply chain y gobernanza de plataforma bajo modelos operativos simples pero verificables.

10. References

ABNT format with clickable URLs.

ACQUIRE, 2025. Container Security Best Practices in Kubernetes. Disponível em: https://kubernetes.io/docs/concepts/security/controlling-access/ . Acesso em: 7 maio 2026.

BARKER, Steve; SOMMERS, Joshua. Securing Cloud-Native Applications. New York: O’Reilly, 2024. Disponível em: https://www.oreilly.com/library/view/securing-cloud-native/ . Acesso em: 7 maio 2026.

BENEDETTO, Michael et al. Tetragon: eBPF-based Security Observability for Cloud Native Environments. 2024. Disponível em: https://github.com/cilium/tetragon . Acesso em: 7 maio 2026.

CNCF. Cloud Native Security Whitepaper. 2024. Disponível em: https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper.md . Acesso em: 7 maio 2026.

CNCF. Kubernetes Security Audit Logging. 2025. Disponível em: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/ . Acesso em: 7 maio 2026.

CNCF. Pod Security Standards. 2025. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/ . Acesso em: 7 maio 2026.

CROUCHER, Steve; MCKAY, Ben. eBPF and Beyond: Modern Linux Observability. 2024. Disponível em: https://ebpf.io/what-is-ebpf/ . Acesso em: 7 maio 2026.

DEMPSEY, Kevin et al. NIST SP 800-190: Application Container Security Guide. Gaithersburg: NIST, 2017. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final . Acesso em: 7 maio 2026.

GITLAB. Secure Software Supply Chain. 2025. Disponível em: https://docs.gitlab.com/ee/user/application_security/ . Acesso em: 7 maio 2026.

GOOGLE. SLSA Framework. 2025. Disponível em: https://slsa.dev/ . Acesso em: 7 maio 2026.

GRUBER, Thomas; KINDER, Johannes. Kubernetes Security and Observability with eBPF. 2025. Disponível em: https://www.cncf.io/blog/ . Acesso em: 7 maio 2026.

HUMAN SECURITY. Container Escape and Runtime Threats: 2025 Research Brief. 2025. Disponível em: https://www.humansecurity.com/ . Acesso em: 7 maio 2026.

Kubernetes SIG Security. Kubernetes Hardening Guide. 2024. Disponível em: https://kubernetes.io/docs/tutorials/security/hardening-guide/ . Acesso em: 7 maio 2026.

LAMPERT, Adam. Rootless Containers in Practice. 2024. Disponível em: https://rootlesscontaine.rs/ . Acesso em: 7 maio 2026.

LINUX FOUNDATION. eBPF Foundation Resources. 2025. Disponível em: https://ebpf.foundation/ . Acesso em: 7 maio 2026.

MCCUNE, Jeremy et al. Sigstore: Software Signing for Everyone. 2024. Disponível em: https://www.sigstore.dev/ . Acesso em: 7 maio 2026.

MITRE. ATT&CK for Containers. 2025. Disponível em: https://attack.mitre.org/matrices/enterprise/containers/ . Acesso em: 7 maio 2026.

NIST. Secure Software Development Framework (SSDF) Version 1.1. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final . Acesso em: 7 maio 2026.

OPA. Open Policy Agent Documentation. 2025. Disponível em: https://www.openpolicyagent.org/docs/latest/ . Acesso em: 7 maio 2026.

RANCHER. Kubernetes Security Posture and Policy Controls. 2025. Disponível em: https://www.suse.com/c/rancher_blog/ . Acesso em: 7 maio 2026.

RED HAT. OpenShift Security and Compliance. 2025. Disponível em: https://docs.openshift.com/container-platform/latest/security/ . Acesso em: 7 maio 2026.

SIGSTORE. Cosign Documentation. 2025. Disponível em: https://docs.sigstore.dev/cosign/overview/ . Acesso em: 7 maio 2026.

SYFT. SBOM Generator. 2025. Disponível em: https://github.com/anchore/syft . Acesso em: 7 maio 2026.

THE LINUX KERNEL ORGANIZATION. seccomp. 2025. Disponível em: https://docs.kernel.org/userspace-api/seccomp_filter.html . Acesso em: 7 maio 2026.

TRIVY. Container Vulnerability Scanner. 2025. Disponível em: https://trivy.dev/ . Acesso em: 7 maio 2026.

WEISE, Aaron et al. Kubernetes Security Contexts and Runtime Hardening. 2024. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ . Acesso em: 7 maio 2026.