Podman: contenedores sin daemon ni root

Podman es la alternativa a Docker que más ha madurado en los últimos años. Promovido por Red Hat y empaquetado por defecto en RHEL/Fedora, en 2023 ya es una opción técnicamente sólida que vale la pena conocer — sobre todo si tu prioridad es seguridad o trabajas en entornos donde un daemon corriendo como root es un problema.

La diferencia arquitectónica

Docker tiene un daemon (dockerd) que corre como root y a través del cual pasan todos los comandos del CLI. Podman, en cambio, ejecuta los contenedores como procesos hijos directos del usuario que invoca el comando. No hay servicio central.

Las consecuencias de este cambio:

• Sin punto único de fallo. Si “el daemon” muere, mueren todos los contenedores. En Podman, cada contenedor es independiente.
• Rootless por defecto. Podman puede ejecutar contenedores sin privilegios de root usando user namespaces. Docker también lo soporta desde 2020, pero requiere configuración adicional.
• Integración con systemd. Podman puede generar units de systemd para gestionar contenedores como servicios del sistema. Sin necesidad de restart: always ni un orquestador.
• Auditoría más limpia. Cada contenedor aparece en ps con el usuario que lo lanzó, no como hijo del daemon.

Compatibilidad con Docker

La compatibilidad CLI es prácticamente total:

alias docker=podman

Para la mayoría de comandos básicos (run, build, pull, push, exec, logs), Podman es drop-in. También consume Dockerfile sin modificaciones, soporta el mismo formato de imágenes OCI, y usa los mismos registros (Docker Hub, Quay, GHCR).

Lo que sí difiere:

• Compose. podman-compose existe pero no tiene el polish de Docker Compose. Para stacks complejos con múltiples servicios, la experiencia no está al mismo nivel — aunque mejora cada release.
• Swarm. Podman no tiene equivalente. Si dependes del modo Swarm de Docker, no es una sustitución directa.
• Docker Desktop. Existe Podman Desktop, igualmente abierto, pero el ecosistema de extensiones es menor.

El argumento de seguridad

Si trabajas en sectores regulados, el modo rootless es probablemente la razón principal para considerar Podman:

• Un contenedor escapa → no obtiene root del host, solo el del usuario que lo lanzó.
• Sin un daemon expuesto en /var/run/docker.sock que cualquier proceso con acceso a ese socket pueda controlar.
• Auditoría más granular — cada podman run aparece como una syscall del usuario real, trazable en logs de auditd.

Para un entorno de desarrollo donde varios desarrolladores comparten un servidor, esto reduce drásticamente la superficie de ataque. Para un servidor de producción donde solo corre tu stack, la diferencia es menor pero no nula.

Buildah, Skopeo y la separación de responsabilidades

Una decisión interesante de Red Hat: separar las funciones que en Docker hace un único binario en herramientas distintas:

• podman: ejecuta contenedores.
• buildah: construye imágenes (más flexible que docker build).
• skopeo: copia imágenes entre registros, inspecciona sin descargar.

Esta modularidad tiene ventajas: para una pipeline CI que solo necesita construir imágenes, instalar buildah pesa menos que Docker entero. Y skopeo permite inspeccionar imágenes remotas sin descargarlas — útil para pipelines de validación.

Casos donde Podman es la elección obvia

• Entornos sin acceso a root. Servidores corporativos donde cada usuario tiene su sandbox.
• Workstations de desarrollo en RHEL/Fedora. Ya viene preinstalado, integración natural.
• Pipelines CI rootless. Algunos runners de Gitea/GitLab/Jenkins evitan privilegios elevados.
• Sistemas que ya usan systemd intensivamente. Generar units para contenedores se siente nativo.
• Auditoría regulatoria. Cuando “un daemon corriendo como root” no pasa la revisión de seguridad.

Cuándo seguir con Docker

• Producción con Swarm. No hay sustituto directo.
• Equipos con muchas integraciones a Docker Desktop. Migración no trivial.
• Compose stacks complejos en producción. La paridad de podman-compose no es total todavía.
• Cuando el ecosistema de tu equipo está maduro en Docker y la ganancia de cambiar no compensa la fricción.

Convivencia razonable

Una opción intermedia que suelo recomendar: usa Podman en estaciones de desarrollo y CI, mantén Docker en producción si ya está consolidado. La compatibilidad de imágenes es total — lo que builds con buildah corre en Docker sin problema. Esto da los beneficios de seguridad donde más impactan (entornos compartidos) sin migrar producción de golpe.

Si vas a empezar de cero un proyecto pequeño en 2023, vale la pena probar Podman desde el principio. Si vienes de un ecosistema Docker establecido, no hay urgencia para migrar.

Conclusión

Podman ya no es “el experimento de Red Hat” — es una alternativa real con ventajas claras en seguridad y arquitectura. La compatibilidad con Docker es alta pero no completa, y eso conviene saberlo antes de prometer migraciones globales. Para casos de uso específicos (rootless, auditoría, entornos sin daemon) es la mejor opción disponible. Para producción Swarm, sigue sin ser sustituto.

Síguenos en jacar.es para más sobre contenedores, seguridad y herramientas de infraestructura.