So sperren Sie Container-UID/GID und Volume-Besitz vor Updates selbst gehosteter Apps

Updates selbst gehosteter Apps führen seltener zur Erstellung von Dateien im Besitz von Root, wenn die Bereitstellung einen numerischen Benutzervertrag festlegt und vor dem Ersetzen des Containers die Volume-Eigentümerschaft überprüft.

Die vorbeugende Maßnahme besteht darin, den internen Benutzernamen des Images nicht als stabile Speicheridentität zu behandeln. Erfassen Sie die effektive UID und GID, mit denen persistente Daten geschrieben werden, ordnen Sie sie Host-Verzeichnissen oder benannten Volumes zu, bewahren Sie alle PUID/PGID- oder User-Namespace-Einstellungen auf und testen Sie das neue Image vor dem vollständigen Rollout an einem kleinen beschreibbaren Pfad. So kann ein Image-Update den numerischen Besitzer von Konfigurationen, Uploads, Datenbanken oder Medienmetadaten nicht unbemerkt ändern.

Numerische UID und GID vor dem Update erfassen

Erfassen Sie den Benutzer des laufenden Prozesses, die primäre Gruppe, ergänzende Gruppen sowie die numerische Eigentümerschaft repräsentativer Dateien in jedem beschreibbaren Mount. Speichern Sie den Image-Digest oder die Version zusammen mit dieser Eigentümer-Baseline.

Die Anleitung zu Docker für die Erstellung von Images besagt, dass explizite IDs Abweichungen bei Neubuilds vermeiden, da automatisch zugewiesene Image-Benutzer bei Neubuilds unterschiedliche numerische IDs erhalten können.

Erfassen Sie Zahlen und nicht nur Namen wie app oder media. Ein neues Image kann denselben Benutzernamen wiederverwenden und gleichzeitig seine UID ändern, während Host-Dateien die numerische Eigentümerschaft speichern.

Den Laufzeitbenutzer im Bereitstellungsvertrag festlegen

Wenn das Image die direkte Ausführung unter einem Nicht-Root-Konto unterstützt, geben Sie den vorgesehenen Benutzer und die Gruppe explizit in Compose oder der Laufzeitkonfiguration an. Wenn das Image eine Initialisierungsphase mit Root-Rechten benötigt, dokumentieren Sie, welcher nachfolgende Prozess tatsächlich persistente Daten schreibt.

Die Open Container Image Specification definiert User als Laufzeitstandard. Das bedeutet, dass ein geändertes Image die Laufzeitidentität ändern kann, sofern die Bereitstellung sie nicht bewusst überschreibt oder überprüft.

Erzwingen Sie bei Images, die ein unterstütztes Initialisierungsmodell benötigen, keine beliebige Nicht-Root-UID. Der Vertrag sollte dem dokumentierten Design der Anwendung folgen und zugleich dafür sorgen, dass der Besitzer persistenter Dateien vorhersehbar bleibt.

PUID und PGID an die Host-Eigentümerschaft angleichen

Bei Images, die PUID- und PGID-Variablen bereitstellen, legen Sie diese Werte in der versionskontrollierten Compose- oder Umgebungskonfiguration fest und stellen Sie sicher, dass die Verzeichnisse der Host-Volumes dem entsprechenden Dienstkonto gehören.

LinuxServer erklärt, dass PUID Schreibvorgänge aus dem Container zuordnet, sodass in zugeordneten Volumes erstellte Dateien außerhalb des Containers verwaltet werden können.

Vergleichen Sie vor dem Update die konfigurierten IDs mit id auf dem Host und mit der vorhandenen Dateieigentümerschaft. Übernehmen Sie einen Beispielwert wie 1000 nicht blind auf einen Server, auf dem diese ID einer anderen Person oder einem anderen Dienst gehört.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

User-Namespaces und Rootless-Zuordnungen berücksichtigen

Rootless Docker oder Podman kann einen Prozess innerhalb des Containers als Root erscheinen lassen, während er auf eine Nicht-Root-UID des Hosts abgebildet wird. Erfassen Sie den Namespace-Modus und die Konfiguration der untergeordneten UID/GID-Bereiche, bevor Sie Änderungen der Eigentümerschaft interpretieren.

Die Laufzeitoptionen von Podman zeigen, dass keep-id die Benutzerzuordnung beibehält, wenn ein Container vorhersehbaren Zugriff auf auf dem Host eingebundene Dateien benötigt.

„Beheben“ Sie einen innerhalb des Containers wie Root erscheinenden Besitzer nicht, bevor Sie die numerische ID auf der Host-Seite geprüft haben. Namespace-Root und Host-Root sind nicht immer dieselbe Identität.

Das neue Image vorab mit einem Test-Volume prüfen

Führen Sie das neue Image vor dem Ersetzen des Produktionscontainers mit der vorgesehenen UID/GID und einem temporären Verzeichnis aus, das die Berechtigungen der Produktion nachbildet. Lassen Sie die Startinitialisierung eine Datei und ein Verzeichnis erstellen und prüfen Sie anschließend deren Eigentümerschaft auf der Host-Seite.

Der Debugging-Leitfaden von Red Hat für Rootless-Volumes zeigt, dass die Host-Eigentümerschaft der UID-Zuordnung folgt, anstatt dass der innerhalb des Containers angezeigte Benutzername allein ein ausreichender Beleg ist.

Wenn der Canary unerwartete Dateien im Besitz von Root oder neu zugeordnete Dateien erstellt, stoppen Sie den Rollout und vergleichen Sie Image-Benutzer, Entrypoint, Namespace und Mount-Einstellungen. Das ist wesentlich sicherer, als die Änderung erst zu entdecken, nachdem eine rekursive Startmigration einen vollständigen Foto- oder Datenbankbaum verändert hat.

Ergänzende Gruppen und beschreibbare Pfade überprüfen

Einige Apps benötigen neben einer primären Dienst-UID den Zugriff über eine gemeinsame Medien-, Download- oder Gerätegruppe. Erfassen Sie diese Gruppen-IDs und testen Sie alle beschreibbaren Pfade, nicht nur das Konfigurationsverzeichnis.

Kubernetes verwendet explizite runAsUser- und runAsGroup-Steuerungen und veranschaulicht damit dasselbe Prinzip der Linux-Eigentümerschaft auch außerhalb einer einfachen Docker-Compose-Bereitstellung.

Die Update-Richtlinie ist vollständig, wenn das neue Image über jeden persistenten Pfad hinweg Dateien mit der erwarteten Host-Eigentümerschaft erstellt und eine Neuerstellung des Containers übersteht. Der zugehörige ZimaSpace-Artikel über Dateien im Besitz von Root nach Image-Updates beschreibt den Wiederherstellungsweg, falls ein Rollout bereits Daten im Besitz von Root erzeugt hat.