Implementaciones sin daemon en Edge: Arquitectura de pipelines CI/CD sin daemon con Podman y Buildah

Exponer un socket Docker a nivel raíz en un pipeline que tiene acceso directo a tu hardware físico local es una bomba de tiempo en la cadena de suministro. Es hora de eliminar completamente el daemon. Aquí te mostramos cómo diseñar pipelines de despliegue totalmente rootless y sin daemon usando Podman y Buildah — y qué cambios ha habido en el ecosistema de contenedores sin root hasta mediados de 2026.

1. La vulnerabilidad del socket compartido

En entornos tradicionales de CI/CD, la dependencia de Docker ha establecido un anti patrón arquitectónico generalizado: montar el socket del daemon Docker a nivel raíz (/var/run/docker.sock) directamente dentro de los runners del pipeline. A esto se le llama comúnmente Docker-in-Docker (DinD) o montaje de socket, y este patrón otorga al proceso del runner acceso administrativo completo al motor host. Es conveniente para construir, etiquetar y subir imágenes OCI, pero representa un vector de amenaza grave en pipelines que gestionan hardware local, gateways edge o proxies localizados.

[ Componente de runner CI/CD comprometido ]
                │
                ▼ (Ejecuta payload malicioso)
   [ Llamada API a /var/run/docker.sock ]
                │
                ▼ (Escala rápidamente a raíz del host)
[ Hardware físico / recursos del sistema comprometidos ]

Cuando un pipeline tiene un acceso explícito a hardware físico — interfaces IIoT, redes SCADA, sistemas médicos o nodos de IA en el edge — una fuga de contenedor no es solo un fallo de software localizado. Es un vector para daño ciberfísico. Como dockerd se ejecuta nativamente como root, cualquier proceso que pueda acceder a su socket UNIX sin cifrar puede emitir llamadas API arbitrarias: docker run --privileged -v /:/host desde una dependencia comprometida es suficiente para comprometer el sistema host directamente.

Esto no es una hipótesis. CVE-2024-21626 (“Vasos con fuga”), divulgado en enero de 2024, mostró exactamente esta clase de fallo en la práctica: una fuga interna de descriptor de archivo en runc (versiones hasta 1.1.11) permitió que una imagen maliciosa o payload runc exec estableciera el directorio de trabajo de un contenedor en un descriptor de archivo filtrado que apunta al sistema de archivos del host — haciendo que el proceso del contenedor salga de su raíz propia, con un camino documentado para sobrescribir binarios del host. Se corrigió en runc 1.1.12, pero ilustra claramente por qué el radio de explosión de una fuga en tiempo de ejecución importa tanto como la probabilidad de que ocurra. Un daemon que corre como root convierte cualquier bug en una compromisión total del host; un pipeline rootless bien configurado convierte ese mismo bug en una cuenta de servicio de bajo privilegio sin acceso a binarios del sistema, módulos del kernel o dispositivos físicos.

Para proteger infraestructuras industriales, la arquitectura moderna requiere abandonar por completo el daemon monolítico de contenedores en favor de mecanismos de aislamiento donde la creación de contenedores y la construcción de imágenes se ejecuten nativamente dentro de espacios de usuario no privilegiados — el enfoque en el que se construyeron Podman y Buildah.

2. Desglose técnico: arquitectura de Podman y Buildah

Arquitectura tradicional de Docker:

[ CLI del cliente ] ──(socket UNIX/TCP)──► [ Daemon monolítico central (dockerd) ] ──► [ Runtime OCI (runc) ]

Arquitectura sin daemon:

[ CLI de Podman / Buildah ] ──(fork/exec directo en Linux vía namespaces)──► [ Runtime OCI (crun / runc) ]

El modelo cliente-servidor de Docker traduce la entrada CLI en llamadas REST enviadas a través de un socket a dockerd, un proceso que corre continuamente y gestiona cada contenedor como un hijo. Si el daemon falla, la orquestación de todos los contenedores en el host se rompe.

