Contenedores y Docker: la caja aislada

Una Máquina Virtual (VM) emula hardware completo mediante un hipervisor (como VMware o VirtualBox): tiene su propia BIOS, su propio kernel y gestiona su propia memoria virtual, pesando gigabytes. Un contenedor Docker no emula hardware ni lleva su propio kernel: es simplemente un proceso ordinario de Linux confinado en una 'jaula' mediante dos funciones del sistema operativo: namespaces (que aíslan lo que el proceso puede ver) y cgroups (que limitan cuánta memoria y CPU puede gastar).

En Docker existen dos conceptos esenciales: 1) La Imagen: es una plantilla de solo lectura que contiene el sistema de archivos empaquetado (el código, las librerías y las dependencias necesarias). 2) El Contenedor: es una instancia viva en ejecución creada a partir de esa imagen. Puedes lanzar diez contenedores idénticos de un servidor web desde una sola imagen; si uno se corrompe o falla, se destruye y se recrea en un segundo sin alterar la imagen original.

Por defecto, un contenedor vive en una red interna privada (como 172.17.0.2) y nadie fuera del servidor puede comunicarse con él. Para publicar su servicio se realiza un reenvío de puertos mediante el parámetro -p: por ejemplo, docker run -p 8080:80 nginx. Esto indica al cortafuegos del host que cualquier paquete que llegue al puerto 8080 del servidor físico debe redirigirse al puerto 80 dentro del contenedor.

Si no se indica lo contrario en el Dockerfile, los procesos dentro del contenedor se ejecutan bajo la cuenta root (UID 0). Dado que el contenedor comparte el kernel del anfitrión, si un atacante explota una vulnerabilidad en el software y logra escapar del contenedor (Container Escape), aterriza en el servidor anfitrión con los máximos privilegios posibles. La buena práctica consiste en definir un usuario sin privilegios (USER appuser) dentro del contenedor.