Docker — Seguridad Runtime (gVisor y Kata Containers)

🎯 Introducción

Si crees que endurecer una imagen es suficiente para dormir tranquilo, te estás equivocando: si el contenedor comparte directamente el kernel del host, el riesgo sigue ahí. Con el runtime por defecto (runc), un contenedor no es más que un proceso extra en el host aislado mediante namespaces, cgroups y seccomp; esto significa que cualquier fallo de aislamiento en el kernel —un CVE de escalada de privilegios o un syscall mal filtrado— puede derivar en una fuga directa hacia el host y todos sus vecinos.

Para solucionar esto necesitamos aislamiento en runtime (sandboxing), una técnica que mete una capa de protección entre el contenedor y el kernel real. En este artículo vamos a centrarnos en las dos soluciones más maduras que existen actualmente: gVisor (un kernel que corre en espacio de usuario) y Kata Containers (contenedores que viven dentro de microVMs). No vamos a perder el tiempo repitiendo conceptos de hardening de imágenes, gestión de secrets o scanning; para eso, tienes que consultar Docker — Seguridad y Scanning, que es el complemento perfecto para lo que vamos a ver aquí.

🧠 El problema del kernel compartido

Con runc, todos los contenedores del host comparten un único kernel Linux. La superficie de ataque es enorme: cientos de syscalls, drivers, filesystems y subsistemas de red. seccomp reduce esa superficie, pero sigue siendo el mismo kernel para todos.

• gVisor intercepta las syscalls del contenedor y las sirve desde un kernel reimplementado en Go (el Sentry), que solo hace un puñado de syscalls reales al host.
• Kata arranca cada contenedor (o pod) dentro de una microVM ligera con su propio kernel invitado, aislado por virtualización de hardware.

🔍 gVisor (runsc)

gVisor implementa un kernel de aplicación en espacio de usuario. El proceso Sentry intercepta las syscalls del contenedor (vía ptrace o, por defecto, la plataforma systrap/KVM) y las procesa sin dárselas al kernel real. El acceso al filesystem pasa por un proceso separado, el Gofer, mediante el protocolo 9P.

Instalación

# Descargar runsc y su shim para containerd
(
  set -e
  ARCH=$(uname -m)
  URL=https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}
  wget ${URL}/runsc ${URL}/runsc.sha512 \
       ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
  sha512sum -c runsc.sha512 -c containerd-shim-runsc-v1.sha512
  rm -f *.sha512
  chmod a+rx runsc containerd-shim-runsc-v1
  sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin
)

Configuración con Docker

# Registra runsc como runtime en el daemon de Docker
sudo runsc install
sudo systemctl reload docker

Esto añade el runtime a /etc/docker/daemon.json:

{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

Ejecutar un contenedor con gVisor:

docker run --rm --runtime=runsc hello-world

# Comprobar que el kernel es el del Sentry, no el del host
docker run --rm --runtime=runsc alpine dmesg | head
# -> se ve "Starting gVisor..." en lugar del kernel real

Configuración con containerd

En /etc/containerd/config.toml:

version = 2

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"

sudo systemctl restart containerd

🔍 Kata Containers (microVMs)

Kata arranca cada pod dentro de una VM ligera usando un hipervisor (QEMU por defecto, o Cloud Hypervisor / Firecracker). El contenedor ve un kernel invitado completo, de modo que el aislamiento lo garantiza la virtualización de hardware (VT-x/AMD-V), no solo el software.

Requisitos

# Verificar soporte de virtualización por hardware
kata-runtime check
# o, manualmente:
egrep -c '(vmx|svm)' /proc/cpuinfo   # > 0 = soportado

Instalación

# Vía kata-manager (script oficial que instala binarios + config)
bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/kata-containers/main/utils/kata-manager.sh)"

Los binarios quedan en /opt/kata/bin/ y la configuración en /opt/kata/share/defaults/kata-containers/configuration.toml.

Configuración con containerd

version = 2

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
  runtime_type = "io.containerd.kata.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
    ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration.toml"

sudo systemctl restart containerd

Prueba directa con ctr:

sudo ctr images pull docker.io/library/alpine:latest
sudo ctr run --runtime io.containerd.kata.v2 --rm \
  docker.io/library/alpine:latest kata-test uname -r
# El kernel mostrado es el invitado de Kata, distinto al del host

☸️ Integración en Kubernetes (RuntimeClass)

Ambos runtimes se exponen a Kubernetes mediante el recurso RuntimeClass. El handler debe coincidir con el nombre del runtime configurado en containerd.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc          # coincide con [...runtimes.runsc]
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata           # coincide con [...runtimes.kata]

Asignar un pod a un runtime sandboxeado:

apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: gvisor      # o "kata"
  containers:
    - name: app
      image: nginx:1.27-alpine

# Fragmento de RuntimeClass con scheduling a nodos etiquetados
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
scheduling:
  nodeSelector:
    katacontainers.io/kata-runtime: "true"
  tolerations:
    - key: "kata"
      operator: "Exists"
      effect: "NoSchedule"

⚖️ Comparativa: runc vs gVisor vs Kata

🧭 ¿Cuándo usar cada uno?

⚠️ Limitaciones

🔗 Enlaces relacionados

• Docker — Seguridad y Scanning — hardening de imágenes, secrets y escaneo (complemento de esta guía).
• Docker — Base
• Docker — Optimizaciones
• gVisor — Documentación oficial
• Kata Containers — Documentación oficial
• Kubernetes — RuntimeClass