Por el contrario, Podman y Buildah siguen un modelo de fork-exec cercano al ciclo de vida de procesos Linux tradicionales. El binario es una utilidad efímera: se comunica directamente con el kernel mediante un runtime compatible con OCI (crun o runc), rastrea el estado a través de la biblioteca descentralizada containers/storage, y termina una vez que la tarea concluye. No hay un servicio en segundo plano de larga duración ni un socket API expuesto.

Componentes clave

• Podman (Gestor de pods) — gestiona, ejecuta y depura pods y contenedores OCI (run, stop, ps, exec) sin daemon.
• Buildah — utilidad enfocada en construir imágenes OCI. Podman usa internamente las bibliotecas de Buildah para podman build; Buildah independiente ofrece comandos de construcción en capas, scriptables y granulares.
• Skopeo — inspecciona, firma y copia imágenes entre registros y almacenamiento local sin descargar y desempaquetar capas completas.

Espacios de usuario: mecanismo detrás de la ejecución sin root

El aislamiento sin root depende de los espacios de usuario Linux (user_namespaces(7)), que mapean un rango de UIDs/GIDs del host a un conjunto diferente dentro del contenedor. Cuando una cuenta no privilegiada inicia una instancia de Podman sin root, el kernel mapea el UID real del usuario (por ejemplo, 1001) a UID 0 dentro del namespace del contenedor. Cualquier intento de esa proceso de acceder fuera del límite del contenedor se traduce de vuelta a UID 1001 en el host.

Si un ataque en la cadena de suministro logra inyectar un payload malicioso en un contenedor que corre en un pipeline rootless, y el payload explota una vulnerabilidad en tiempo de ejecución para escapar, el atacante aterriza en el host como esa misma cuenta de servicio de bajo privilegio — no como root. No puede modificar binarios del sistema, cargar módulos del kernel ni tocar dispositivos físicos directamente.

3. Configuración de espacios de usuario para provisión de hardware

El mapeo de espacios de usuario sin root depende de los archivos /etc/subuid y /etc/subgid del host, que asignan bloques de UIDs/GIDs subordinados a cuentas no privilegiadas.

gitlab-runner:100000:65536

Tres campos delimitados por dos puntos: - Identificador — la cuenta de servicio del host (gitlab-runner) - UID subordinado inicial — inicio del bloque asignado (100000) - Rango — número de UIDs concedidos (65536)

UID interno del contenedor	Mapeo UID en host	Descripción
0 (raíz interno)	1001	UID real de la cuenta de servicio en el host
1	100000	Primer UID subordinado en el rango
2	100001	Segundo UID subordinado
65535	165535	Último UID subordinado en el bloque

Los gestores de paquetes modernos ahora proveen esto automáticamente — sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 <usuario> — pero las cuentas de servicio del pipeline creadas por infraestructura como código aún necesitan que esto se configure explícitamente, y vale la pena verificar con grep <usuario> /etc/subuid /etc/subgid en lugar de asumir que ya está.

Controladores de almacenamiento: overlay nativo ha reemplazado mayormente fuse-overlayfs

El requisito original era real, pero ahora está desactualizado, y vale ser precisos sobre qué ha cambiado. Los contenedores con privilegios usan directamente el sistema de archivos overlay del kernel. Durante años, los usuarios sin privilegios no podían montar overlay en absoluto, por lo que Podman sin root recurría a fuse-overlayfs, una implementación basada en FUSE que maneja copy-on-write en espacio de usuario sin tocar el subsistema de montaje privilegiado del host.

Esa solución alternativa ya no es estrictamente necesaria en kernels actuales. Linux 5.11 añadió montaje overlay sin privilegios, pero un bug en el etiquetado SELinux significaba que no era seguro confiar en ello hasta kernel 5.13, donde se corrigió. Desde entonces, Podman prefiere native overlay sin root siempre que el kernel lo soporte, porque fuse-overlayfs es un sistema de archivos en espacio de usuario que debe interpretar cada lectura/escritura antes de entregarla al kernel del host — una sobrecarga real y medible en cargas de trabajo intensas de construcción o escritura. fuse-overlayfs sigue siendo relevante como fallback en kernels antiguos, para directorios home en NFS (que no toleran múltiples UIDs en el servidor), o en escenarios específicos de contenedor dentro de contenedor donde /dev/fuse es más fácil de conceder que soporte native completo.

