Qué es de verdad un contenedor y por qué no es una máquina virtual

Antes de hablar de ataques conviene tener muy claro qué es un contenedor, porque casi todos los riesgos del curso nacen de un malentendido: creer que un contenedor es una caja tan sellada como una máquina virtual. No lo es, y entender por qué es el primer paso para defenderse.

Qué es un contenedor

Un contenedor es un proceso normal del sistema operativo al que el núcleo le muestra una versión recortada de la máquina: ve solo sus propios archivos, sus propios procesos y su propia red, como si estuviera solo en el equipo. No es una computadora dentro de otra; es un programa que corre en el anfitrión con una venda en los ojos que le oculta todo lo demás.

Esa venda la ponen dos funciones del núcleo de Linux. Los espacios de nombres (namespaces) deciden qué puede ver el proceso: qué procesos existen, qué red hay, qué sistema de archivos. Los grupos de control (cgroups) deciden cuánto puede consumir: cuánta memoria, cuánta CPU. Juntos crean la ilusión de una máquina aparte. Pero debajo de la ilusión hay un solo núcleo, el del anfitrión, compartido por todos los contenedores.

Por qué no es una máquina virtual

Esta es la diferencia que lo cambia todo para la seguridad.

	Máquina virtual	Contenedor
Qué aísla	Hardware virtual completo sobre un hipervisor	Un proceso, mediante funciones del núcleo
Núcleo	Cada máquina tiene el suyo	Todos comparten el del anfitrión
Arranque	Lento, pesado (un sistema completo)	Rápido, liviano
Si falla el aislamiento	Hay que vencer al hipervisor, barrera gruesa	Basta una mala configuración o una falla del núcleo

Una máquina virtual lleva su propio núcleo y se apoya en un hipervisor; para saltar de una a otra hay que atravesar una barrera diseñada precisamente para eso. Un contenedor, en cambio, es solo un proceso con la vista recortada. Si la configuración afloja la venda, o si aparece una falla en el núcleo compartido, ese proceso puede alcanzar al anfitrión. A eso se le llama escape de contenedor, y es el corazón del módulo 3.

Un poco de historia

Época	Qué cambió
Años setenta y dos mil	Unix ofrece aislar procesos con mecanismos como chroot; aparecen las jaulas y las primeras formas de aislamiento.
Años dos mil a 2008	El núcleo de Linux incorpora los espacios de nombres y los grupos de control, la base técnica de los contenedores.
2013	Docker populariza los contenedores: empaquetar una aplicación con todo lo que necesita en una imagen fácil de compartir.
2014 en adelante	Google libera Kubernetes para orquestar miles de contenedores; los contenedores se vuelven el estándar para desplegar software.

La lección de esta historia es que la comodidad llegó antes que la cultura de seguridad. Durante años se desplegaron contenedores como root, con imágenes sin revisar y clústeres abiertos, porque "funcionaba". Los ataques de este curso explotan justo esa herencia.

Dónde viven los contenedores

Lugar	Ejemplo
Servidor de una empresa	La tienda en línea de Cafetal Digital empaquetada en contenedores
Nube pública	Servicios gestionados de contenedores y clústeres de Kubernetes
Canalizaciones de integración	Cada cambio de código se prueba dentro de un contenedor
Equipo de una persona desarrolladora	Bases de datos y servicios de prueba en contenedores locales

Conceptos clave

Concepto	Qué significa
Imagen	Plantilla de solo lectura, hecha de capas, con la aplicación y sus dependencias
Contenedor	Instancia en ejecución de una imagen; un proceso aislado por el núcleo
Registro	Servidor donde se guardan y descargan las imágenes
Demonio	Servicio que corre en el anfitrión y crea y maneja los contenedores
Orquestador	Sistema que despliega y coordina muchos contenedores; Kubernetes es el más común
Escape	Salir del aislamiento del contenedor y alcanzar el anfitrión

Con este mapa en mente, el resto del curso recorre cada familia de ataques respondiendo siempre tres preguntas del defensor: cómo funciona, cómo se ve y cómo se frena.