Docker se volvió sinónimo de contenedores, pero eso no significa que sea la única opción, ni siempre la más adecuada para producción. Cuando un equipo de seguridad audita una infraestructura containerizada, la primera pregunta suele ser: ¿qué proceso corre con privilegios de root y quién puede escalar a través de él? Con Docker clásico, la respuesta casi siempre es incómoda.
El problema del demonio root
Docker funciona mediante un demonio (dockerd) que corre permanentemente con privilegios de root, y todos los contenedores se lanzan como hijos de ese proceso. Cualquiera con acceso al socket de Docker tiene, en la práctica, acceso root a todo el host — es una superficie de ataque conocida desde hace años. Podman elimina esa arquitectura: no tiene demonio, cada contenedor es un proceso hijo directo del usuario que lo lanzó, y puede correr completamente en modo rootless sin ningún privilegio elevado.
Qué cambia en la práctica
- Sin demonio: Podman lanza contenedores como procesos independientes, sin un servicio central que, si se compromete, compromete todo lo que administra.
- Rootless real: un usuario sin privilegios puede correr contenedores completos sin necesitar sudo ni pertenecer al grupo docker (que de por sí equivale a root).
- Compatibilidad de comandos: Podman implementa la misma CLI que Docker casi 1:1 — en la mayoría de los casos,
alias docker=podmanalcanza para migrar sin reescribir scripts. - Pods nativos: Podman puede agrupar contenedores en pods al estilo Kubernetes de forma nativa, lo que facilita la transición a K8s el día que la infraestructura lo requiera.
- Sin punto único de falla: si un contenedor se cae en Docker con el demonio caído, pueden caer todos los contenedores del host; en Podman, cada uno es independiente.
| Aspecto | Docker | Podman |
|---|---|---|
| Arquitectura | Demonio centralizado con privilegios root | Sin demonio, procesos independientes |
| Modo rootless | Soportado, pero no es el default ni el más maduro | Nativo y recomendado como default |
| Ecosistema | Más maduro, Docker Compose ampliamente adoptado | Compatible vía podman-compose, creciendo |
| Integración Kubernetes | Requiere adaptación (containerd/CRI-O) | Genera pods nativamente compatibles |
Cuándo migramos y cuándo no
No recomendamos migrar por moda. Docker sigue siendo sólido para equipos chicos con infraestructura simple y buena higiene de acceso al socket. La migración a Podman tiene sentido concreto cuando hay múltiples usuarios operando contenedores sobre el mismo host, cuando la auditoría de seguridad exige minimizar procesos con privilegios root, o cuando el roadmap apunta a Kubernetes y conviene adoptar una arquitectura de pods desde antes.
Metodología de trabajo
- Relevamiento del stack de contenedores actual y dependencias de Docker Compose.
- Prueba de compatibilidad en entorno de staging con podman-compose.
- Migración gradual, servicio por servicio, con rollback documentado.
- Configuración de modo rootless para los servicios que lo permiten.
- Capacitación del equipo interno en la CLI y en las diferencias operativas reales.
Cuándo lo recomendamos
Infraestructuras multiusuario donde el acceso al socket de Docker hoy equivale a root compartido, organizaciones bajo auditoría de seguridad que necesitan justificar cada proceso con privilegios elevados, y equipos que planean adoptar Kubernetes en el corto o mediano plazo.
¿Sabés quién tiene acceso root en tu infraestructura de contenedores?
Evaluamos tu stack actual y armamos un plan de migración a Podman sin downtime, con capacitación incluida para tu equipo.