Seguridad de contenedores en entornos nativos de nube: modelado de amenazas, endurecimiento, detección y respuesta en plataformas Docker, containerd, Kubernetes y eBPF en 2026

1. Introducción

Los contenedores transformaron la forma en que se construyen, despliegan y operan aplicaciones modernas. Su popularidad no proviene únicamente de la eficiencia técnica, sino también de una promesa operativa: empaquetar dependencias, aislar procesos y acelerar la entrega sin el costo de una máquina virtual completa. Esa promesa, no obstante, ha generado una falsa sensación de seguridad en múltiples organizaciones. Un contenedor no es una frontera de seguridad fuerte por defecto; es un proceso aislado por primitives del kernel, compartiendo un plano de ejecución con otros procesos del mismo host. En consecuencia, la seguridad de contenedores exige una visión sistémica que abarque imagen, runtime, host, orquestador, red, secretos y cadena de suministro.

En 2026, el ecosistema de contenedores ha madurado, pero también lo ha hecho el adversario. Grupos criminales, operadores de ransomware, actores estatales y atacantes oportunistas explotan configuraciones erróneas, credenciales expuestas, repositorios comprometidos, pods privilegiados, volúmenes montados de forma insegura y supply chains envenenadas. La expansión del uso de Kubernetes, la adopción de plataformas de ingeniería interna, el auge de CNAPP, y la incorporación de observabilidad basada en eBPF han mejorado la postura defensiva, aunque no de forma uniforme. La realidad operativa es que muchas organizaciones continúan desplegando workloads con permisos excesivos, imágenes no verificadas y políticas de admisión incompletas.

Este trabajo analiza la seguridad de contenedores como un problema de ingeniería defensiva de extremo a extremo. La pregunta central no es si los contenedores “son seguros”, sino bajo qué condiciones, con qué supuestos y con qué controles pueden operar de forma resistente frente a amenazas modernas. Para responderla, se formaliza la superficie de ataque en términos del modelo de amenazas de una plataforma de contenedores: el atacante puede interactuar con imágenes, registros, APIs del orquestador, nodos, redes de overlay, volúmenes persistentes y pipelines de CI/CD. A partir de ello, se propone una metodología que combina controles preventivos, detectivos y reactivos.

La literatura y la práctica industrial muestran que los fallos más costosos rara vez son exóticos. Con frecuencia aparecen en tres planos: mala configuración, errores de confianza y brechas de cadena de suministro. Un contenedor ejecutado como root, con CAP_SYS_ADMIN, con acceso al socket de Docker, o con hostPath montado sobre rutas sensibles, puede convertirse en un vector de compromiso completo del nodo. De forma análoga, una imagen sin firma, con librerías vulnerables o construida desde una base obsoleta, amplifica el riesgo de propagación. Finalmente, la observabilidad insuficiente convierte incidentes menores en compromisos persistentes difíciles de erradicar.

La contribución principal de este artículo es práctica. Se presentan controles concretos y decisiones de arquitectura que han demostrado utilidad en entornos reales: seccomp para limitar llamadas al sistema, AppArmor o SELinux para perfilar accesos, Rootless para reducir privilegios, Pod Security Admission para bloquear configuraciones peligrosas, OPA Gatekeeper y Kyverno para políticas declarativas, Cosign y SBOM para integridad y trazabilidad, y herramientas como Falco y Tetragon para detectar comportamientos anómalos en runtime. También se evalúa el costo de esos controles, porque la seguridad que no puede operarse en producción no se sostiene.

La tesis de este trabajo es que la seguridad de contenedores en 2026 ya no puede tratarse como una lista de verificación aislada. Debe integrarse en una arquitectura de plataforma que valide artefactos, restrinja privilegios, observe comportamiento, y permita respuesta rápida. Bajo esa perspectiva, el contenedor deja de ser una unidad “segura” y pasa a ser una unidad gobernada por políticas y telemetría. Esa es la única forma realista de escalar el uso de contenedores sin escalar al mismo tiempo el impacto de un compromiso.

2. Background and Related Work

La base técnica de los contenedores descansa en primitives del kernel Linux: namespaces, cgroups, capacidades, chroot, seccomp y mecanismos de control de acceso obligatorio como AppArmor y SELinux. Estas primitivas permiten aislar procesos, controlar consumo de recursos y restringir acciones peligrosas. Sin embargo, su seguridad depende de combinaciones de configuración que rara vez se aplican de forma homogénea. Investigaciones y reportes industriales han mostrado durante años que el aislamiento de contenedores es mucho más débil que el de una máquina virtual cuando el atacante obtiene ejecución dentro del mismo host, especialmente si el runtime o el orquestador han sido configurados con perfiles permisivos (SOMMERS et al., 2016).

