Sag einfach nein zu root (in Containern)

Ich werde ständig nach den verschiedenen Sicherheitsmaßnahmen gefragt, die verwendet werden, um zu kontrollieren, was Containerprozesse auf einem System tun können. Die meisten davon habe ich in früheren Artikeln auf Opensource.com behandelt:

• Sind Docker-Container wirklich sicher?
• Einführung neuer Sicherheitsfunktionen in Docker
• Docker-Sicherheit in der Zukunft

In fast allen oben genannten Artikeln geht es darum, zu steuern, was ein privilegierter Prozess auf einem System in einem Container tun kann. Zum Beispiel:Wie führe ich root in einem Container aus und lasse nicht zu, dass er ausbricht?

Linux-Container

• Was sind Linux-Container?
• Eine Einführung in die Containerterminologie
• Download:Einführung in Container
• Kubernetes-Operatoren:Automatisierung der Container-Orchestrierungsplattform
• eBook:Kubernetes-Muster zum Entwerfen cloudnativer Apps
• Was ist Kubernetes?

Beim Benutzernamensraum geht es darum, privilegierte Prozesse in Containern auszuführen, sodass sie, wenn sie ausbrechen, außerhalb des Containers nicht mehr privilegiert sind. Zum Beispiel ist meine UID im Container 0 (Null), aber außerhalb des Containers ist meine UID 5000. Aufgrund von Problemen mit der fehlenden Dateisystemunterstützung war der Benutzernamensraum nicht das Allheilmittel, das er angeblich sein sollte. Bis jetzt.

OpenShift ist die Container-Plattform von Red Hat, die auf Kubernetes, Red Hat Enterprise Linux und OCI-Containern aufbaut und über ein großartiges Sicherheitsfeature verfügt:Standardmäßig dürfen keine Container als Root ausgeführt werden. Ein Administrator kann dies überschreiben, da sonst alle Benutzercontainer ausgeführt werden, ohne jemals root zu sein. Dies ist besonders wichtig in mandantenfähigen OpenShift Kubernetes-Clustern, in denen ein einzelner Cluster möglicherweise mehrere Anwendungen und mehrere Entwicklungsteams bedient. Es ist nicht immer praktisch oder sogar ratsam, dass Administratoren separate Cluster für jeden ausführen. Leider ist eine der größten Beschwerden über OpenShift, dass Benutzer nicht alle auf docker.io verfügbaren Community-Container-Images problemlos ausführen können. Dies liegt daran, dass die überwiegende Mehrheit der Container-Images auf der Welt heute Root erfordern.

Warum benötigen all diese Bilder root?

Wenn Sie tatsächlich die Gründe untersuchen, um auf einem System root zu sein, sind sie ziemlich begrenzt.

Ändern Sie das Hostsystem:

• Ein Hauptgrund dafür, Root auf dem System zu sein, ist das Ändern der Standardeinstellungen auf dem System, wie das Ändern der Kernel-Konfiguration.
• In Fedora, CentOS und Red Hat Enterprise Linux haben wir das Konzept von Systemcontainern , bei denen es sich um privilegierte Container handelt, die mithilfe von atomic auf einem System installiert werden können Befehl. Sie können voll privilegiert laufen und dürfen sowohl das System als auch den Kernel modifizieren. Bei Systemcontainern Wir verwenden das Container-Image als Content-Delivery-System und suchen nicht wirklich nach Container-Trennung. System-Container sind eher für die zentralen Host-Dienste des Betriebssystems gedacht als für die App-Dienste der Benutzer, die von den meisten Containern ausgeführt werden.
• In Anwendungscontainern wollen wir fast nie, dass die Prozesse innerhalb des Containers den Kernel modifizieren. Dies ist definitiv nicht standardmäßig erforderlich.

Unix/Linux-Tradition:

• Hersteller und Entwickler von Betriebssystemsoftware wissen seit langem, dass das Ausführen von Prozessen als Root gefährlich ist. Daher fügte der Kernel viele Linux-Funktionen hinzu, damit ein Prozess als Root starten und dann so schnell wie möglich Berechtigungen verlieren kann. Die meisten UID/GID-Funktionen ermöglichen es einem Prozess wie einem Webdienst, als Root zu starten und dann Nicht-Root zu werden. Dies geschieht, um an Ports unter 1024 zu binden (mehr dazu später).
• Container-Laufzeiten können Anwendungen zunächst als Nicht-Root starten. Um ehrlich zu sein, kann systemd das auch, aber die meiste Software, die in den letzten 20 Jahren entwickelt wurde, geht davon aus, dass sie als Root startet und Berechtigungen fallen lässt.

