Commercialization of open source projects and haggling over licensing issues are gnawing away at the acceptance of free software. This not uncommon switch to a commercial future often sounds the death knell for the community's willingness to participate in ongoing development. An unclear licensing policy on the part of Docker developers has led to many controversies in the past, and an audit clause now imposes an additional burden on IT departments. Little wonder then that Red Hat, SUSE, and other Linux distributions replaced Docker with Podman years ago.

To future-proof your own IT infrastructure, you need to be able to plan for the long term. And long discussions about licenses are likely to be counterproductive. Enter Podman [1], the open source project that has long been touted in the community as a replacement for Docker. A number of aspects – both strategic and technological – speak in favor of switching to Podman, including Podman Desktop, which simplifies container management.

Licensing Hassle at Docker

What kicked off the far-reaching changes to the licensing policy was the acquisition of Docker Inc. by Mirantis in November 2019. The provider now relies on a subscription model: For companies with more than 250 employees or an annual turnover of more than $10 million, depending on the subscription option chosen, the fee is $5, $9, or $24 per user per month – all with annual payment. Depending on how you use Docker in your organization, this can mean substantial additional IT costs.

The audit clause is another pain. According to the license agreements, users grant Docker the right to store data relevant to licensing for at least three years, which means that organizations need to take care to archive the data in a reliable way. The use of a special software asset management environment is required to provide protection against potential contract penalties. The personal version is still available for free use, however.

Understandably, the new owners of Docker want and need to earn money with their investment to drive future development, which in itself reveals a significant strategic difference. Although Podman is backed by a well-known industry player (Red Hat), their business model focuses on generating revenue with licenses and support from its Red Hat Enterprise Linux (RHEL) and OpenShift businesses.

Podman vs. Docker

Fundamentally, Podman and Docker offer the same kind of scalable execution, management, and provisioning of containers. At the same time, the environments have some fundamental differences. What is perhaps the most significant difference relates to the architecture. Whereas Docker is based on a client-server model, Podman has an architecture that does not rely on a daemon, which removes the need to run an uninterrupted daemon process in the background.

The benefits of direct management are a far faster launch of Podman containers. Some sources report performance gains of up to 50 percent. Podman enhances security in the environment, as well.

More Secure Out of the Box

When Docker launches a container, the Docker client sends a request to the Docker daemon, which in turn is responsible for starting the container. Therefore, containers are child processes of the Docker daemon. If a security-related incident originating from a container process occurs and is registered by the Linux audit system (auditd), the audit user ID comes up as invalid, instead of the user ID that started the misbehaving container that is evaluated as critical.

As a result, it is almost impossible to assign critical activities to a specific user, which has a significant effect on system security. The situation with Podman is different. Every container is instantiated directly by a user login session. The source information is kept in the container process data and auditd can map the user ID to specific container processes, preserving the audit trail.

The idea behind containerized environments is to isolate their execution from the host system as far as possible. The greatest risk is posed by attackers breaking out of a container and compromising the host system. To mitigate this kind of risk, the containers are executed with minimal permissions. Many administrators and developers appreciate that the container environment strictly counteracts these risks. In principle, Docker can also handle containers without root privileges.

By default, Podman uses containers without root privileges that run in isolated user namespaces. This method significantly reduces the risk of an outbreak. Docker is different: Container processes run as root by default. Because Podman containers are also tied to specific user sessions, the auditing systems can trace malicious activities back to specific users, which is much more difficult with Docker because of the global daemon.

However, the two platforms also share similarities: Podman and Docker draw on the capabilities of the Linux kernel and seccomp profiles to control process authorizations. Both environments can also configure robust security. That said, you are looking at significantly less overhead with Podman to achieve a comparable level of security.