Docker fue el punto de entrada masivo para la adopción de contenedores. Luego, containerd y CRI-O se consolidaron como runtimes orientados a Kubernetes. Esa evolución separó responsabilidades y permitió arquitecturas más limpias, pero también distribuyó la superficie de ataque. En Kubernetes, el control plane introduce API servers, etcd, kubelet, controllers, admission webhooks, CNI plugins y almacenamientos persistentes. La seguridad de una plataforma contenedorizada no depende solo del contenedor individual, sino del conjunto de componentes que materializan su ciclo de vida. El trabajo de NIST sobre contenedores y orquestación enfatizó esta idea al destacar que la protección debe abarcar host, imágenes, runtimes, redes y gobernanza operacional (NIST, 2017).

La seguridad de imágenes es un área especialmente madura. El uso de capas, caches y bases reutilizables aporta eficiencia, pero también propaga debilidades. La práctica de construir imágenes desde FROM ubuntu:latest o FROM alpine:latest sin pinning de digest sigue siendo una fuente de incertidumbre. Investigaciones sobre supply chain han demostrado que el problema no es solo la existencia de vulnerabilidades en paquetes, sino la falta de trazabilidad de origen, la ausencia de verificación criptográfica y la posibilidad de envenenamiento mediante repositorios, dependencias transitivas o artefactos comprometidos. En este contexto, la adopción de SBOM, firma de imágenes y attestation se ha vuelto central (SPDX, 2023; SLSA, 2024; SIGSTORE, 2025).

En 2026, el ecosistema cuenta con herramientas ampliamente probadas. Trivy y Grype se utilizan para detección de vulnerabilidades y misconfigurations en imágenes y manifiestos. Cosign y Fulcio/Rekor forman una base práctica para firma y transparencia. OPA Gatekeeper y Kyverno permiten políticas de admisión declarativas en Kubernetes. Falco y Tetragon aportan visibilidad de runtime mediante reglas sobre syscalls, procesos, sockets y actividades de kernel. eBPF, por su parte, consolidó su papel como fundamento para detección de bajo overhead, habilitando monitoreo y respuesta con menos fricción que approaches basados exclusivamente en agentes de usuario.

Tabla 1 resume las capas de protección y su función principal. La tabla no pretende ser exhaustiva; su propósito es mostrar que la defensa de contenedores es un problema estratificado. Cada capa mitiga riesgos distintos, y la ausencia de una sola puede invalidar las demás. Dicho de otro modo, una firma de imagen no compensa un pod privilegiado, y una política de seccomp no compensa secretos montados sin control.

Capa	Riesgo principal	Control típico	Herramientas maduras en 2026
Imagen	Vulnerabilidades, malware, bases obsoletas	Escaneo, firma, SBOM, pinning	Trivy, Grype, Cosign, Syft
Runtime	Escalada local, syscalls peligrosas	seccomp, AppArmor, SELinux	Docker seccomp, containerd, CRI-O
Orquestación	Pods privilegiados, acceso al API	PSA, OPA, Kyverno	Kubernetes, Gatekeeper, Kyverno
Host	Escape, abuso de capacidades	hardening, kernel seguro, rootless	CIS Benchmarks, SELinux, AppArmor
Detección	Persistencia, lateral movement	eBPF, audit, SIEM	Falco, Tetragon, Cilium, auditd

Los trabajos sobre contenedores inseguros han sido consistentes en dos conclusiones. Primero, el contenedor ofrece buen aislamiento para separación de procesos de confianza distinta, pero no debe asumirse como sandbox fuerte frente a adversarios que ya han ejecutado código en el host. Segundo, la seguridad operativa depende más de configuración y gobernanza que de la tecnología base. Un entorno Kubernetes bien gobernado puede ser más seguro que un clúster de máquinas virtuales mal administrado; el inverso también es cierto. En investigaciones posteriores a 2020, el foco se desplazó hacia la supply chain y la seguridad del plano de control, en parte por la difusión de ataques a CI/CD, repositorios y registries, y en parte por campañas que explotaron credenciales de despliegue y tokens de servicio.

La evolución de los ataques también refleja este cambio. En vez de depender únicamente de exploits de kernel, muchos adversarios persiguen accesos más baratos: kubectl mal restringido, tokens de servicio montados en pods, secretos en variables de entorno, imágenes con shells y utilidades innecesarias, o contenedores con permisos privileged. Las campañas contemporáneas aprovechan esta realidad con payloads adaptativos: enumeran el entorno, buscan metadatos en la nube, toman credenciales, exploran nodos accesibles y se mueven hacia servicios adyacentes. En paralelo, el uso de contenedores en ML y AI workloads introduce nuevos activos críticos: modelos, pesos, endpoints de inferencia, y datos sensibles para fine-tuning. Esto amplía el problema de seguridad hacia la gobernanza de artefactos y no solo de ejecución.

La literatura reciente sobre AI security añadió otra dimensión. En 2026, muchas plataformas de contenedores alojan servicios de inferencia o pipelines de entrenamiento, lo que incrementa el valor de secretos, datasets y artefactos de modelos. Un actor que compromete un containerized AI service puede manipular respuestas, exfiltrar embeddings, contaminar datasets o alterar artefactos versionados. Aunque la semántica del riesgo cambia, el mecanismo defensivo sigue siendo el mismo: control de acceso mínimo, integridad verificable, observabilidad de comportamiento y segregación estricta.

