Explorando o Podman: Uma alternativa ao Docker mais segura

Artigo original ↗ Discussão no Hacker News ↗

O Podman está surgindo como uma alternativa popular ao Docker, em grande parte por causa do seu design com foco em segurança: contêineres rootless, melhor integração com SELinux e rede menos intrusiva, evitando alguns dos problemas de firewall e VPN do Docker. Os comentaristas destacam que o Podman muitas vezes pode servir como substituto direto e funciona bem com ferramentas como systemd e docker-compose/podman-compose, mas apontam arestas em ferramentas, mapeamentos UID/GID e problemas de plataforma, especialmente no Apple Silicon. Muitos ainda ficam com o Docker por causa do ecossistema, da documentação e da familiaridade, argumentando que o modo rootless do Docker pode atender a preocupações de segurança semelhantes se configurado corretamente.

Modelos de segurança e contêineres rootless

  • Muitos veem o modelo “seguro por padrão” do Podman (rootless, namespaces de usuário, sem daemon raiz de longa execução) como uma grande vantagem sobre o Docker.
  • O padrão do Docker de rodar como root e usar um grupo docker é criticado como um sério risco de segurança em ambientes multiusuário / gerenciados.
  • Vários comentários observam que o Docker de fato suporta modo rootless e seccomp por padrão, mas isso não é o caminho padrão e é percebido como menos priorizado.
  • Alguns consideram injusta a comparação Podman-rootless vs Docker-com-root; argumentam que a comparação relevante é Docker-rootless vs Podman-rootless.

SELinux e rotulagem

  • A adesão do Podman às políticas SELinux é elogiada pela segurança em produção, mas causa atrito (contêineres não conseguem acessar diretórios montados via bind).
  • Contornos: desativar a rotulagem em containers.conf, ou usar :z / :Z em volumes para ajustar automaticamente os rótulos.
  • As opiniões sobre SELinux variam de “vale a hora para aprender” a “desastre inutilizável”, embora alguns insistam que ele deveria ser deixado em modo permissivo em vez de ser desativado.

Comportamento de rede

  • A manipulação de iptables/nftables pelo Docker é um ponto recorrente de dor: conflitos com firewalls (UFW), VPNs e bridges KVM.
  • Relata-se que o Podman “se dá bem” com rede do host e KVM, embora a rede rootless tenha limitações do kernel.
  • A modificação dinâmica de portas encaminhadas é desejada, mas descrita como tecnicamente difícil dada a complexidade do iptables/nftables.

systemd, Quadlet e orquestração

  • O suporte inicial do Podman para podman generate systemd era popular; a mudança para Quadlet é divisiva. Alguns acham o Quadlet mais limpo; outros o veem como uma complicação desnecessária e voltam para docker-compose ou unidades escritas manualmente.
  • O podman-compose pode gerar e registrar unidades systemd; alguns acham isso elegante, outros dizem que é pouco descobrível.
  • Vários usam docker-compose/podman-compose em homelabs e até em produção pequena; outros argumentam que implantações maiores deveriam migrar para Kubernetes, Swarm ou Nomad e gostariam de um orquestrador simples “tipo Swarm” nativo do Podman.

Ferramentas, compatibilidade e fluxo de trabalho do desenvolvedor

  • O Podman é “em grande parte” um substituto direto do Docker; diferenças sutis de CLI e comportamento podem quebrar scripts ou configurações de compose, especialmente em rede.
  • Usar ferramentas do Docker com Podman geralmente envolve executar um socket compatível com Docker e apontar DOCKER_HOST para ele; alguns veem isso como trivial, outros como atrito desnecessário.
  • O ecossistema do Docker (arquivos compose, documentação, comunidade) ainda é visto como mais maduro e acessível, então muitas organizações continuam com Docker para desenvolvedores mesmo usando Podman/Buildah em CI.
  • Usuários do NixOS destacam ferramentas como compose2nix para converter arquivos compose em configurações nativas de systemd/OCI.

Experiências específicas de plataforma

  • No Linux, vários afirmam que “não há razão para usar Docker mais” se o Podman estiver disponível.
  • As experiências no macOS (especialmente Apple Silicon) são mistas: alguns relatam anos de uso sem problemas; outros enfrentam travamentos ou congelamentos graves e voltam para o Docker. O Podman Desktop às vezes funciona onde instalações via CLI não funcionam.
  • No Windows, o Podman é elogiado por ser mais leve e menos intrusivo que o Docker Desktop, embora careça de algumas integrações com IDEs.

Motivações, política e preocupações com o ecossistema

  • O investimento da Red Hat no Podman é atribuído a tentativas fracassadas de colaborar com o Docker e à insatisfação com a segurança, o SELinux, o systemd e o comportamento de rede do Docker.
  • Alguns argumentam que a existência do Podman, assim como Linux vs sistemas operacionais proprietários, é valiosa como um freio ao poder do Docker.
  • Há debate sobre qual empresa é mais confiável; as opiniões divergem sobre Red Hat/IBM vs Docker, mas o fato de o Podman ser totalmente aberto é visto como uma rede de segurança caso a direção corporativa mude.

Pontos de dor e alternativas

  • Os mapeamentos UID/GID do Podman, ACLs e rótulos podem confundir novos usuários; adotantes iniciais relatam “não funcionou simplesmente” e que podman system migrate podia destruir configurações. Outros, começando mais tarde, acham mais fácil que Docker.
  • Algumas cargas de trabalho não podem ser executadas facilmente rootless (por exemplo, montagens NFS), limitando o valor do Podman/Docker rootless nesses ambientes.
  • Alguns preferem evitar tanto Docker quanto Podman em certos casos de uso, usando bubblewrap ou Buildah diretamente e criticando Dockerfiles como uma DSL desnecessária.