Why Use Podman Quadlet over Docker…
This blog shares some of the insights I gained while exploring Podman Quadlet and how easily it allows us to run containers as systemd services.
You might wonder: Why not Docker?
Docker is easy to use, widely adopted, and comes with tools like Docker Compose, which make managing multiple containers through a single configuration file straightforward.
So, why consider an alternative?
The Real Issue with Docker
One of the concerns I have with Docker is the privileges required to run its daemon.
Docker relies on a background process called dockerd, which traditionally runs with root privileges. This introduces an additional security concern: the potential blast radius if an attacker manages to compromise a container or gain access to the Docker daemon.
Podman takes a different approach by allowing containers to run under an unprivileged user account without requiring a root-owned daemon.
If an attacker exploits a vulnerable container and gains access to the Docker socket or daemon, they could potentially escalate their privileges and compromise the underlying host.
This makes the Docker daemon an important part of the server’s attack surface.
Another Concern: Docker and Firewall Management
Another aspect worth discussing is how Docker handles firewall rules.
Get Nachiket Pensalwar’s stories in your inbox
Join Medium for free to get updates from this writer.
Docker automatically creates and manages its own firewall rules, including rules in iptables or nftables, depending on the networking backend and configuration.
This can create conflicts with dynamic firewall management tools such as firewalld and ufw.
Ideally, we want a centralized firewall management approach where all network access is controlled through the firewall policies we explicitly define.
However, Docker’s networking behavior can bypass the expectations set by these firewall configurations.
You might have come across port mappings like these in a Docker Compose configuration:
ports:
- "127.0.0.1:3000:3000" # Accessible only through host localhost
- "0.0.0.0:3030:3030" # Accessible on all host network interfacesNotice the second mapping.
By binding port 3030 to 0.0.0.0, Docker publishes the port on all host network interfaces. This can make the service accessible externally, even if you haven't explicitly opened that port through your usual ufw or firewalld configuration.
In other words, a port that you expected to remain blocked by your firewall might still be reachable because of Docker’s firewall rules.
Native systemd Integration
Containers can be managed just like any other systemd service. We get access to familiar features such as service dependencies, automatic restarts, logging through journalctl, timers, and resource limits without introducing additional management tools.
These are some of the reasons I started exploring Podman and, more specifically, Podman Quadlet.
Podman offers a daemonless architecture and integrates nicely with systemd through Quadlet, making it an interesting alternative for running and managing containers on Linux servers.