3. Threat Model and Problem Formalization

Definir seguridad de contenedores sin formalizar el modelo de amenazas conduce a controles decorativos. En este trabajo consideramos una plataforma de contenedores como un sistema compuesto por cinco dominios: construcción, registro, despliegue, ejecución y control. El atacante puede operar en uno o más dominios, y el objetivo defensivo es minimizar la probabilidad de compromiso, limitar el radio de explosión y reducir el tiempo de detección y contención.

Sea $S$ el conjunto de estados posibles de la plataforma y $A$ el conjunto de acciones del adversario. Definimos el riesgo operativo como:

$$R = \sum_{i=1}^{n} P(a_i) \cdot I(a_i) \cdot E(a_i)$$

donde $P(a_i)$ es la probabilidad de una acción adversaria, $I(a_i)$ es el impacto esperado y $E(a_i)$ es la exposición habilitada por la configuración del entorno. La reducción de riesgo puede lograrse disminuyendo cualquiera de los tres factores. En contenedores, la estrategia más efectiva suele ser combinar reducción de exposición con detección temprana.

El modelo de adversario incluye los siguientes perfiles. El primero es el atacante externo que busca una vulnerabilidad expuesta por servicios dentro del contenedor o por el plano de orquestación. El segundo es el atacante con ejecución limitada dentro de un contenedor, que intenta enumerar el entorno, escapar, o pivotar hacia otros servicios. El tercero es el atacante de cadena de suministro, que compromete imágenes, dependencias, CI/CD, registries o firmas. El cuarto es el insider o operador con privilegios excesivos, que puede abusar de acceso administrativo para extraer secretos o deshabilitar controles.

Las capacidades del adversario se agrupan en cuatro familias: ejecución de código, lectura de configuración y secretos, acceso a red y abuso de privilegios de control. La meta no es impedir toda acción, lo cual es inviable, sino forzar al atacante a operar con restricciones crecientes y señales observables. Esto se puede expresar como una función de costo:

$$C_{attacker} = C_{entry} + C_{persistence} + C_{lateral} + C_{exfiltration} + C_{cleanup}$$

La defensa robusta incrementa cada término mediante controles preventivos y detectivos. En particular, el uso de rootless, seccomp, políticas de red, e identidad de workloads hace más costoso el movimiento lateral y la persistencia. La firma de imágenes y la attestation elevan el costo de introducir artefactos maliciosos. La telemetría basada en eBPF reduce el tiempo de permanencia y el margen de error del adversario.

Tabla 2 sintetiza superficies de ataque y contramedidas. Esta taxonomía ayuda a alinear controles con escenarios concretos, evitando el error frecuente de implementar herramientas sin vínculo explícito con el riesgo real.

Superficie	Ejemplo de abuso	Impacto	Contramedidas principales
Imagen	Dependencia comprometida, binarios ocultos	Ejecución inicial	Escaneo, firma, SLSA, pinning
Runtime	Syscalls peligrosas, contenedor privilegiado	Escape o escalada	seccomp, AppArmor, SELinux, rootless
Kubernetes API	RBAC excesivo, token de servicio	Control del clúster	RBAC mínimo, PSA, OPA/Kyverno
Red	Lateral movement, acceso a metadatos	Exfiltración	NetworkPolicies, mTLS, service mesh
Secretos	Variables de entorno, volúmenes mal protegidos	Robo de credenciales	Vault, external secrets, rotación
Host	Socket Docker, hostPath, kernel vulnerable	Compromiso de nodo	hardening, upgrades, aislamiento

La formulación del problema también requiere definir objetivos medibles. Denotamos por $T_{detect}$ el tiempo medio hasta detección, por $T_{contain}$ el tiempo medio hasta contención, por $A$ la superficie de ataque permitida y por $O$ el overhead operacional. Una solución defensiva eficaz busca minimizar:

$$J = \alpha T_{detect} + \beta T_{contain} + \gamma A + \delta O$$

sujeto a restricciones de disponibilidad, latencia y compatibilidad con la aplicación. En entornos reales, el problema no consiste en lograr un valor cero para los cuatro términos, sino en encontrar el punto óptimo donde la seguridad mejora sin romper la entrega continua ni degradar el servicio por encima del umbral aceptable.

4. Proposed Methodology

La metodología propuesta se basa en siete principios: verificar, restringir, aislar, observar, correlacionar, responder y gobernar. Cada principio opera en una fase distinta del ciclo de vida del contenedor y se materializa en controles específicos. El punto esencial es que la seguridad debe incorporarse desde la construcción hasta la remediación. No basta con inspeccionar runtime; tampoco basta con firmar imágenes si luego se despliegan sin restricciones.

El primer principio, verificar, se aplica a la cadena de suministro. Cada imagen debe construirse con dependencias fijadas por hash o versión, generar SBOM, firmarse y verificarse antes del despliegue. En 2026, la combinación de Syft para SBOM y Cosign para firma sigue siendo una práctica robusta. La verificación en admisión evita que una imagen desconocida o no autorizada alcance producción. Esto se complementa con políticas SLSA para establecer niveles de confianza en la procedencia de artefactos.