Implicación práctica para el diseño de pipelines: verifica podman info | grep -i "native overlay" (o Native Overlay Diff: true en la salida de info) en tus hosts de runner antes de asumir que necesitas fuse-overlayfs. En kernels 5.13+, la configuración recomendada en ~/.config/containers/storage.conf ya no requiere una línea mount_program:

[storage]
driver = "overlay"

[storage.options.overlay]
# El overlay nativo sin root se usa automáticamente en kernels 5.13+.
# Solo descomenta las siguientes líneas como fallback en kernels antiguos,
# directorios home en NFS, o escenarios de contenedor anidado.
# mount_program = "/usr/bin/fuse-overlayfs"
mountopt = "nodev,metacopy=on"

metacopy=on sigue siendo válido en ambos casos — evita copiar datos de capas inferiores hasta que se modifiquen, acelerando significativamente construcciones con imágenes base grandes.

4. Guía para construcción de imágenes sin daemon con Buildah

Buildah es muy adecuado para construcciones programáticas y por scripting, en lugar de parseo estático de Dockerfile, útil cuando un pipeline necesita extraer matrices de configuración local, compilar firmware, y montar una imagen endurecida sin capas intermedias adicionales.

#!/usr/bin/env bash
set -o errexit
set -o pipefail
set -o nounset

# Paso 1: Inicializar un entorno de trabajo limpio desde una imagen base mínima
echo "=== Inicializando contenedor OCI base ==="
container=$(buildah from alpine:3.19)

# Paso 2: Montar el sistema de archivos raíz del contenedor en el espacio no privilegiado del host
echo "=== Exponiendo capa del sistema de archivos del contenedor ==="
container_mount=$(buildah mount "${container}")

# Paso 3: Proveer la capa de la aplicación
echo "=== Provisionando capa de la aplicación y artefactos edge ==="
mkdir -p "${container_mount}/opt/edge/proxy"
mkdir -p "${container_mount}/etc/edge"

echo "Iniciando ciclo de comunicación endurecido"  "${container_mount}/opt/edge/proxy/core.bin"
chmod 755 "${container_mount}/opt/edge/proxy/core.bin"

# Paso 4: Configurar el contenedor
echo "=== Aplicando configuración del contenedor ==="
buildah config --workingdir "/opt/edge/proxy" "${container}"
buildah config --entrypoint '["/opt/edge/proxy/core.bin"]' "${container}"
buildah config --user "1001:1001" "${container}"
buildah config --label architecture="edge-hardened" "${container}"
buildah config --env PROXY_PORT="8080" "${container}"

# Paso 5: Confirmar en almacenamiento inmutable local
echo "=== Confirmando imagen OCI sellada ==="
buildah commit --rm "${container}" "localhost/edge-proxy:v1.0.0"

echo "=== Construcción completa: localhost/edge-proxy:v1.0.0 ==="

Por qué esto importa en la práctica: - Sin sockets expuestos — toda la construcción sucede dentro del proceso del pipeline, sin daemon en segundo plano. - Control granular de archivos — buildah mount da acceso directo al sistema de archivos, evitando la sobrecarga de capas repetidas con instrucciones RUN cp / ADD. - Definición de destino sin root — buildah config --user "1001:1001" garantiza que la imagen desplegada corra sin privilegios en hardware de destino.

A mediados de 2026, Buildah llega a v1.44.0 (lanzado el 27 de mayo de 2026) y la línea estable de Podman está en v5.8.x (v5.8.2, abril de 2026) — vale la pena fijar versiones explícitamente en las imágenes CI en lugar de usar :latest, ya que ambos proyectos lanzan parches de seguridad con frecuencia (más en la lista de verificación abajo).

5. Guía de implementación: pipeline seguro de provisión en el edge

El siguiente ejemplo usa sintaxis de GitLab CI/CD; la estructura es directamente compatible con GitHub Actions, Tekton o Jenkins.

stages:
  - lint
  - build
  - provision

variables:
  # Aislar capas de almacenamiento dentro del espacio de trabajo del runner local
  CONTAINERS_STORAGE_CONF: "$CI_PROJECT_DIR/.containers/storage.conf"
  REGISTRY_AUTH_FILE: "$CI_PROJECT_DIR/.containers/auth.json"
  STORAGE_DRIVER: "overlay"

