> ## Content Index
> Fetch the complete content index at: https://www.sredevops.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# ¿Los contenedores siguen siendo un límite de seguridad?
- URL: https://www.sredevops.org/es/los-contenedores-siguen-siendo-un-limite-de-seguridad/
- Published: 2026-10-05T09:37:04.000Z
- Updated: 2026-10-05T09:37:04.000Z
- Description: Un malware corriendo dentro de un contenedor puede explotar un bug del kernel, escalar a root y, de repente, está en el host. El límite del contenedor se vuelve decorativo.
- Author: Nicolás Georger
- Tags: Security, Linux, Kubernetes, Containers, Español, #es

Durante años, los contenedores se han vendido como "aislamiento liviano": empaqueta tu app, córrela en cualquier lado y duerme tranquilo porque el código malicioso no puede tocar el host. Esa historia es *mayormente* cierta—hasta que el kernel decide tener un mal día. Con una seguidilla constante de CVEs del kernel de Linux y bugs de escalada de privilegios local (LPE), es razonable preguntarse: **¿sigue siendo un contenedor un límite de seguridad significativo, o solo un `chroot` muy confiado con presupuesto de marketing?**

## Cómo aíslan los contenedores en realidad

Cuando ejecutas `docker run`, no estás arrancando un SO diminuto. Estás llamando a `clone(2)` con un montón de flags. El kernel crea un proceso hijo con nuevos namespaces: mount, PID, user, network, IPC, UTS y cgroup. Obtienes un sistema de archivos raíz falso, un usuario root falso y una red falsa. **Se siente como una VM. No lo es.**

Bajo el capó, `runc` (u otro runtime OCI) usa flags como `CLONE_NEWNS`, `CLONE_NEWPID`, `CLONE_NEWUSER` y `CLONE_NEWNET`. El PID 1 del contenedor no es más que un proceso en el host, oculto por un namespace de PID. Su usuario `root` a menudo se mapea a un UID sin privilegios mediante un namespace de usuario. Su `/etc` es un namespace de montaje. Todo es truco del kernel. **Cada syscall sigue llegando al mismo kernel del host.**

**Ese kernel compartido es la gracia. También es el problema.**

## El kernel es el límite

El kernel media todo: archivos, memoria, red, dispositivos. La interfaz de syscalls no es privilegiada; cualquier proceso puede llamar a `open`, `read`, `write`, `splice`, `io_uring` y amigos. Se supone que el kernel verifica permisos y te mantiene en tu carril. **Si un bug te permite confundir al kernel, puedes salirte de ese carril y llegar a root.**

**Dirty COW (CVE-2016-5195)** fue la llamada de atención: una *race condition* en copy-on-write permitía escalada de privilegios local universal. En ese entonces, un bug de ese tamaño se sentía como un evento anual. Parcheabas, seguías adelante y rezabas para que nadie posea un zero-day.