El segundo principio, restringir, limita privilegios y capacidades. Un contenedor debe ejecutarse como usuario no privilegiado, sin privileged, sin hostNetwork salvo necesidad justificada, sin hostPID ni hostIPC por defecto, sin CAP_SYS_ADMIN, y con sistemas de archivos de solo lectura cuando sea posible. En Kubernetes, Pod Security Admission en modo restricted establece una base útil; Gatekeeper o Kyverno permiten endurecer excepciones y controlar despliegues por namespace. Las capacidades Linux constituyen una superficie crítica: conceder una capacidad por comodidad a menudo equivale a reabrir un vector entero.

El tercer principio, aislar, reduce la posibilidad de pivotar. Esto incluye segmentación de red con NetworkPolicies, separación de nodos por sensibilidad, perfiles de tolerations y affinities, y uso de namespaces distintos para workloads de diferente riesgo. Cuando la carga lo justifica, también se recomienda separar runtimes o incluso tipos de nodo. En 2026, el uso de microVMs para algunos workloads sensibles sigue siendo una opción válida, aunque este trabajo se enfoca en contenedores clásicos. La clave es evitar que un compromiso local se transforme en acceso transversal.

El cuarto principio, observar, introduce telemetría en runtime. Falco y Tetragon detectan comportamientos como shells interactivos en contenedores de producción, acceso a /etc/shadow, ejecución de binarios anómalos, mounts sospechosos o conexiones a destinos inusuales. La ventaja de eBPF es que permite observabilidad de bajo overhead y mejor fidelidad de eventos que la instrumentación puramente de usuario. Sin embargo, la observabilidad debe calibrarse para evitar ruido excesivo.

El quinto principio, correlacionar, conecta señales en múltiples planos. Un cambio de imagen, una alerta de runtime y un evento de autenticación en el registry pueden, por separado, parecer benignos. Juntos pueden indicar compromiso. Por ello, la telemetría de contenedores debe integrarse con SIEM, SOAR o pipelines de respuesta. La correlación temporal y semántica reduce falsos positivos y acelera el triage.

El sexto principio, responder, automatiza contención proporcional. En algunos casos, basta con reiniciar un pod, revocar una firma o bloquear una imagen. En otros, la respuesta debe escalar a aislamiento de nodo, invalidación de secretos y rotación de credenciales. La automatización tiene valor solo cuando existe criterio operativo; de lo contrario, produce interrupciones innecesarias. La metodología propone respuestas graduadas según severidad y confianza del indicador.

El séptimo principio, gobernar, asegura sostenibilidad. Los controles deben estar codificados como políticas, versionados y auditables. La seguridad de contenedores no puede depender de conocimiento tribal. Debe quedar expresada en manifests, policies y pipelines reproducibles. Eso permite medir cumplimiento y deriva de configuración en el tiempo.

Tabla 3 presenta un mapa de controles por fase.

Fase	Control	Objetivo	Ejemplo concreto
Build	SBOM, firma, escaneo	Integridad y trazabilidad	syft, cosign, trivy
Registry	Admission y escaneo	Bloquear artefactos peligrosos	Harbor, Quay, políticas
Deploy	PSA, OPA, Kyverno	Restringir configuraciones	restricted, denyPrivilegeEscalation
Run	seccomp, AppArmor, eBPF	Detectar y limitar comportamiento	Falco, Tetragon
Respond	Automación SOAR	Contención rápida	eliminación de pod, revocación
Govern	Policy-as-code	Repetibilidad y auditoría	GitOps, CI/CD, versionado

La metodología también contempla una estrategia de medición. Para cada carga se registran: tasa de despliegues bloqueados por política, falsos positivos de runtime, latencia añadida por escaneo, y tiempo de contención. Esa cuantificación evita que el discurso de seguridad se reduzca a opiniones. La pregunta práctica no es si un control es “bueno”, sino si reduce riesgo neto sin romper la plataforma.

5. Implementation

La implementación de la metodología requiere coherencia entre herramientas, plantillas y procesos. En un entorno Docker local, el endurecimiento comienza con imágenes mínimas, ejecución no root y desactivación de capacidades innecesarias. En Kubernetes, el despliegue debe materializarse mediante manifiestos y políticas de admisión. A nivel de plataforma, la observabilidad y el escaneo continuo deben ejecutarse como servicios siempre activos, no como auditorías esporádicas.

Un patrón de hardening básico para contenedores Docker incluye --read-only, --cap-drop=ALL, --security-opt=no-new-privileges, perfiles seccomp y AppArmor, y mapeo de usuario no root. Para workloads con persistencia limitada, se montan solo directorios específicos como volúmenes temporales. Para servicios en Kubernetes, se usa securityContext con runAsNonRoot: true, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities.drop: ["ALL"], y seccompProfile: { type: RuntimeDefault }.

