Was ist Cirrus CLI? Die folgende Beschreibung stammt aus der Cirrus CLI GitHub-Seitenbeschreibung:
Cirrus CLI ist ein Tool zum reproduzierbaren Ausführen containerisierter Aufgaben in jeder Umgebung. Am häufigsten werden Cirrus-Tasks als Teil von Continuous-Integration-Workflows verwendet, können aber auch als Teil des lokalen Entwicklungsprozesses als hermetischer Ersatz für Hilfsskripte/Makefiles verwendet werden. Cirrus CLI führt Ihre Aufgaben lokal genauso aus, wie sie in CI oder auf dem Computer Ihres Kollegen ausgeführt werden. Die Unveränderlichkeit von Containern stellt sicher, dass die Aufgaben in Jahren auf die gleiche Weise ausgeführt werden, unabhängig davon, welche Versionen von Paketen Sie lokal haben werden.
Cirrus CLI hat Docker von Anfang an unterstützt, aber manchmal ist es keine Option, einen Container-Daemon zu benötigen, der als Root ausgeführt wird und weniger privilegierten Benutzern Zugriff gewährt:Zum Beispiel, wenn auf einer gemeinsam genutzten Maschine gebaut, verschachtelte Container isoliert oder einfach nur Sicherheit geboten wird -bewusst, was auf Ihrem Desktop läuft.
Und obwohl Docker vor etwa einem Jahr den Rootless-Modus eingeführt hat, fehlt seiner Meinung nach derzeit die Benutzererfahrung, hauptsächlich aufgrund fehlender Verpackung und einer Geschichte, in der Docker ein Daemon war. Podman hingegen begann als Container-Engine ohne Daemon, und sein Installationsprozess deckt praktisch alle Distributionen ab.
Darüber hinaus haben wir bei der Untersuchung von Podman als zusätzliche Option zum Ausführen von Cirrus-Aufgaben festgestellt, dass dies ein kleiner Schritt ist, um die Software-Monokultur zu durchbrechen, da letztendlich die Softwarequalität steigt. Neue Standards und Bausteine wie das Rootless Containers-Projekt entstehen, die den Weg für die Zukunft der Software ebnen.
Rootless-Container werden betrieben von... Namespaces?
Die Linux-Namespaces sind der wichtigste Eckpfeiler dafür, dass Container unter Linux funktionieren. Sie sind hochgradig Linux-spezifisch, bis zu dem Punkt, dass eine separate Linux-VM hochgefahren wird, wenn Sie Container unter Windows und macOS ausführen.
Namespaces ermöglichen eine granulare Ressourcentrennung. Wenn beispielsweise ein Prozess einem bestimmten PID-Namensraum zugeordnet ist, sieht er nur andere Prozesse, die demselben Namensraum zugeordnet sind. Oder wenn ein FUSE-Dateisystem als Root eingehängt ist (/ ), während er sich in einem separaten Mount-Namespace befindet, stürzt der Host nicht plötzlich aufgrund fehlender Binärdateien ab.
Einer der kniffligsten Namensräume sind die Benutzernamensräume. Benutzer-Namensräume ermöglichen es einem im Wesentlichen, innerhalb dieses Namensraums ein Root zu sein, aber von außen als normaler Benutzer zu erscheinen. Da die meisten Container-Images davon ausgehen, dass sie für bestimmte Vorgänge als Root ausgeführt werden, ist die Implementierung von Benutzernamensräumen für Container ohne Root entscheidend.
Mal sehen, was passiert, wenn mehrere Benutzer ihre Build-Befehle mit Docker ohne starten Benutzernamensräume aktiviert:
Beim Beobachten der IDs dieser Prozesse vom Container-Host laufen alle Jobs unter root, obwohl sie von verschiedenen Benutzern gestartet wurden. Dasselbe gilt für containerd . Und dabei hättest du eigentlich die --userns-remap passieren können Flag, würde der Container immer noch als Root laufen und wäre ein Single Point of Failure.
Im Standardmodus läuft das so, weil die Implementierung von rootlosen Containern nicht trivial ist.
Die Benutzernamensräume selbst sind wahrscheinlich eine der komplexesten zu implementierenden Konfigurationen und produzieren viele sicherheitsrelevante Fehler. Einige Distributionen wie Debian haben sich vor einiger Zeit sogar dafür entschieden, sie standardmäßig zu deaktivieren.
[ Falls Sie es verpasst haben:Grundlegende Sicherheitsprinzipien für Container und Containerlaufzeiten ]
Wie Podman wurzellose Ausführungsschwierigkeiten löst
Das Starten eines Containers ohne Root-Rechte beinhaltet einige Kompromisse und Problemumgehungen.
Wenn Sie beispielsweise als Benutzer einen Netzwerk-Namespace erstellen (der mit einem Benutzer-Namespace einhergehen sollte), erhalten Sie nur einen lo Schnittstelle. Normalerweise erstellt eine Container-Engine auch einen veth Gerätepaar und verschiebt eines seiner Enden zurück zum Host, um es mit einer echten Netzwerkschnittstelle oder Bridge (für die Kommunikation zwischen Containern) zu verbinden.
Das Verbinden von Schnittstellen auf dem Host erfordert jedoch, dass Sie ein Root im Namespace des Hosts sind, daher ist dies nicht möglich. Podman umgeht dies, indem es slirp4netns verwendet, einen Netzwerkstapel, der die Pakete zwischen dem Container und dem Monitor selbst weiterleitet, anstatt die Kernel-Einrichtungen zu verwenden. Daher sind keine Superuser-Rechte erforderlich.
Aufgrund der mit Benutzernamensräumen verbundenen Komplexität können Sie auch bestimmte Dateisysteme nicht verwenden, die normalerweise dem Root des Hosts zur Verfügung stehen. Eines dieser Dateisysteme ist OverlayFS, das beim Deduplizieren von Container-Image-Layern sehr hilfreich ist und das Container-Erlebnis verbessert. Man kann aber trotzdem FUSE verwenden. Das Podman-Team hat fuse-overlayfs implementiert , das verwendet wird, wenn es installiert ist, und auf Kosten der Leistung einfach auf das Extrahieren des Bildinhalts in ein Verzeichnis zurückgreift.
Wenn wir jetzt die gleichen Jobs wie zuvor ausführen, aber mit Podman, sieht das Ergebnis so aus:
Beachten Sie, dass jetzt nichts als root ausgeführt wird und es keinen Single Point of Failure gibt, wenn eine Container-Engine aus irgendeinem Grund abstürzt.
Integration mit Podman
Wenn Sie einen neuen Build mit cirrus run starten , erzeugt es den Podman-Prozess unter der Haube und kommuniziert mit ihm über die REST-API, die kürzlich als Nachfolger der alten Varlink-API eingeführt wurde.
Die API selbst ähnelt stark der Docker Engine API, die eine saubere Abstraktion für beide APIs in derselben Codebasis ermöglicht.
Tatsächlich bietet derselbe Podman-Endpunkt eine Docker-Engine-API-Kompatibilitätsebene, aber zum Zeitpunkt der Erstellung dieses Artikels befindet er sich noch in Arbeit.
Podman in der CLI aktivieren
Wenn Sie Podman noch nicht installiert haben, befolgen Sie die Anweisungen für Ihre Linux-Distribution und lesen Sie dann das Rootless-Tutorial.
CLI unterstützt Podman-Version 0.17.0 und höher. Sie können es aktivieren, indem Sie --container-backend=podman übergeben Flagge:
cirrus run --container-backend=podman Lint Beachten Sie, dass Sie, wenn Sie Docker nicht auf Ihrem System installiert haben, nicht einmal etwas angeben müssen – alles funktioniert automatisch.
[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Abschluss
Rootlose Builds sind eine wichtige Komponente von Containerbereitstellungen. Cirrus CLI arbeitet mit Podman zusammen, um diese Funktionalität bereitzustellen. Verwenden Sie diese beiden Dienstprogramme, um Ihre Containerumgebungen besser zu verwalten und zu sichern.