Podman: Container without a Daemon, and Root-rights

Alex Alex 20 November 2019
Podman: Container without a Daemon, and Root-rights

Podman has grown since its first Release in February of 2018 [1] rapidly and is now traded in many places as a replacement for Docker. Replacing one with the other, sounds logical. However, a synergy is often better – achieve more together! There are quite good reasons, Podman use. However, Podman not be able to find all the possibilities of Docker directly. What works, what is possible and how can the Most from Podman get out? In this article we will answer these questions.

The differences of Podman and Docker arising from the different approaches, which track both the Container Manger. Docker was designed in 2013 as a tool to provide easy access to Linux Namespaces, and the insulation of possibilities already. Podman, 2018 created, could build on the Docker gained experience in certain areas. The Tool uses the same command line parameters and switches, such as Docker, therefore, a change from Docker to Podman for the local operation of containers, the ease with which. The operation of multiple Pods across multiple Hosts is the exception. This is a Podman is not possible, since the functionality of Docker Swarm (Overlay networks) is missing.

Here you must therefore be alternatively used to Kubernetes back. Kubernetes provides many concepts and approaches, which establish themselves more and more on the market, if one may believe the media Reports. Among these concepts, the Pods, or daemonless and rootless Container.</example p>

Pods

Podman [2] is a Container Manager that can be run without a Daemon, and on the concept of a Kubernetes pod builds (Fig. 1). Kubernetes Pods [3] represent a combination of multiple containers within a common Linux Namespaces [4]. The possibility to create "Pods", is certainly one of the advantages of Podman. Thereby, it is possible to start very flexible combinations and configurations of containers together. For example, a Container within a pod may be responsible for pullen in regular, modern steuertn intervals, the contents of a static website from a Git Repository, while another Container of the same pod, provides the content via a web server.

figure 1: The Pod-concept

such A merger of containers is not with Docker without any further configuration is not viable as the concept of Pods in Docker is as such known. The additional tool docker-compose this functions, however, available. The idea behind it is based on the Sharing of a common network-Namespaces. On the Blog of Michael Irwin [5] described an approach comes in the use of Kubernetes automatically to the application. Unfortunately, it is currently not possible to use Kubernetes Deployments, which included the Pod configuration, by means of Podman directly [6]. This is a pity, since it thus with Podman easier to start local Pods [7], a real advantage in comparison with docker-compose is not given immediately. Especially the different naming of the same functionality between Kubernetes and Podman is not likely to make it easier for many users, the access to this topic at the moment. As an example, the "infra"containers cited that fulfils exactly the same purpose, Yes was even the same Container Image is used, as in Kubernetes, namely, k8s.gcr.io/pause [7]. Why this Container is not known, in contrast to the Kubernetes however, as a "pause"Container, but "infra"containers, is not quite clear, even if "infrastructure" is the technically correct name — correct does not always mean accessible for the user.

Daemonless

Docker is already since long been in focus of many security researchers, since the Docker Daemon, so the service, the start for the management of the Container (start, stop, etc.) is responsible, as the Root user is running. This is due to the possibilities of what Docker without further tools, such as Overlay networks in the Docker-Swarm-operation. Podman that operates without a Central Daemon and thus represents a tool that can be run in User-Space and thus in the context of the respective user rights.

The daemonless mode, it does not mean, however, that there is no Daemon, which monitors the Container of Pods. To this purpose, it is automatically started with the Start of each pod to another process shape and this process listens to the name conmon [9]. the conmon makes an important it is not only the responsibility to monitor the Container of the pod, rather, conmon the link between the Container Manager and the Container-Runtime (runc) and thus ensures the correct startup parameters for the Container Runtime. There must also be a conmon the three standard streams (stdin, stdout and stderr) to manage, and is also responsible for the launch of slirp4netns [10], which accomplishes the forwarding of the network data streams to and from the Pod located in the containers. This can, as shown in Figure 2, Running the netstatcommand after the Start of a pod with a corresponding Host-Port-forwarding just to be checked.

figure 2: podman and slirp4netns

In this article used Podman-Version (1.6.2) monitors conmon not the slirp4netnsprocess. The slirp4netns should crash because of an error or the process is terminated deliberately, so he no longer starts, unfortunately, and a network communication with the Pod Service is no longer possible (Fig. 3). A corresponding GitHub Issue for this behavior was opened, [11]; perhaps, in fact, in one of the next Podman versions of a Revision.

figure 3: kill slirp4netns

Since the slirp4netns-process is run with the same permissions as the Container itself, it is in rootless mode, it is not possible to use a Low-Port as a Host Port, since this would require appropriate administrative rights. Rootless containers are a further strength of Podman.

The automatic startup of Podman Pods must be made on the basis of the daemonless approach by means of the systemd unitfile. How figure 4 shows, these files can be generated directly with the Podman-command.

figure 4: podman generate systemd

Rootless

Rootless containers mean that it is possible to start a Container without Root privileges. Thanks to the mapping of user IDs in the Namespace of the current container, the Container has no Root rights. As in figure 5 is first started by Podman an Alpine Container, which, in turn, starts a sleepcommand. After the Container is started, can be checked in the Host operating system with which users of the sleepcommand in it is executed. In the illustrated example, this is m4r10k, my own Linux user without Root rights. The second command, which is executed within the current container, shows that within the container of the sleepcommand with Root privileges has been started. The Mapping of the user IDs, works excellent within the container, a process with Root running-Right, which has, however, within the Host operating system, only normal user privileges.

figure 5: podman run-command – Rootless

This functionality is new as compared with the approach of Docker significant progress. Docker supports running the Docker daemon in the rootless-variant experimental Version 19.03 [8]. The support of rootless containers here, however, only at the beginning of the implementation, since this change is within the Docker-based technology relates to many areas, including the network area with the Overlay networks in the Docker-Swarm-operation.

in The operation of rootless containers, it is important to note that there is no Low Ports may be used for the Host-Port Mapping. For the Start of a pod with a manual Port Expose this means that a Port must be higher than 1024 to be used. This fact is not observed, the Podman-command is breaking with a rather cryptic error message, as in the figure 6 as shown.

figure 6: podman rootless Low-Port-Mapping

conclusion

Podman with the daemonless and rootless options much Potential to be able to Container securely on the local machine or on a single Server to operate. Currently a few minor problems, which do not fall further into the weight, if the usual configuration options are used still exist. In particular, in the Kubernetes environment, for example. in the case of Red Hat's OpenShift, has set Podman already as a Standard. The division into several different smaller services, podman, conmon and slirp4netns is the Unix philosophy: "Make each program do one thing well". Whether or not this will, however, in the long term prevail, will prove only, as the example of the "one-big-daemon"-systemd in the last few years has shown.

Source: entwickler.de

Comments (0)

    No comments yet

You must be logged in to comment.