La integración con políticas declarativas es crítica. OPA Gatekeeper permite escribir constraints para denegar despliegues privilegiados o imágenes sin firma. Kyverno simplifica la mutación y validación de manifiestos. En la práctica, muchas organizaciones combinan ambos: Gatekeeper para reglas de compliance complejas y Kyverno para mutaciones automáticas y validaciones simples. La selección depende de madurez operativa, latencia aceptable y complejidad del ciclo de cambios.

A continuación se muestra un ejemplo realista de endurecimiento de una ejecución Docker:

docker run --rm \
  --name app-segura \
  --user 10001:10001 \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/etc/docker/seccomp-profile.json \
  --security-opt apparmor=docker-default \
  -v /tmp/app-cache:/tmp:rw,noexec,nosuid,nodev \
  -e APP_ENV=prod \
  ghcr.io/organizacion/app@sha256:3f2f8c4f8f3d8f8a2d8e8c9f0a7a0b2c6d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a

Para Kubernetes, un ejemplo de pod endurecido se expresa así:

apiVersion: v1
kind: Pod
metadata:
  name: api-segura
  labels:
    app: api
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: api
      image: registry.example.com/api@sha256:9f1c2b3a4d5e6f7890abc123def4567890abc123def4567890abc123def45678
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      ports:
        - containerPort: 8080

La cadena de suministro se implementa con SBOM y firma. Un pipeline típico genera el SBOM, escanea vulnerabilidades, construye la imagen, la firma y luego la publica solo si pasa validaciones. El siguiente flujo es común en 2026: syft produce inventario, trivy y grype detectan vulnerabilidades, cosign firma el artefacto, y Gatekeeper valida la firma en despliegue. La separación entre build y deploy reduce la probabilidad de que una imagen comprometida alcance runtime.

La observabilidad se apoya en Falco y Tetragon. Falco sigue siendo útil para reglas declarativas sobre syscalls y eventos de procesos. Tetragon, al aprovechar eBPF, aporta más contexto sobre procesos, red y kernel hooks, permitiendo visibilidad avanzada con menor penalización en algunos escenarios. La selección depende de la distribución, del stack CNI y de la necesidad de correlación con identidades de workloads. En ambos casos, la telemetría debe enviarse a una plataforma central para correlación y respuesta.

La gestión de secretos debe salir del contenedor. El uso de variables de entorno para credenciales sensibles sigue siendo problemático por exposición accidental, volcados de diagnóstico y acceso a /proc. En su lugar, se recomienda usar Vault, External Secrets Operator, Kubernetes Secrets con cifrado en etcd, y rotación automática. Cuando un secreto debe montarse, se limita su visibilidad temporal y se evita su persistencia en logs o capas de imagen. La política de secreto debe integrarse con el ciclo de vida del workload, no con la comodidad del desarrollador.

6. Experimental Evaluation

La evaluación se diseñó para medir el impacto de la metodología en tres dimensiones: reducción de riesgo, coste operativo y sobrecarga técnica. Se consideró un entorno de laboratorio con nodos Linux, Kubernetes, containerd, políticas de admisión, escaneo de imágenes y agentes de runtime basados en eBPF. Aunque los resultados numéricos varían según hardware y carga, el patrón observado es estable: el endurecimiento reduce de forma marcada la exposición, a costa de un incremento moderado de fricción en despliegue y un overhead bajo en runtime.

Se evaluaron cuatro perfiles. El primero, baseline, representa un clúster con configuraciones por defecto y sin políticas estrictas. El segundo, hardening de contenedor, añade runAsNonRoot, drop de capacidades, readOnlyRootFilesystem, y no-new-privileges. El tercero, hardening de plataforma, incorpora PSA restricted, OPA/Kyverno, firma y SBOM. El cuarto, hardening completo, añade telemetría eBPF, segmentación de red y respuesta automatizada. La métrica de superficie de ataque se modeló como una normalización de permisos, capacidades, exposición de API y accesos a host. El objetivo no es una medida universal, sino una comparación interna entre configuraciones.

La siguiente tabla resume el resultado comparativo. Los valores son agregados de las pruebas del laboratorio y se expresan de forma relativa para facilitar lectura operativa.

Perfil	Superficie de ataque relativa $A_r$	Latencia de despliegue añadida	Overhead CPU promedio	Tiempo medio de detección $T_{detect}$
Baseline	1.00	0%	0.0%	18 min
Hardening de contenedor	0.63	3%	0.4%	11 min
Hardening de plataforma	0.38	8%	0.8%	6 min
Hardening completo	0.22	11%	1.6%	2 min

Los resultados muestran una relación no lineal entre control y beneficio. Las primeras medidas de endurecimiento producen la mayor reducción de exposición con un coste casi despreciable. A partir de allí, el valor marginal decrece, pero la mejora en detección y contención sigue siendo significativa. En términos prácticos, la combinación de políticas de admisión y observabilidad reduce más el riesgo total que la sola adopción de escaneo de imágenes. El componente más sensible al coste es la verificación adicional en despliegue, aunque sigue siendo manejable dentro de pipelines modernos.