An Ports <1024 binden

• Vor langer Zeit in den 1960er und 1970er Jahren, als es nur wenige Computer gab, galt die Unfähigkeit nicht privilegierter Benutzer, sich an Netzwerkports <1024 zu binden, als Sicherheitsmerkmal. Da dies nur ein Administrator tun könnte, könnten Sie den Anwendungen vertrauen, die diese Ports überwachen. Ports> 1024 könnten von jedem Benutzer im System gebunden werden, sodass ihnen nicht vertraut werden könnte. Die Sicherheitsvorteile sind weitgehend weg, aber wir leben immer noch mit dieser Einschränkung.
• Das größte Problem mit dieser Einschränkung sind die Webdienste, bei denen die Leute es lieben, wenn ihre Webserver auf Port 80 lauschen. Dies bedeutet, dass der Hauptgrund, warum Apache oder Nginx mit der Ausführung als Root beginnen, darin besteht, dass sie sich an Port 80 und dann binden können Nicht-Root werden.
• Containerlaufzeiten, die Portweiterleitung verwenden, können dieses Problem lösen. Sie können einen Container so einrichten, dass er jeden Netzwerkport abhört, und dann die Containerlaufzeit diesen Port Port 80 auf dem Host zuordnen.

In diesem Befehl würde die Podman-Laufzeit einen apache_unpriv ausführen Container auf Ihrem Rechner, der Port 80 auf dem Host abhört, während der Apache-Prozess im Container nie root war, sondern als apache gestartet wurde Benutzer und wurde angewiesen, auf Port 8080 zu lauschen.

podman run -d -p 80:8080 -u apache apache_unpriv

Alternativ:

docker run -d -p 80:8080 -u apache apache_unpriv

Installieren von Software in einem Container-Image

• Als Docker das Bauen von Containern mit docker build einführte , war der Inhalt in den Containern nur standardmäßige Softwarepakete für Distributionen. Die Software kam normalerweise über RPM-Pakete oder Debian-Pakete. Nun, Distributionspaketsoftware muss von root installiert werden. Ein Paket erwartet Dinge wie die Manipulation von /etc/passwd Datei durch Hinzufügen von Benutzern zu erstellen und Inhalte mit unterschiedlichen UID/GIDs im Dateisystem abzulegen. Ein Großteil der Software erwartet auch, über das Init-System (systemd) gestartet zu werden und als root zu starten und dann nach dem Start die Privilegien fallen zu lassen.
• Leider ist dies nach fünf Jahren der Containerrevolution immer noch der Status quo. Vor ein paar Jahren habe ich versucht, dem httpd-Paket mitzuteilen, wann es von einem Nicht-Root-Benutzer installiert wird und eine andere Konfiguration hat. Aber ich habe den Ball darauf fallen lassen. Wir müssen Paketierer und Paketverwaltungssysteme dazu bringen, den Unterschied zu verstehen, und dann könnten wir nette Container erstellen, die ohne Root ausgeführt werden können.
• Eine Sache, die wir jetzt tun könnten, um dieses Problem zu beheben, ist, die Build-Systeme von den Installationssystemen zu trennen. Eines meiner Probleme mit #nobigfatdaemons ist, dass der Docker-Daemon dazu führte, dass die Container mit denselben Rechten zum Ausführen eines Containers ausgeführt wurden wie zum Erstellen eines Container-Images.
• Wenn wir das System ändern oder andere Tools verwenden, z. B. Buildah, um einen Container mit lockereren Einschränkungen zu erstellen, und CRI-O/Kubernetes/OpenShift, um die Container in der Produktion auszuführen, können wir mit erhöhten Rechten erstellen, aber dann ausführen Container mit viel strengeren Einschränkungen oder hoffentlich als Nicht-Root Benutzer.

Unterm Strich

Fast alle Software, die Sie in Ihren Containern ausführen, tut dies nicht Root benötigen. Ihre Webanwendungen, Datenbanken, Load Balancer, Number Cruncher usw. nicht müssen immer als root ausgeführt werden. Wenn wir Leute dazu bringen würden, Container-Images zu erstellen, die überhaupt kein Root benötigen, und andere, ihre Images auf nicht privilegierten Container-Images aufzubauen, würden wir einen riesigen Sprung in der Containersicherheit sehen.

Es muss noch viel Aufklärungsarbeit geleistet werden, um root innerhalb von Containern auszuführen. Ohne Bildung können kluge Administratoren schlechte Entscheidungen treffen.