default:
  before_script:
    - mkdir -p $(dirname "$CONTAINERS_STORAGE_CONF")
    - |
      echo '[storage]'  "$CONTAINERS_STORAGE_CONF"
      echo 'driver = "overlay"'  "$CONTAINERS_STORAGE_CONF"
      # El overlay nativo sin root se usa automáticamente en kernels 5.13+;
      # descomenta las dos líneas siguientes solo si tu kernel es anterior a esa.
      # echo '[storage.options.overlay]'  "$CONTAINERS_STORAGE_CONF"
      # echo 'mount_program = "/usr/bin/fuse-overlayfs"'  "$CONTAINERS_STORAGE_CONF"
    - podman login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"

build_edge_image:
  stage: build
  tags:
    - rootless-edge-runner
  script:
    - echo "Construyendo recurso edge (sin root)..."
    - podman build --storage-driver=$STORAGE_DRIVER --layers -t "$CI_REGISTRY_IMAGE/edge-node:$CI_COMMIT_SHA" .
    - echo "Subiendo imagen al registro..."
    - podman push "$CI_REGISTRY_IMAGE/edge-node:$CI_COMMIT_SHA"

provision_local_hardware:
  stage: provision
  tags:
    - rootless-edge-runner
  script:
    - echo "Provisionando dispositivo edge vía SSH..."
    - |
      ssh -i "$EDGE_PROXY_DEPLOY_KEY" -o StrictHostKeyChecking=require "$EDGE_PROXY_USER@$EDGE_PROXY_IP"  EOF
        set -e
        echo "Conectado a gateway de despliegue físico."

        podman login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
        podman pull "$CI_REGISTRY_IMAGE/edge-node:$CI_COMMIT_SHA"

        podman stop telemetry-collector || true
        podman rm telemetry-collector || true

        # Sin --privileged, sin montar en host. Los dispositivos se mapean explícitamente.
        podman run -d \
          --name telemetry-collector \
          --restart=always \
          --user=1001:1001 \
          --security-opt label=disable \
          --device /dev/ttyUSB0:/dev/ttyUSB0:rw \
          -p 8443:8443 \
          "$CI_REGISTRY_IMAGE/edge-node:$CI_COMMIT_SHA"

        echo "Interfaz de hardware inicializada y transmitiendo."
      EOF
  only:
    - main

Medidas de seguridad integradas en este pipeline: - Contexto de almacenamiento aislado — reescribir CONTAINERS_STORAGE_CONF en $CI_PROJECT_DIR previene la fuga de capas entre tenants en runners compartidos. - Mapeo explícito de --device — en lugar de --privileged, que expone todos los dispositivos del host, --device /dev/ttyUSB0:/dev/ttyUSB0:rw mapea solo la interfaz específica que necesita la carga de trabajo. - Red en espacio de usuario — los contenedores sin root dependen de un helper de red en espacio de usuario en lugar de puentes y reglas iptables de root (detalles abajo — esta es una de las áreas que más ha cambiado desde 2024).

6. Qué ha cambiado realmente: redes, almacenamiento y versiones en 2026

Esta sección es la más propensa a quedar obsoleta en un artículo sobre contenedores sin root, así que vale ser explícito sobre el estado actual a mediados de 2026.

Pasta reemplazó a slirp4netns como backend de red predeterminado en entornos sin root. Durante años, Podman sin root dependió de slirp4netns, que crea una interfaz virtual y traduce cada paquete mediante NAT en espacio de usuario — funcional, pero con sobrecarga real por paquete y cuellos de botella en cargas altas. Desde Podman 5.0 (y como predeterminado desde 5.3), pasta (también llamado passt) tomó el relevo. Pasta es una reescritura desde cero que refleja la configuración de red del host (direcciones, rutas, MTU) directamente en el contenedor en lugar de usar NAT, eliminando una parte significativa del “impuesto sin root”. No es una victoria absoluta en todos los aspectos — benchmarks independientes muestran que pasta supera a slirp4netns hasta niveles moderados de paralelismo en conexiones, aunque en alta concurrencia slirp4netns aún compite, y cada proceso pasta consume algo más de memoria (mediciones comunitarias estiman unos 29 MB frente a 3–4 MB por contenedor en slirp4netns) — pero para la mayoría de cargas de trabajo en gateways edge y CI, eliminar el salto NAT es el cambio más relevante. slirp4netns será completamente eliminado en la próxima versión Podman 6.0 (en desarrollo activo como propuesta en Fedora a mediados de 2026), junto con cgroups v1 y el antiguo backend de almacenamiento BoltDB, por lo que los pipelines que aún usen network=slirp4netns deberían planear migrar.

