¿Por Qué los Contenedores No Deberían Ejecutarse como Root por Defecto?

Ejecutar contenedores como root es una de las configuraciones incorrectas más comunes — y más peligrosas — en entornos de producción. Expande silenciosamente la superficie de ataque de cada carga de trabajo, y la mayoría de los equipos no lo realizan hasta que un incidente obliga el tema.

Qué Significa Realmente "Ejecutarse como Root"

Por defecto, muchas imágenes de contenedor (especialmente las mínimas o heredadas) ejecutan su proceso principal como UID 0 dentro del contenedor. Como los contenedores comparten el kernel del host con otros contenedores y el host en sí, root dentro de un contenedor no es lo mismo que root en una máquina virtual completamente aislada — pero sigue siendo mucho más poderoso de lo que debería ser. Si un atacante logra ejecutar código dentro de un contenedor propiedad de root, hereda:

• Acceso completo de lectura/escritura a cualquier archivo montado en el contenedor, independientemente de los permisos previstos
• La capacidad de instalar paquetes, modificar binarios o manipular el estado de la aplicación
• Un camino mucho más fácil hacia un escape de contenedor si una vulnerabilidad del kernel o runtime es explotable
• Mayor influencia cuando se combina con volúmenes mal configurados, como un socket de Docker montado o una ruta del sistema de archivos del host

Incluso sin un exploit del kernel, el acceso root dentro del contenedor aumenta dramáticamente el radio de impacto de cualquier vulnerabilidad a nivel de aplicación (SSRF, bugs de deserialización, escritura de archivo arbitraria, etc.).

Por Qué Esto Importa Más en Entornos Orquestados

En clusters de Kubernetes, un contenedor root combinado con capacidades de Linux excesivas o un contexto de seguridad permisivo puede permitir que un atacante:

• Modifique /proc o /sys de formas que afecten al host
• Escale privilegios si hostPID, hostNetwork, o hostIPC están habilitados
• Abuse de un token de cuenta de servicio montado para pivotear lateralmente a través del cluster
• Escape al nodo si privileged: true está configurado o se otorgan capacidades peligrosas como SYS_ADMIN

El usuario root en sí no siempre es la vulnerabilidad — es la combinación de root más capacidades de kernel excesivamente generosas, montajes de host o compartición de namespaces lo que convierte un compromiso contenido en uno a nivel de cluster.

Pasos Prácticos de Hardening

1. Establece un Usuario No-Root en la Imagen

Define explícitamente un usuario no-root en tu Dockerfile en lugar de confiar en los valores por defecto:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Aplicaló a Nivel del Orquestador

No simplemente confíes en la imagen — aplica la política en tiempo de ejecución. En Kubernetes, usa un securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true causa que el pod falle en la admisión si la imagen intenta ejecutarse como UID 0, dándote una garantía dura en lugar de una convención de mejor esfuerzo.

3. Descarta Capacidades Innecesarias

La mayoría de las aplicaciones no necesitan ninguna de las capacidades de Linux por defecto otorgadas a los contenedores. Descarta todo y añade de vuelta solo lo estrictamente requerido (casos raros como vincularse a puertos bajos podrían necesitar NET_BIND_SERVICE).

4. Evita Modo Privilegiado y Compartición de Namespaces del Host

privileged: true, hostNetwork: true, y hostPID: true deberían estar reservados para cargas de trabajo de infraestructura muy específicas (como ciertos agentes de CNI o monitoreo) — nunca para contenedores de aplicación general.

5. Escanea y Aplica con Herramientas de Política

Usa controladores de admisión o motores de política (ej. Kyverno, OPA/Gatekeneeper) para rechazar automáticamente despliegues que violen estas reglas, en lugar de confiar en revisión de código manual. Combina esto con escaneo de imágenes en CI para detectar imágenes con usuario root antes de que lleguen a un cluster.

Una Defensa en Capas, No Perfecta

Ejecutarse como no-root no elimina el riesgo completamente — existen escapes de contenedor a nivel de kernel independientemente del usuario dentro del contenedor — pero elimina una enorme clase de técnicas de escalada de privilegios y movimiento lateral de bajo esfuerzo. Combinado con sistemas de archivos de solo lectura, capacidades descartadas y políticas de red restrictivas, forma una de las capas más baratas y efectivas en una estrategia de defensa en profundidad de seguridad de contenedores.

¿Quieres profundizar más en hardening de cargas de trabajo cloud-native? Explora segmentos relacionados de Korra Studio sobre Cloud security y hardening de tuberías DevOps para construir el resto de tu estrategia de defensa en profundidad.