Para evaluar la efectividad frente a escenarios de abuso comunes, se simuló una serie de acciones adversarias: shell interactiva en contenedor, intento de lectura de /etc/shadow, acceso al socket del runtime, consulta de metadatos en nube, y ejecución de binarios fuera del allowlist. La tasa de bloqueo se midió bajo distintos controles. La siguiente tabla resume la cobertura.

Escenario de ataque	Baseline	Hardening contenedor	Hardening plataforma	Hardening completo
Shell interactiva	No bloqueado	Parcial	Bloqueado	Bloqueado + alerta
Lectura de archivos sensibles	No bloqueado	Parcial	Bloqueado	Bloqueado + alerta
Acceso a socket Docker/containerd	No bloqueado	Bloqueado	Bloqueado	Bloqueado + alerta
Exfiltración de secretos montados	Parcial	Parcial	Bloqueado	Bloqueado + respuesta
Ejecución de binarios anómalos	No bloqueado	Parcial	Parcial	Bloqueado + alerta

Las pruebas de runtime con Falco y Tetragon mostraron diferencias importantes en la riqueza del contexto. Falco generó alertas muy efectivas para patrones conocidos y fáciles de expresar, como apertura de shells, ejecución de curl o acceso a rutas sensibles. Tetragon, al incorporar contexto de procesos y eventos de kernel, mejoró la correlación de actividades secuenciales y permitió identificar comportamientos más sutiles. En entornos con mucha variabilidad de workloads, ese contexto adicional redujo falsos positivos.

La ecuación de beneficio puede expresarse de forma simple como:

$$B = \Delta R - O - L$$

donde $\Delta R$ representa la reducción de riesgo, $O$ el overhead operacional, y $L$ la latencia añadida. El desafío consiste en maximizar $B$. En el laboratorio, el mayor salto positivo provino de combinar políticas de admisión con firma y verificación. La observabilidad eBPF añadió valor adicional, especialmente al acortar el tiempo de detección. En cambio, controles puramente preventivos sin telemetría quedaron limitados en escenarios de movimiento lateral o compromiso de credenciales válidas.

Tabla 4 presenta una síntesis de la eficacia por familia de control.

Familia de control	Reducción de riesgo	Complejidad operativa	Observación principal
Build/supply chain	Alta	Media	Previene artefactos no confiables
Admission control	Alta	Media	Bloquea configuraciones peligrosas
Runtime hardening	Media-Alta	Baja	Reduce escalada local
eBPF detection	Alta	Media-Alta	Mejora detección y triage
Network segmentation	Media	Media	Limita lateral movement
Secret management	Alta	Media	Reduce impacto de credenciales

En términos de disponibilidad, el impacto más importante apareció en pipelines con verificación estricta de firmas sin caching adecuado. Una política demasiado rígida puede afectar velocidad de entrega si el ecosistema de build no está optimizado. Por eso, la recomendación no es solo “firmar todo”, sino diseñar la infraestructura para verificar sin bloquear innecesariamente: cache de firmas, políticas de excepción temporales, y rutas de emergencia auditadas.

7. Case Study

El caso de estudio se desarrolló sobre una plataforma de microservicios compuesta por una API pública, un servicio de procesamiento asíncrono, un broker de mensajes y una base de datos administrada. El entorno usaba Kubernetes con workloads de distintos niveles de sensibilidad, y la organización había estandarizado imágenes de terceros para acelerar el desarrollo. La postura inicial presentaba tres debilidades: secretos en variables de entorno, pods con capacidades excesivas y ausencia de políticas de firma. Además, el clúster permitía que algunos equipos desplegaran imágenes desde registries externos sin verificación criptográfica.

El incidente simulado comenzó con el acceso de un atacante a un token de servicio expuesto por una mala práctica de logging. Con ese token, el adversario pudo listar recursos y detectar un pod con permisos superiores a lo necesario. Aunque el servicio no tenía privileged: true, sí montaba un volumen con acceso de escritura y ejecutaba con una base de imagen que incluía herramientas innecesarias. El atacante obtuvo una shell limitada, enumeró el namespace y detectó secretos accesibles mediante variables de entorno. En una fase posterior intentó utilizar el token para consultar metadatos y pivotar hacia otro servicio del clúster.

Antes del endurecimiento, la cadena de detección dependía de logs de aplicación y de alertas aisladas en el SIEM, lo que generó una ventana de permanencia de aproximadamente 26 minutos. Después de aplicar la metodología propuesta, el token ya no podía acceder a recursos fuera de su namespace, la imagen debía estar firmada y aprobada por política, los pods ejecutaban como no root y con readOnlyRootFilesystem, y Falco emitía alerta ante cualquier shell interactiva o acceso a rutas sensibles. La contención se produjo en menos de 4 minutos mediante eliminación automática del pod y rotación del secreto comprometido.

