Explorando Podman: una alternativa más segura a Docker

Artículo original ↗ Discusión en Hacker News ↗

Podman está emergiendo como una alternativa popular a Docker, en gran parte por su diseño centrado en la seguridad: contenedores rootless, mejor integración con SELinux y una red menos intrusiva que evita algunos de los problemas de cortafuegos y VPN de Docker. Los comentaristas destacan que Podman a menudo puede servir como reemplazo directo y funciona bien con herramientas como systemd y docker-compose/podman-compose, pero señalan bordes ásperos en torno a las herramientas, los mapeos UID/GID y los problemas de plataforma, especialmente en Apple Silicon. Muchos siguen usando Docker por su ecosistema, documentación y familiaridad, argumentando que el modo rootless de Docker puede abordar preocupaciones de seguridad similares si se configura correctamente.

Modelos de seguridad y contenedores rootless

  • Muchos ven el modelo de Podman de “seguro por defecto” (rootless, espacios de nombres de usuario, sin daemon raíz de larga ejecución) como una gran ventaja frente a Docker.
  • El valor predeterminado de Docker de ejecutarse como root y usar un grupo docker es criticado como un riesgo de seguridad grave en entornos multiusuario / gestionados.
  • Varios comentarios señalan que Docker sí admite el modo rootless y seccomp por defecto, pero no es la ruta lista para usar y se percibe como menos priorizada.
  • Algunos consideran injusta la comparación Podman-rootless vs Docker-como-root; sostienen que la comparación relevante es Docker-rootless vs Podman-rootless.

SELinux y etiquetado

  • Se elogia la adhesión de Podman a las políticas de SELinux por la seguridad en producción, pero causa fricción (los contenedores no pueden acceder a directorios montados con bind).
  • Soluciones: deshabilitar el etiquetado en containers.conf, o usar :z / :Z en los volúmenes para ajustar automáticamente las etiquetas.
  • Las opiniones sobre SELinux van desde “vale la hora que lleva aprenderlo” hasta “un tren descarrilado inutilizable”, aunque algunos insisten en que debería dejarse en modo permisivo en lugar de deshabilitarse.

Comportamiento de red

  • La manipulación de iptables/nftables por parte de Docker es un punto de dolor recurrente: conflictos con cortafuegos (UFW), VPNs y puentes KVM.
  • Se informa que Podman “se lleva bien” con la red del host y KVM, aunque la red rootless tiene limitaciones del kernel.
  • Se desea la modificación dinámica de puertos reenviados, pero se describe como técnicamente difícil dada la complejidad de iptables/nftables.

systemd, Quadlet y orquestación

  • El soporte temprano de Podman para podman generate systemd era popular; el cambio hacia Quadlet divide opiniones. Algunos encuentran Quadlet más limpio; otros lo ven como una complicación innecesaria y vuelven a docker-compose o a unidades escritas a mano.
  • podman-compose puede generar y registrar unidades systemd; algunos lo consideran elegante, otros dicen que es poco descubrible.
  • Varios usan docker-compose/podman-compose en homelabs e incluso en producción pequeña; otros sostienen que los despliegues más grandes deberían pasar a Kubernetes, Swarm o Nomad y desean un orquestador simple “tipo Swarm” nativo de Podman.

Herramientas, compatibilidad y flujo de trabajo del desarrollador

  • Podman es “en su mayoría” un reemplazo directo de Docker; las diferencias sutiles de CLI y de comportamiento pueden romper scripts o configuraciones de compose, especialmente en torno a la red.
  • Usar herramientas de Docker con Podman normalmente implica ejecutar un socket compatible con Docker y apuntar DOCKER_HOST hacia él; algunos lo ven trivial, otros como una fricción innecesaria.
  • El ecosistema de Docker (archivos compose, documentación, comunidad) sigue viéndose como más maduro y accesible, por lo que muchas organizaciones se quedan con Docker para los desarrolladores aunque usen Podman/Buildah en CI.
  • Los usuarios de NixOS destacan herramientas como compose2nix para convertir archivos compose en configuraciones nativas de systemd/OCI.

Experiencias específicas por plataforma

  • En Linux, varios afirman que “ya no hay razón para usar Docker” si Podman está disponible.
  • En macOS (especialmente Apple Silicon) las experiencias son mixtas: algunos reportan años de uso sin problemas; otros sufren bloqueos o congelamientos graves y vuelven a Docker. Podman Desktop a veces funciona donde las instalaciones por CLI no lo hacen.
  • En Windows, se elogia Podman por ser más ligero y menos intrusivo que Docker Desktop, aunque carece de algunas integraciones con IDE.

Motivaciones, política y preocupaciones del ecosistema

  • La inversión de Red Hat en Podman se atribuye a intentos fallidos de colaborar con Docker y a la insatisfacción con la seguridad de Docker, SELinux, systemd y el comportamiento de red.
  • Algunos sostienen que la existencia de Podman, como Linux frente a los sistemas operativos propietarios, es valiosa como control sobre el poder de Docker.
  • Hay debate sobre qué empresa es más confiable; las opiniones difieren sobre Red Hat/IBM frente a Docker, pero la naturaleza totalmente abierta de Podman se ve como una red de seguridad si las direcciones corporativas cambian.

Puntos de dolor y alternativas

  • Los mapeos UID/GID, las ACL y las etiquetas de Podman pueden confundir a los nuevos usuarios; los primeros adoptantes informan que “no simplemente funcionó” y que podman system migrate podía destrozar configuraciones. Otros, que empezaron más tarde, lo encuentran más fácil que Docker.
  • Algunas cargas de trabajo no pueden ejecutarse fácilmente rootless (por ejemplo, montajes NFS), lo que limita el valor de Podman/Docker rootless en esos entornos.
  • Algunos prefieren evitar tanto Docker como Podman para ciertos casos de uso, usando bubblewrap o Buildah directamente y criticando los Dockerfiles como un DSL innecesario.