from Hacker News

Exploring Podman: A More Secure Docker Alternative

by sacrosanct on 1/13/24, 5:00 PM with 126 comments

  • by tekeous on 1/13/24, 6:16 PM

    Podman was good when it supported systemd unit files, so I could auto start and auto update containers, even entire pods with systemd.

    Then they removed that in favor of Quadlet. Now in order to do a single container I can do a unit file, but for a pod, I need to use a Kubernetes cluster definition.

    Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable to access mapped directories.

    So what is it, Podman? Should I just use Kubernetes? Should I just make dedicated directories for everything instead of mapping logical places for things?

  • by freedomben on 1/13/24, 8:03 PM

    I almost never see what is IMHO the killer feature of Podman touted as a reason to prefer it over Docker: Docker mangles your network config. It is a nightmare trying to run Docker and KVM virtual machines with bridges at the same time. Podman on the other hand plays very nice OOTB.

    I've also had a lot of VPNs break and/or be broken by Docker. I don't know much about the way podman does networking, but whatever it is they did a good job thinking it through and it has yet to interfere with anything else I do. I definitely can't say the same for Docker

  • by bootsmann on 1/13/24, 5:51 PM

    Glad that podman is getting more traction tbh, too many tools are built with the assumption that people add the sudo docker group which break if you have any kind of security conscious docker setup (such as not blindly giving it root access).

  • by INTPenis on 1/13/24, 7:05 PM

    As a certified RHEL engineer I have been using Podman for years already.

    To be perfectly honest I do enjoy it for all my personal container use. But at work I still use docker for our developers. There is so far nothing I can offer our developers that can match docker compose in simplicity.

    We even use buildah in CI pipelines when we make container images, but specifically for developer end users docker compose is still dominant.

  • by coldblues on 1/13/24, 5:51 PM

  • by BossingAround on 1/13/24, 7:09 PM

    I still don't really understand why Red Hat invests into creating a Docker alternative, but I really like it. Podman does pretty much everything Docker does, but it has more features (e.g. pods) or the way Podman does it tends to be better (e.g. daemonless container spawning process).

    The main issue to a common developer would be Docker compose I suppose, which if you use simple compose files, there's actually a podman-compose script that attempts to be compatible with the Docker compose spec.

    There's also using Podman as a backend for docker-compose [1]. Overall, in 2024, I see no reason using Docker at least on Linux boxes. Not sure how Podman fares on macOS or Windows.

    [1] https://www.redhat.com/sysadmin/podman-docker-compose

  • by politelemon on 1/13/24, 6:36 PM

    Sounds good, I like their security first approach and some of the decisions they've made, going for secure defaults out of the box, and that it works with docker compose. I wonder if podman gains enough traction, at some point, they decide to go their own way with regards to the commands and the yml, because right now it seems to be a tool that 'hangs on to' docker and docker's compose file format.

    It would be good to have a swarm alternative in podman, it seems like k8s is a crutch for lack of orchestration. With their good security hat on they could probably come up with a sane, simple way of running containers at small scales without having to dive into a PhD in k8s which doesn't have secure defaults out of the box, while maintaining compatibility with docker compose format.

    Anyway that's a good intro thanks for sharing, I'll be trying it later.

  • by Helmut10001 on 1/14/24, 5:47 AM

    I agree that rootless containers and isolated namespaces are critical security features. But with docker rootless, this is also possible and not complicated. You just have to do it. I have written a blog post to set up Mastodon in docker rootless with all the best practices currently available [1].

    The benefit with sticking with docker is that accessibility is better: More communities, more blogs, broad availability of docker compose configs, more peers knowing how to use it etc. In the end, both podman and docker run processes in isolated namespaces on the host.

    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • by irusensei on 1/13/24, 7:54 PM

    Don't take me wrong. Podman is great and I use it instead of docker nowadays but when I started using it thinking it was just a docker replacement I got burned by UID and GID mappings, SELINUX policies, missing DNS configuration and more.

    More than once I wrecked my whole setup running system migrate as a way to fix problems. It has a whole thing about security ACLs, ID mapping and labels. A chmod -R under your home folder will probably kill all your containers.

    While I'm happy with the results it was far from an "it just works" solution like Docker. I imagine things probably have been improved since I started using it.

  • by jrm4 on 1/13/24, 7:44 PM

    Big picture, it feels like Podman is essential the same way Linux used to be.* It doesn't matter if very few people use it -- it's presence prevents its much bigger privately-owned brother(s) from doing terrible things.

    *(I say "used to be" because Linux is now even more essential and central, not less.)

  • by tdiff on 1/13/24, 9:55 PM

    One other thing podman (unlike Docker) is missing is ability to run x86 images of Apple silicon under Rosetta. QEMU turns out to be too slow for real use.

  • by Plasmoid on 1/13/24, 6:43 PM

    One of the nice things about podman is that it's super easy to configure image caches. So instead of rewriting all my image references to use my local cache tool, I can just set a cache directive in podman and everything works transparently.

  • by xyst on 1/13/24, 8:17 PM

    I had some issues with podman working on my m1 mac about 1-2 yrs ago.

    I’ll give it a shot again. Looks like it has matured very fast.

  • by qwertox on 1/13/24, 6:42 PM

    I have such a huge arsenal of custom tools to manage Docker, that I envy Podman users because I can't move to it because of this technical debt.

    I just keep hoping that Docker isn't that bad and is a good alternative to Podman, because I've read mostly good things about the it, while Docker usually gets dragged through the dirt.

  • by coppsilgold on 1/13/24, 10:43 PM

    I tend to just make and run shell scripts that configure and run bubblewrap[1].

    Everything is nicely explicit and allows for a good mental model of what's going to happen when you run it.

        source "/path/bwrap_helper.sh"
    FLAGS=(
      ${FLAGS_ROOTFS_DISTROX_MIN[@]}
      ${FLAGS_ENV_XDG_GUI[@]}
      ${FLAGS_PULSE[@]}
      ${FLAGS_GPU_ACCEL[@]}
      --new-session
      --bind /path/jail123 /home/user
    )
    exec bwrap "${FLAGS[@]}" --seccomp 10 10< /path/a_filter.bpf -- /usr/bin/gui_app "$@"
    [1] <https://github.com/containers/bubblewrap>

  • by AkihiroSuda on 1/14/24, 12:32 PM

    > Podman is designed to help with this by providing stronger default security settings compared to Docker. Features like rootless containers, user namespaces, and seccomp profiles, while available in Docker, aren't enabled by default and often require extra setup.

    Seccomp has been enabled by default since 2015: https://github.com/moby/moby/pull/18780

    It is true that Rootless isn't enabled by default but its "extra setup" can be done with a single command (`dockerd-rootless-setuptool.sh install`)

  • by oasisaimlessly on 1/13/24, 10:28 PM

    Can anyone tell me why neither Docker nor Podman allow you to dynamically modify forwarded ports? It would allow zero-downtime updates of containers (starting new container, wait for it to be healthy, update port forwards, stop old container).

    And no, reverse proxies do not solve this problem; lots of protocols (e.g. SSH) have no equivalent to X-Forwarded-For for identifying the remote host.

  • by tdiff on 1/13/24, 9:53 PM

    Could anyone please advise a paper on Docker architecture, discussing its design choices (e.g. client-server model) in detail?

  • by hirako2000 on 1/13/24, 8:51 PM

    Also worth mentioning that while docker has been catching up by offering a rootless mode for years now, it insists on running a daemon process.

    That daemon is a subtle but incomensurate burden when adopting the least privilege principle.

    In environments running multiple hosts which themselves run multiple containers, typically: k8s, it forces your hand in either giving in and grant docker (the daemon) root privilege if any one of your container needs root, or to exclude that container from running in that environment altogether (since it would fail to execute if the docker daemon is in rootless mode). Of course the most secure and wise option would be to refractor that container and whatever it's doing to run rootlesssly, but sometimes this is simply not a reasonable or even possible option in order migrate massive complex platform of hundreds of micro services with its own history and justified security exceptions.

    K8s (and Openshift, which adopts a stronger security by default configuration set) provides control over which service accounts is granted such exception.

    tl-dr: use podman/buildah rather than docker, use openshift rather than vanilla k8s.

  • by snapplebobapple on 1/16/24, 8:31 PM

    Can't do nfs mounts rootless, so I don't really see the point since my whole infrastructure is using nfs mounts and docker already.

  • by WhyNotHugo on 1/14/24, 9:46 AM

    The comparison is unfair in that it compares docker-as-root vs rootless podman.

    A more sensible comparison would be between docker rootless and podman rootless.

  • by CodeCompost on 1/13/24, 6:17 PM

    deleted

  • by throwawaaarrgh on 1/13/24, 9:05 PM

    Somebody should tell them Docker can run in rootless mode.