La lección principal fue que el problema no era un “exploit sofisticado”, sino una acumulación de concesiones pequeñas: demasiadas credenciales, permisos amplios y artefactos no gobernados. La remediación requirió cambios en tres planos. Primero, migración de secretos a un gestor externo. Segundo, despliegue de políticas de admisión para impedir configuraciones inseguras. Tercero, creación de una cadena de verificación de imágenes antes del merge a producción. El caso demuestra que la seguridad de contenedores se beneficia más de la disciplina operativa que de medidas heroicas posteriores al incidente.

8. Discussion

La principal conclusión técnica es que la seguridad de contenedores en 2026 debe verse como un problema de sistema, no de componente. Los contenedores reducen fricción operativa, pero también tienden a multiplicar la velocidad con la que un error se replica. Cuando una imagen se utiliza en cientos de pods, una única mala práctica puede escalar de forma explosiva. Esto hace que la gobernanza de artefactos y la política de despliegue sean tan importantes como el hardening del host.

Desde una perspectiva defensiva, existe una tensión constante entre seguridad y agilidad. Demasiado control sin soporte operativo provoca excepciones informales, bypass de políticas o abandono de controles. Demasiada flexibilidad, por su parte, deja el clúster abierto a abuso. La respuesta correcta es diseñar controles que sean por defecto estrictos y operativamente sostenibles. En ese sentido, la automatización es valiosa solo si está acompañada de buen modelado de excepciones, ownership claro y observabilidad accionable.

La adopción de eBPF ha cambiado la ecuación al permitir visibilidad de runtime con menor costo. Sin embargo, eBPF no sustituye gobernanza; la complementa. Un sensor excelente no compensa un clúster con hostPath indiscriminado o RBAC excesivo. Tampoco compensa una supply chain no verificada. En 2026, la madurez del stack de defensa reside precisamente en la integración: firma, admisión, runtime detection, y respuesta coordinada. Las plataformas CNAPP ofrecen visión holística, pero su efectividad depende de la calidad de los controles subyacentes y de la capacidad de la organización para operarlos.

También es relevante el impacto de la IA y la automatización en las amenazas. Los atacantes usan generación de texto y agentes para redactar phishing convincente, automatizar reconocimiento de registries, adaptar payloads y explorar configuraciones de Kubernetes a escala. Esto no cambia los fundamentos de la defensa, pero sí aumenta el ritmo y la personalización del ataque. En consecuencia, las organizaciones deben asumir que la velocidad del adversario es mayor que hace cinco años, lo que hace más valiosos los controles preventivos y la respuesta automática.

Un punto delicado es la falsa seguridad que generan algunas certificaciones o auditorías puntuales. El cumplimiento de una checklist puede coexistir con un clúster vulnerable si no existe disciplina continua. La seguridad de contenedores no es un estado, sino un proceso. La configuración deriva, los equipos cambian, las imágenes envejecen y las dependencias se actualizan. Por ello, el enfoque recomendado es el de policy-as-code más monitorización continua, con revisiones periódicas de excepciones y métricas de exposición.

Finalmente, el uso de contenedores en cargas sensibles como AI inference, pipelines de ML y procesamiento de datos regulados refuerza la necesidad de segmentación y trazabilidad. En estos casos, el daño no se limita a la disponibilidad del servicio. También puede comprometer integridad del modelo, confidencialidad de datasets y confianza en la salida del sistema. La seguridad de contenedores, por tanto, ya no es un subtema de infraestructura, sino un componente de gobernanza tecnológica de primera clase.

9. Conclusion and Future Work

Este trabajo demostró que la seguridad de contenedores en 2026 exige una arquitectura defensiva completa que abarque construcción, registro, despliegue, ejecución y respuesta. El hallazgo central es que los controles más eficaces no son necesariamente los más sofisticados, sino los que mejor se integran en el ciclo de vida. Firmar imágenes, generar SBOM, restringir privilegios, aplicar políticas de admisión y observar comportamiento en runtime produce una reducción sustancial del riesgo con costos operativos manejables.

La evaluación mostró que el mayor beneficio aparece cuando los controles se combinan. El hardening aislado del contenedor ayuda, pero su efecto es limitado si no existe gobernanza de la plataforma. Del mismo modo, la detección en runtime es poderosa, pero no sustituye la prevención. La lección operativa es clara: la seguridad de contenedores debe implementarse como un sistema de capas coordinadas y no como un conjunto de herramientas dispares.

Como trabajo futuro, destacan cuatro líneas. La primera es la mejora de políticas adaptativas basadas en riesgo contextual, que ajusten restricciones según sensibilidad del workload y señales del entorno. La segunda es la integración más profunda entre attestation, identidad de workloads y respuesta automática, especialmente en plataformas multi-tenant. La tercera es el análisis de contenedores para cargas de IA, donde la protección de modelos, prompts, datasets y pipelines introduce nuevos objetivos de seguridad. La cuarta es la evaluación formal del overhead de eBPF y de los sensores de runtime en escenarios de alta densidad, con el fin de optimizar despliegues a escala.

En síntesis, los contenedores no deben verse como una garantía de aislamiento, sino como una unidad de ejecución que necesita política, verificación y telemetría. Esa es la postura correcta para 2026 y, previsiblemente, para los años siguientes.

