Compare Docker vs. Podman for container management
Docker and Podman offer similar capabilities to manage containers, but Docker's security vulnerabilities might make Podman more appealing for some admins.
Docker is the de facto container software standard for many IT administrators and holds the lion's share of developer interest. Yet a newer contender, Podman, offers admins security advantages over a basic Docker deployment because it runs as a nonprivileged user -- and without a daemon -- by default.
Docker and Podman offer many of the same features, such as support for and adherence to Open Container Initiative's (OCI's) runtime and image specifications, as well as command mapping to create and manage containers. But there are several differences between Docker and Podman relating to security concerns and reliance on daemon programs.
Podman does not use a daemon to develop, manage and run OCI containers -- it runs on top of a Linux OS. In general, containers can run as root or in rootless mode. By default, Docker uses a daemon -- a persistent background process that handles all container management duties on the host. Docker relies on a client-server architecture, wherein the daemon fulfills the role of a server, and clients communicate via the command-line interface (CLI).
Docker uses a native Windows daemon to launch Windows or Linux-based images. Podman requires version 2 of the Windows Subsystem for Linux, released in the May 2020 update, so IT admins will need an up-to-date system to experiment with this tool.
Security
One significant difference between Docker and Podman is how they handle system security. By default, the Docker daemon requires root privileges, which presents a clear security risk that grows exponentially with each additional access permission. A Docker container configured improperly could access the host file system without restriction. Admins can prevent this by following some basic Docker best practices, such as using container images from trusted vendors, and by instating more rigorous access management policies, such as role-based access control.
With Podman, admins launch containers as nonprivileged users by default. This provides Podman with an advantage over Docker in locking down environments to potential attacks. Admins can't execute any commands that require root privileges on the host system as a nonprivileged user, such as mapping any privileged port numbers below 1024 on the host or the default HTTP port 80.
Docker and Podman both take advantage of the Linux kernel seccomp feature to enable a secure computing mode. This feature implements a filtering mechanism whenever a process invokes a system call to prevent malicious code execution. It reduces the attack surface presented by system-level code execution.
In addition, both Docker and Podman use a CLI as the primary management interface. However, Docker uses a REST API endpoint for communication with the daemon. Older Docker versions use a TCP socket bound to the localhost IP address. This presents a potential attack surface for a cross-site forgery exploit. Docker addressed this vulnerability in version 0.5.2 by introducing a Unix socket, controlled with traditional Unix permissions to restrict access. Podman is not susceptible to this type of attack because it doesn't use a daemon.
Podman version 3.3.0 was released in August 2021 and included 60 bug fixes and improvements for stability. The newest version provides support to run Podman on macOS X and restart containers after a system restarts.
Docker can launch the daemon as a nonroot user, providing the same level of data protection as Podman. This capability was introduced in version 19.03 of the Docker engine and promoted from experimental to mainstream in version 20.10.
Container orchestration
If Docker is the de facto containerization software, Kubernetes is the de facto container orchestration software. VMware has adopted Kubernetes as its primary management plane for VMs -- and everything connected to run containers. Kubernetes uses the term pod to define a collection of containers that share certain resources. Podman supports this same concept by implementing a pod command to manage multiple containers as a single entity.
Docker provides multiple options for container orchestration. Docker Swarm is the native cluster management tool that Docker maintains, but Kubernetes uses Docker containers under the hood, which has made Kubernetes the more popular choice for many organizations. For Windows deployments, admins can enable Kubernetes during the installation process. This provides admins full access to the Kubernetes commands.
With Docker, admins can build their applications around the CI/CD model. This means development and testing can happen anywhere based on simple configuration files. A few additional steps to change the deployment target are all that's required for admins to push a release to production.
The 3.0 release of Podman added support for the Docker compose command. Previously, admins used the Podman play command to manually import Kubernetes definitions, which are written in YAML. Admins can now load the same YAML files used by the Docker compose command, thereby easing the transition between the two platforms.
Both Podman and Docker conform to OCI standards for images, but Podman is worth checking out for its security features. Podman also provides native commands to build and test pods with an eye toward deploying a production system with Kubernetes.
Docker supports Kubernetes YAML, which enables the same type of development process to build and deploy multiple containers in an isolated environment, such as a laptop. This YAML file provides the same level of orchestration necessary to push applications to a Kubernetes production environment.
Docker vs. Podman
From a features and security perspective, updates to both tools have brought them almost to the point of parity. Although architectural differences remain, they don't represent significant advantages for either approach. For many organizations, it will come down to comfort level and developer adoption.
The good news is that either approach can achieve the same level of security and productivity to maintain applications.