La restricción de puertos bajos sigue vigente. net.ipv4.ip_unprivileged_port_start aún por defecto en 1024 en kernels estándar, bloqueando enlaces no privilegiados a puertos menores. La recomendación original — reducirlo mediante un archivo dedicado en /etc/sysctl.d/ en lugar de editar /etc/sysctl.conf directamente — sigue siendo válida:

# /etc/sysctl.d/99-rootless-ports.conf
net.ipv4.ip_unprivileged_port_start=443

Configurar esto en 443 en lugar de 0 mantiene la restricción significativa (los servicios privilegiados por debajo de 443 permanecen bloqueados) y permite el ingreso HTTPS estándar para proxies en el edge sin root.

Permisos de volumen y mapeo UID en host y contenedor siguen resolviéndose igual: banderas SELinux :Z/:z, o --userns=keep-id para mapear el UID real del usuario que invoca directamente en el contenedor.

Huella de memoria inactiva: real, pero “0 MB” es una sobreestimación. La afirmación central — que un runtime sin daemon no tiene proceso en segundo plano permanente, mientras que dockerd sí — es correcta y relevante en hardware edge con recursos limitados. Benchmarks independientes de 2026 muestran que un par dockerd + containerd en reposo ocupa entre aproximadamente 55 y 200 MB de RSS dependiendo de la versión y configuración, comúnmente alrededor de 140–150 MB. La cantidad inactiva de Podman es mucho menor, ya que no hay un proceso daemon persistente — pero “cero” no es literal: un contenedor en ejecución mantiene vivo un monitor ligero conmon por contenedor, y un proceso pasta (~29 MB) si ese contenedor tiene su propio namespace de red. La conclusión importante para dimensionar hardware en edge es que la sobrecarga de Docker existe incluso sin contenedores activos, y la de Podman no.

7. Lista de verificación arquitectónica: endurecimiento de la pila de contenedores

                 ┌────────────────────────────────────────┐
                 │  AUDITORÍA DE ENDURECIMIENTO SIN DAEMON  │
                 └────────────────────────────────────────┘
                                      │
     ┌────────────────────────────────┼────────────────────────────────┐
     ▼                                ▼                                ▼
[ NAMESPACES DE USUARIO ]   [ SIN DAEMONS ACTIVOS ]          [ DISPOSITIVOS GRANULARES ]
  Verificado vía               Sin dockerd activo               Solo caminos explícitos
  /etc/subuid y /etc/subgid   en ejecución en el host          mapeados con --device

• [ ] Verificar límites de espacios de usuario — cada cuenta del runner tiene una entrada en /etc/subuid y /etc/subgid con al menos 65,536 IDs asignados.
• [ ] Imponer ejecución sin daemon — dockerd debe ser completamente eliminado o deshabilitado (systemctl disable --now docker) en todo el sistema.
• [ ] Validar origen de la imagen antes de ejecutar en hardware — usar Skopeo junto con cosign para verificar firmas. Esto no es solo para cumplir, en 2026 se descubrieron vulnerabilidades reales en este espacio, incluyendo CVE-2026-44517 (vulnerabilidad de traversal en construcción de contenedores) y CVE-2026-57231 (fuga de variables de entorno maliciosas en imágenes), que deben incluirse en la lista de verificación de endurecimiento, además de asegurar que las herramientas de firma y whitelist de registros estén en uso.
• [ ] Aplicar privilegios mínimos a dispositivos — reemplazar cada --privileged por mapeos explícitos --device y --cap-add específicos (por ejemplo, CAP_NET_ADMIN, CAP_SYS_RAWIO) solo donde sea estrictamente necesario.
• [ ] Configurar ejecución de contenedores sin root — construir y ejecutar cargas útiles bajo un USER no root (1001 o similar).
• [ ] Mantener el runtime parcheado, no solo las imágenes base — runc, que usan Podman y Buildah, ha tenido múltiples CVEs de escape de contenedores divulgados (CVE-2024-21626, y otros más recientes como CVE-2025-31133, CVE-2025-52565, CVE-2025-52881), todos corregidos en runc 1.3.4 incluido en Buildah 1.42. La fijación de versiones en CI sin un ciclo de parches implica heredar los CVEs del runtime en esa versión.

