Advanced topics

Containers en detalle

Los Linux containers se implementan con varios mecanismos del kernel trabajando juntos: control groups (cgroups), namespaces, Secure Computing Mode (seccomp), SELinux y AppArmor. Cada uno cumple un rol:

• cgroups: resource limits (memoria, CPU, I/O).
• Namespaces: procesos ven recursos con nombres únicos, aislados unos de otros.
• seccomp: limita qué system calls puede hacer un proceso.
• SELinux/AppArmor: aislamiento de seguridad adicional.

Una analogía: si un server normal es un almacén abierto donde los procesos se estorban unos a otros, Docker convierte el almacén en un edificio de oficinas. Los namespaces son las paredes, los cgroups son los servicios (CPU, memoria, I/O), seccomp/SELinux/AppArmor son la seguridad del edificio.

cgroups (control groups)

cgroups fueron inventados antes de Docker (Linux 2.6.24, 2007) específicamente para resolver el problema de resource partitioning sin virtualización. Permiten poner límites en memoria, swap, CPU, I/O de storage, y network.

Hay dos versiones de cgroups (v1 y v2). Asegúrate de saber cuál usas en producción para aprovechar todas sus capacidades.

Cómo se ven en Docker

Cada container recibe un cgroup único. Todos los procesos del container están en el mismo grupo, así que puedes controlar recursos para el container como un todo sin preocuparte por qué procesos hay dentro.

# Ver CPU shares de un container
docker container inspect <id> | grep CpuShares

# Cambiar en runtime
docker container update --cpu-shares=512 <container_id>

docker container stats usa cgroups internamente para darte CPU%, memoria, I/O por container. No son solo límites, también son métricas.

Configurar cgroups manualmente

Si tienes root en el host, puedes tocar /sys/fs/cgroup directamente para configurar cualquier aspecto:

# Encuentra el ID del container
docker container run -d spkane/train-os stress --cpu 2 --timeout 360s
LONG_ID=<long_container_id>

# Lista los cgroup controllers disponibles
ls /sys/fs/cgroup/docker/$LONG_ID
# cpu.max, cpu.weight, memory.max, memory.current, io.max, etc.

# Mira el CPU weight actual (default 100)
cat /sys/fs/cgroup/docker/$LONG_ID/cpu.weight
# 100

# Cámbialo a la mitad
echo 50 > /sys/fs/cgroup/docker/$LONG_ID/cpu.weight
cat /sys/fs/cgroup/docker/$LONG_ID/cpu.weight
# 50

Namespaces

Los namespaces hacen que cada container vea su propia versión de recursos globales (filesystem, network, hostname, PIDs, UIDs). Son las “paredes” de la oficina.

Tipos de namespaces

Ejemplo: PID namespace

# Crear container
docker container run -d --rm --name pstest spkane/train-os sleep 240

# Desde dentro: el main process es PID 1
$ docker container exec -ti pstest ps -ef
UID  PID  PPID  C  STIME  TTY  TIME  CMD
root   1    0   0  15:33  ?   00:00:00  sleep 240
root  13    0   0  15:33  pts/0   00:00:00  ps -ef

# Desde el host: el mismo proceso es un PID distinto (31396)
$ docker container top pstest
UID   PID    PPID  C  STIME  TTY  TIME     CMD
root  31396  31370  0  15:33  ?    00:00:00  sleep 240

# El PPID 31370 es el containerd-shim
$ docker container run --pid=host ubuntu ps -p 31370
PID  TTY  TIME  CMD
31370  ?   00:00:00  containerd-shim

nsenter

nsenter te permite entrar al namespace de otro proceso desde el host:

# Entra a los namespaces de PID 1 (init del host)
sudo nsenter -t 1 -m -u -n -i sh
# -m: mount
# -u: UTS
# -n: network
# -i: IPC
# -p: PID (sin esto, no compartes PID namespace)

Security

La seguridad de los containers no es comparable a la de una VM, y eso es un punto importante para tener claro.

UID 0 (root)

Por default, los procesos corren como root dentro del container, y ese root es el mismo root del host (a menos que uses rootless mode o userns-remap). Los namespaces dan algo de aislamiento, pero si root escapa del namespace, tiene acceso root al host.

# Peligroso: montar /etc del host
docker container run --rm -it -v /etc:/host_etc ubuntu /bin/bash
root@e674eb96bb74:/# cat /host_etc/shadow
# ¡Root puede leer el /etc/shadow del host!

# Crear un user no-root en el Dockerfile
FROM fedora:34
RUN useradd -u 500 -m myuser
USER 500:500
CMD ["whoami"]

Rootless mode

rootless mode permite correr el daemon de Docker y todos los containers sin root privileges. El daemon corre en el user namespace del usuario no-root, y los containers heredan esa restricción.

# Instalar dependencias
sudo apt-get install -y dbus-user-session uidmap

# Deshabilitar el daemon system-wide
sudo systemctl disable --now docker.service docker.socket
sudo shutdown -r now

# Después del reboot, login como unprivileged user
# Instalar rootless
dockerd-rootless-setuptool.sh install
# ...
# Setear las env vars
export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///run/user/1000/docker.sock

# Verificar
docker container run --rm hello-world

Privileged containers

--privileged=true quita muchas restricciones. El container tiene casi todos los capabilities del kernel:

# Sin --privileged: no puedes cambiar MAC address
$ docker container run --rm -ti spkane/train-os /bin/bash
# [root@...]# ip link set eth0 address 02:0a:03:0b:04:0c
# RTNETLINK answers: Operation not permitted

# Con --privileged: sí puedes
$ docker container run -ti --rm --privileged=true spkane/train-os /bin/bash
# [root@...]# ip link set eth0 address 02:0a:03:0b:04:0c
# (success)

Capabilities

En lugar de --privileged, añade solo las capabilities que necesitas:

# Añade NET_ADMIN (necesario para cambiar MAC)
docker container run --rm --cap-add=NET_ADMIN spkane/train-os /bin/bash

# Quita todas las capabilities y añade solo NET_ADMIN
docker container run --rm --cap-drop=ALL --cap-add=NET_ADMIN spkane/train-os /bin/bash

Capabilities comunes que puedes necesitar:

• NET_ADMIN: configurar network (interfaces, routing, bridges).
• SYS_PTRACE: debuggear procesos del container con strace/gdb.
• SYS_ADMIN: montaje de filesystems, swapon, etc. (riesgosa).
• NET_RAW: usar raw sockets.
• CHOWN: cambiar ownership de files.
• SETUID/SETGID: cambiar UID/GID.

Próximos pasos

• 14-advanced-security-networking-storage: security avanzado (seccomp, AppArmor, SELinux), networking avanzado (host networking, custom networks), storage (volumes, drivers), nsenter en detalle, swapping de runtimes (gVisor, runc alternatives).