Docker/Userns-remap

Docker/Userns-remap - Beschreibung

Beschreibung

Linux-Namespaces

Isolation laufender Prozesse

• Systemressourcen beschränken
• ohne dass Prozesse die wahrnehmen

Rechteausweitung verhindern

Anwendungen von Containern mit nicht privilegierten Benutzern ausführen

Root-Benutzer innerhalb des Containers

Können einem Benutzer mit weniger Privilegien auf dem Docker-Host zugeordnet werden

Bereich von UIDs

Dem Benutzer wird ein Bereich von UIDs zugewiesen

• Docker verwendet Sub-UID/GID-Bereiche aus /etc/subuid und /etc/subgid (default dockremap)

Vorbereitung

Nach dem Aktivieren von userns-remap verwendet Docker einen separaten Datenpfad:

/var/lib/docker/<uid>.<gid>/

• Neue Entitäten (Images, Container, Volumes, Overlay-Ebenen) werden dort gespeichert
• Kataloge mit bisherigen Entitäten werden in diesem Modus nicht verwendet (wirken ausgeblendet)
• docker ps, docker images, docker volume ls zeigen nur Entitäten aus dem aktuell verwendeten Docker-Datenpfad
• Der Eigentümer der Dateien in overlay2 und volumes ist nun nicht mehr root, sondern der remapped-Benutzer

Für neue Installationen

Images und Container lassen sich einfacher und schneller neu laden als migrieren

Bei aktiviertem userns-remap

• --pid=host und --network=host können nicht verwendet werden
• Einige externe Volume-/Speichertreiber verstehen möglicherweise remap nicht und funktionieren nicht mehr
• --privileged ohne --userns=host funktioniert nicht mehr wie zuvor, einige Funktionen sind eingeschränkt
• Es ist besser, userns-remap bei einer sauberen Docker-Installation zu aktivieren: Alte Image-Layer und Container werden ausgeblendet, da Docker einen separaten Ordner für den neuen Namespace in /var/lib/docker/ erstellt

Migration zu neuen Namespaces

Bei bestehender Installation werden vorhandene Objekte nicht automatisch umgeschrieben

• Praktisch erfolgt ein Neuaufbau: Images neu laden, Container neu erstellen
• Persistente Daten (Bind-Mounts/Volumes) erfordern passende Ownership für den remapped UID/GID-Bereich

Installation

Standardbereich vorab festlegen

Für konsistente Ownership bei Bind-Mounts empfiehlt sich ein fester Startbereich ab 200000.

• Bereiche dürfen sich nicht überschneiden
• Startbereich nach produktiver Nutzung zu ändern führt typischerweise zu inkonsistenter Ownership. Neuaufbau und Anpassung persistenter Daten erforderlich

/etc/subuid

dockremap:200000:65536

/etc/subgid

dockremap:200000:65536

Ergebnis

• Prozess läuft als root (UID 0) im Container -> Host-UID 200000
• Prozess läuft als UID 1000 im Container -> Host-UID 201000
• MySQL nutzt häufig UID 999 -> Host-UID 200999
• Verwendete UIDs/GIDs sind image-spezifisch

userns-remap aktivieren

/etc/docker/daemon.json

{
  "userns-remap": "default"
}

Oder Sie können den Benutzer manuell eingeben:

{
  "userns-remap": "testuser"
}

Sie können den Namen, die UID oder user:group angeben

Dienst neu starten

Nach dem Speichern der Datei den Dienst neu starten:

sudo systemctl restart docker

Überprüfung

docker info | grep -i userns

Userns mode: private

Bind-Mounts

• Bei Bind-Mounts muss der Host-Dateibesitzer zur remapped UID/GID passen, sonst können Dienste nicht starten (z.B. fehlende Schreibrechte)

Ziel-UID berechnen

grep dockremap /etc/subuid /etc/subgid

Ausgabe:

dockremap:200000:65536

Bespiel: Anwendung läuft im Container als UID/GID 1000.

• HOST_UID = 200000 + 1000 = 201000

sudo chown -R 201000:201000 /path/to/bind-mount

• Die Rechte sind nun korrekt festgelegt.

Standard UID

Für konsistente Ownership bei Bind-Mounts empfiehlt sich ein fester Startbereich ab 200000

Neustart des Dienstes

sudo systemctl restart docker

---