Conclusión

Exponer un socket Docker a nivel raíz en un pipeline con acceso directo a infraestructura física es una vulnerabilidad crítica y bien documentada — no solo teórica, como demuestran CVE-2024-21626 y sucesores. Pasar a un modelo descentralizado, sin daemon, con Podman y Buildah lo mitiga estructuralmente: un compromiso en la cadena de suministro llega como usuario no privilegiado, no como root. Lo que ha cambiado desde que el enfoque sin daemon ganó tracción es en su mayoría buenas noticias: soporte nativo de overlay en kernels modernos elimina la mayor parte de la carga de rendimiento histórica de FUSE, y pasta elimina la mayor parte de la carga de NAT en redes sin root. Los fundamentos — aislamiento por espacios de usuario, mapeo explícito de dispositivos, verificación de firmas de imágenes y un ciclo de parches real para el runtime — siguen siendo la base para fortalecer pipelines de despliegue en el edge.

---

Registro de cambios

Metadatos eliminados: Se eliminaron metadatos originales y artefactos de formato para publicación.

Verificado y corregido: - Corrigió “Docker-in-Docker (DinD) o socket-mouting” a “socket-mounting.” - Corrigió inconsistencias en nombres de variables en el ejemplo del pipeline (LOCAL_PROXEY_USER, tags del runner en build y provision) para coherencia interna. - Verificó el valor por defecto de net.ipv4.ip_unprivileged_port_start (1024) y el enfoque de mitigación sysctl contra la documentación del kernel y soporte de Red Hat. - Verificó CONTAINERS_STORAGE_CONF y REGISTRY_AUTH_FILE como variables de entorno reales usadas por las bibliotecas containers/storage y containers/image.

Ampliado con información actual (2026): - Añadido ejemplo concreto (CVE-2024-21626 / “Vasos con fuga”) de la clase de escape de contenedores que antes solo se discutía hipotéticamente. - Actualizado la sección de controladores de almacenamiento: overlay nativo (kernel 5.13+) ha reemplazado fuse-overlayfs como recomendación predeterminada; fuse-overlayfs ahora se presenta como fallback. - Añadido una sección sobre pasta reemplazando a slirp4netns como backend de red predeterminado en Podman desde versiones 5.0/5.3, incluyendo sus compromisos de rendimiento y la eliminación planificada en Podman 6.0. - Reemplazó la afirmación no referenciada de “Memoria inactiva de Docker: 140–180 MB / Podman: 0 MB” por un rango basado en múltiples benchmarks independientes de 2026, con la advertencia importante de que la huella de Podman es casi cero en realidad, una vez considerados conmon y procesos pasta. - Añadidas versiones actuales: Podman 5.8.2 (abril 2026), Buildah 1.44.0 (mayo 2026), y la propuesta en desarrollo de Podman 6.0 en Fedora. - Añadidos CVEs relevantes de la cadena de suministro en 2026 (CVE-2026-44517, traversal en contexto de construcción; CVE-2026-57231, fuga de variables en imágenes maliciosas) a la lista de endurecimiento, además de los CVEs en runc (CVE-2025-31133/52565/52881) corregidos en Buildah 1.42, para que la lista sea concreta en la recomendación de mantener las herramientas parcheadas.

Formateo: Se convirtieron diagramas internos y bloques de código etiquetados en bloques de código Markdown con etiquetas de idioma apropiadas; la lista de verificación se estructuró como lista de tareas Markdown; se añadió una tabla comparativa para el mapeo UID.