Python bindings and code examples for using Varlink access to Podman Service
Der erste Teil der Artikelserie hat einen grundlegenden Überblick über Podman vermittelt, während der zweite Teil die Bausteine eines Linux-Containers und Sicherheitskonzepte von Podman genau beleuchtete, insbesondere die Ausführung ohne Root. Der dritte und letzte Teil der Artikelserie widmet sich den fortgeschrittenen Anwendungsfällen von Podman, angefangen bei der automatischen Generierung von Systemd-Services bis zur Container-Ausführung auf einem anderen System.
Für dieses Tutorial habe ich eine Installation mit Debian 11.1 (Bullseye) verwendet. Auf dem Host existieren die beiden User Alice und Bob, welche für die Nutzung von rootless-Podman vorbereitet werden.
Die Einrichtung von rootless-Podman unter Debian Bullseye
Rootless-Container haben die Eigenschaft, dass sie in User Namespaces (siehe user_namespaces(7) und namespaces(7)) ausgeführt werden. UIDs und GIDs, welche innerhalb des Containers existieren, werden dabei auf UIDs/GIDs des Hosts abgebildet. So besitzt ein Prozess, welcher innerhalb eines Containers mit der UID 0 (root) läuft, außerhalb des Containers bspw. die UID 165537 und damit die Rechte eines normalen Benutzers.
Das Container-Tool Podman, als Alternative zu Docker angepriesen, ist kürzlich in Version 1.0 erschienen. Gründe genug für einen tiefen Einblick: Von der Installation bis zum Einsatz.
Podman kann als root oder eben nicht ausgeführt werden: Das kommt nicht nur Benutzerfreundlichkeit und breiten Anwendungsmöglichkeiten, sondern auch der Sicherheit zugute.
Nachdem der erste Teil der Artikelserie [1] einen grundlegenden Überblick über Podman vermittelt hat, geht der zweite Teil auf verschiedene Sicherheitskonzepte von Podman und die Bausteine eines Containers ein. Praktische Beispiele sollen zeigen, wie sie in der Praxis Anwendung finden.
Rootless containers refers to the ability for an unprivileged user to create, run and otherwise manage containers. This term also includes the variety of tooling around containers that can also be run as an unprivileged user. The goal of this website is to catalogue all of the open questions and unresolved issues that need to be solved to bring us closer to rootless containers “for all”.
“Unprivileged user” in this context refers to a user who does not have any administrative rights, and is “not in the good graces of the administrator” (in other words, they do not have the ability to ask for more privileges to be granted to them, or for software packages to be installed).
Varlink is an interface description format and protocol that aims to make services accessible to both humans and machines in the simplest feasible way.
A varlink interface combines the classic UNIX command line options, STDIN/OUT/ERROR text formats, man pages, service metadata and provides the equivalent over a single file descriptor, a.k.a. “FD3”.
Varlink is plain-text, type-safe, discoverable, self-documenting, remotable, testable, easy to debug. Varlink is accessible from any programming environment. See the Ideals page for more. And everybody likes Screenshots.
Project Atomic is an umbrella for many projects related to re-designing the operating system around principles of "immutable infrastructure", using the LDK (Linux, Docker, Kubernetes) stack.
Many of the components of Project Atomic are upstream components of OpenShift Origin v3.
The primary building block of Project Atomic is the "Atomic Host", a lightweight container OS which implements these ideas. Atomic Hosts are immutable, since each is imaged from an upstream repository, supporting mass deployment. Applications run in containers. Atomic Host versions based on CentOS and Fedora are available, and there is also a downstream enterprise version in Red Hat Enterprise Linux.
Manage pods, containers, and container images.