Ahora, la investigación de vulnerabilidades asistida por IA **ha puesto ese modelo patas arriba**. LPEs recientes reportadas con nombres como [Copy Fail](https://www.sredevops.org/en/how-the-linux-kernel-copyfail-vulnerability-impacts-kubernetes-what-you-need-to-know-and-what-you-can-do/) y Dirty Frag muestran sobrescrituras de page-cache y bugs de socket splicing que pueden convertir un escape de contenedor en una toma de control del host. Los nombres son ridículos; el impacto no. **Un malware corriendo dentro de un contenedor puede explotar un bug del kernel, escalar a root y, de repente, está en el host.** [**El límite del contenedor se vuelve decorativo.**](https://cix.world/?ref=sredevops.org)

[How the Linux kernel copyfail vulnerability impacts kubernetes: What you need to know and what you can docopy fail in kubernetes: when your pod escapes to the host with four bytes if you thought containers were a security boundary, cve-2026-31431 (“copy fail”) has some unfortunate news for you. discovered by xint, this linux kernel vulnerability lets an unprivileged local user overwrite four controlled bytes in![](https://www.sredevops.org/content/images/icon/Icon-App-76x76@2x-ca2fb294-cb1c-4d81-8f34-67bdec2073fa.png)SREDevOps.orgNicolás Georger![](https://www.sredevops.org/content/images/thumbnail/copyfail-kubernetes-linux-ddb47722-47c6-41b3-84cd-5faf83a4d034.png)](https://www.sredevops.org/en/how-the-linux-kernel-copyfail-vulnerability-impacts-kubernetes-what-you-need-to-know-and-what-you-can-do/)

Leer más sobre CopyFail en Kubernetes

El gráfico de CVEs del kernel no va a la baja. Si ejecutas código no confiable en un contenedor común, estás compitiendo contra el ciclo de parches. A veces ganas. A veces gana el atacante. Como argumenta [el análisis reciente de Depth First](https://depthfirst.com/research/containers-are-no-longer-safe?ref=sredevops.org), el límite del contenedor ya no es algo con lo que puedas contar.

## Kubernetes no cambia la matemática

Kubernetes orquesta contenedores. No agrega aislamiento por hardware. Programa pods en nodos, y esos pods comparten un kernel. La *multi-tenencia* sobre el mismo kernel es una decisión de confianza. Si los inquilinos ejecutan código arbitrario, un exploit del kernel puede comprometer el nodo y todos los contenedores que están en él.

Por esto los proveedores de nube a menudo aíslan a los inquilinos a nivel de VM, no solo a nivel de contenedor. También es por esto que las plataformas serverless y las ofertas de Kubernetes administrado suelen usar microVMs o runtimes sandboxeados bajo el capó. Kubernetes es un gran orquestador. No es un límite de seguridad.

## MicroVMs: devolviendo el hardware al juego

Una microVM es una máquina virtual real, solo que pequeña y rápida. Usa un VMM (Virtual Machine Monitor) como Firecracker o Cloud Hypervisor, que habla con KVM. La CPU impone el aislamiento de memoria. Un guest comprometido no puede tocar el host a menos que el atacante encuentre un bug del hipervisor.

Esa es una superficie de ataque mucho más pequeña que todo el kernel de Linux. KVM no es invencible *—el* [*KVM CTF*](https://security.googleblog.com/?ref=sredevops.org) *de Google ha pagado grandes recompensas por escapes—*pero la tasa de bugs es órdenes de magnitud menor que la de LPEs del kernel. Proyectos como [Firecracker](https://firecracker-microvm.github.io/?ref=sredevops.org) (usado por AWS Lambda y Fargate), [Kata Containers](https://katacontainers.io/?ref=sredevops.org) y [gVisor](https://gvisor.dev/?ref=sredevops.org) (un kernel en espacio de usuario que intercepta syscalls) ofrecen un aislamiento más fuerte para cargas de trabajo no confiables.

| Enfoque      | Mecanismo de aislamiento          | Superficie de ataque             | Uso típico                                |
| ------------ | --------------------------------- | -------------------------------- | ----------------------------------------- |
| Contenedores | Namespaces + cgroups              | Kernel del host                  | Cargas de trabajo confiables, empaquetado |
| MicroVMs     | Virtualización por hardware (KVM) | Hipervisor + VMM                 | Código multitenant no confiable           |
| gVisor       | Kernel en espacio de usuario      | Superficie de syscalls de gVisor | Sandboxing, serverless                    |

## Qué hacer si ejecutas código no confiable

Si tu modelo de amenaza incluye código malicioso, los contenedores por sí solos no son suficientes. Aquí tienes una lista práctica:

- Usa microVMs o runtimes en sandbox para cargas de trabajo multi-tenant o no confiables.
- En Kubernetes, usa `RuntimeClass` para seleccionar Kata Containers, Firecracker o gVisor para pods sensibles.
- Aplica hardening en los contenedores de todas formas: quita capabilities, habilita seccomp, AppArmor/SELinux, rootfs de solo lectura y ejecuta como non-root.
- Separa zonas de confianza: nodos distintos para inquilinos distintos.
- Aplica parches a los kernels rápido, pero no confíes en ganar la carrera.
- Monitorea CVEs y ten un plan de respuesta a incidentes que asuma que el escape es posible.

Los contenedores siguen siendo excelentes para empaquetado, densidad y orquestación. No son un límite de seguridad fuerte contra exploits del kernel. Si necesitas un límite, pon un hipervisor o un kernel en espacio de usuario en el medio. El kernel es código. El código tiene bugs. La IA los está encontrando más rápido. Elige tus límites en consecuencia.

## Referencias

- [Página de manual de namespaces de Linux](https://man7.org/linux/man-pages/man7/namespaces.7.html?ref=sredevops.org)
- [Página de manual de clone(2)](https://man7.org/linux/man-pages/man2/clone.2.html?ref=sredevops.org)
- [KVM](https://www.linux-kvm.org/page/Main%5FPage?ref=sredevops.org)
- [microVM Firecracker](https://firecracker-microvm.github.io/?ref=sredevops.org)
- [Kata Containers](https://katacontainers.io/?ref=sredevops.org)
- [gVisor](https://gvisor.dev/?ref=sredevops.org)
- [CVE-2016-5195: Dirty COW](https://nvd.nist.gov/vuln/detail/CVE-2016-5195?ref=sredevops.org)
- [Blog de seguridad de Google – KVM CTF](https://security.googleblog.com/?ref=sredevops.org)
- [Depth First](https://depthfirst.com/?ref=sredevops.org)