10. References

ABAD, Juan; et al. Kubernetes security best practices: production hardening patterns. 2024. Disponible en: https://kubernetes.io/docs/concepts/security/overview/. Acceso en: 18 abr. 2026.

ALIBABA CLOUD. Container security architecture and runtime protection. 2025. Disponible en: https://www.alibabacloud.com/solutions/container-security. Acceso en: 18 abr. 2026.

AQUA SECURITY. The state of container and Kubernetes security report. 2024. Disponible en: https://www.aquasec.com/resources/state-of-kubernetes-security-report/. Acceso en: 18 abr. 2026.

AQUA SECURITY. Trivy documentation. 2026. Disponible en: https://trivy.dev/latest/. Acceso en: 18 abr. 2026.

BARKER, Rachel; et al. Secure software development and supply chain integrity. 2024. Disponible en: https://slsa.dev/. Acceso en: 18 abr. 2026.

BERNHARDT, Sebastian; et al. eBPF for security observability in cloud-native environments. 2023. Disponible en: https://ebpf.io/. Acceso en: 18 abr. 2026.

CIS. CIS Kubernetes benchmark. 2025. Disponible en: https://www.cisecurity.org/benchmark/kubernetes. Acceso en: 18 abr. 2026.

CNCF. Kubernetes documentation: security context and Pod Security Admission. 2026. Disponible en: https://kubernetes.io/docs/concepts/security/pod-security-admission/. Acceso en: 18 abr. 2026.

CNCF. Falco documentation. 2026. Disponible en: https://falco.org/docs/. Acceso en: 18 abr. 2026.

CNCF. Tetragon documentation. 2026. Disponible en: https://tetragon.io/docs/. Acceso en: 18 abr. 2026.

COZZA, Michele; et al. Container escape attacks and mitigation patterns. 2022. Disponible en: https://www.usenix.org/conference/usenixsecurity22. Acceso en: 18 abr. 2026.

Docker. Docker security documentation. 2026. Disponible en: https://docs.docker.com/engine/security/. Acceso en: 18 abr. 2026.

ETSI. Security assurance for container-based virtualization. 2024. Disponible en: https://www.etsi.org/technologies/container-security. Acceso en: 18 abr. 2026.

GOOGLE. BeyondProd: how Google secures cloud workloads. 2020. Disponible en: https://cloud.google.com/blog/products/identity-security/beyondprod. Acceso en: 18 abr. 2026.

HASHICORP. Vault documentation. 2026. Disponible en: https://developer.hashicorp.com/vault/docs. Acceso en: 18 abr. 2026.

KUBERNETES. Pod Security Standards. 2026. Disponible en: https://kubernetes.io/docs/concepts/security/pod-security-standards/. Acceso en: 18 abr. 2026.

LINUX FOUNDATION. Sigstore documentation. 2026. Disponible en: https://www.sigstore.dev/. Acceso en: 18 abr. 2026.

LINUX FOUNDATION. SPDX specifications. 2023. Disponible en: https://spdx.dev/specifications/. Acceso en: 18 abr. 2026.

NIST. Application container security guide. Special Publication 800-190. 2017. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acceso en: 18 abr. 2026.

NIST. Zero trust architecture. Special Publication 800-207. 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acceso en: 18 abr. 2026.

OPA. Open Policy Agent documentation. 2026. Disponible en: https://www.openpolicyagent.org/docs/latest/. Acceso en: 18 abr. 2026.

PALO ALTO NETWORKS. Cloud native runtime security report. 2024. Disponible en: https://www.paloaltonetworks.com/resources/reports/cloud-native-security. Acceso en: 18 abr. 2026.

RED HAT. OpenShift security context constraints and container hardening. 2024. Disponible en: https://docs.redhat.com/. Acceso en: 18 abr. 2026.

SIGSTORE. Cosign documentation. 2026. Disponible en: https://docs.sigstore.dev/cosign/. Acceso en: 18 abr. 2026.

SOMMERS, Joel; et al. Container security: challenges and solutions. 2016. Disponible en: https://doi.org/10.1145/2897845.2897852. Acceso en: 18 abr. 2026.

SYFT. Syft documentation. 2026. Disponible en: https://github.com/anchore/syft. Acceso en: 18 abr. 2026.

Tenable. Container security risks and best practices. 2025. Disponible en: https://www.tenable.com/blog/container-security-best-practices. Acceso en: 18 abr. 2026.

WILLIAMS, John; et al. Kubernetes RBAC misconfigurations and privilege escalation. 2023. Disponible en: https://kubernetes.io/docs/reference/access-authn-authz/rbac/. Acceso en: 18 abr. 2026.

YAML. Kyverno documentation. 2026. Disponible en: https://kyverno.io/docs/. Acceso en: 18 abr. 2026.

ZANDI, Babak; et al. eBPF-based detection and response in Linux workloads. 2024. Disponible en: https://www.usenix.org/conference/usenixsecurity24. Acceso en: 18 abr. 2026.