81 Namespaces (User, PID, Network, Mount, UTS, IPC)

Namespaces bilden das Kernstück der Container-Isolation unter Linux. Alles, was wir in Podman, Kubernetes oder containerd als „Container“ bezeichnen, ist in Wahrheit nur eine reguläre Prozessgruppe, die in einer isolierten Menge von Namespaces läuft. Namespaces definieren, welchen Ausschnitt der Systemrealität ein Prozess sieht: Welche Prozesse existieren? Welches Netzwerk? Welche Mounts? Welcher Hostname? Welche Benutzer? Container sind keine Mini-VMs – sie sind Prozesse, deren Sicht auf die Welt durch Namespaces gefiltert ist.

Dieses Kapitel erläutert die sechs zentralen Namespace-Typen: User, PID, Network, Mount, UTS und IPC. Sie bilden ein Schichtmodell, das sich kombinieren lässt. Erst ihr Zusammenspiel erzeugt das isolierte Laufzeitumfeld, auf dem moderne Containerplattformen basieren.

81.1 Überblick: Kernel-Isolation als Zusammenspiel

Ein einfaches Modell zeigt die Wirkung:

Jeder Namespace isoliert einen eigenen Aspekt des Betriebssystems – zusammen bilden sie eine konsistente Sicht, die ein Prozess als „sein System“ interpretiert.

81.2 User Namespace – Root ohne Privilegien

Der User Namespace ist der vielleicht wichtigste Teil der modernen Containersicherheit. Er ermöglicht die Um­abbildung von Benutzer- und Gruppen-IDs zwischen Host und Container.

Kernidee:

• UID/GID 0 im Container entspricht NICHT Root auf dem Host.
• Stattdessen wird UID 0 im Container auf eine „normale“ UID im Host gemappt.
• Dadurch können Container root sein, ohne Root zu sein.

Mapping-Beispiel:

Host-User alice (UID 1000)
Container-Root (UID 0 → mapped to 100000)

Vorteile:

• drastisch verringerte Angriffsfläche
• rootless Container möglich
• Dateisystemzugriffe bleiben kontrolliert
• keine Kernel- oder Geräteoperationen ohne explizite Rechte

Der User Namespace ist die Grundlage für Podmans Rootless Mode.

81.3 PID Namespace – Prozessbaumisolierung

Der PID Namespace bestimmt, welche Prozesse ein Container sehen kann. Hauptmerkmale:

• jeder Container hat seinen eigenen Prozessbaum
• PID 1 im Container ist sein eigener „Init-Prozess“
• Host-Prozesse sind im Container unsichtbar
• Containerprozesse sind im Host sichtbar – aber nicht umgekehrt

PID-Isolation schafft die Illusion einer eigenen Prozesshierarchie.

Beispielstruktur:

Diese Isolation verhindert, dass Container:

• Prozesse des Hosts beeinflussen
• Signale in fremde Prozessbäume schicken
• Tools wie ps oder prlimit zum Ausbruch nutzen

81.4 Network Namespace – eigene Netzwerkwelt

Der Network Namespace definiert:

• eigene IP-Adresse
• eigene Netzwerkinterfaces
• eigenes Routing
• eigene Firewall-Regeln

Jeder Container kann damit wie ein eigener kleiner Rechner erscheinen. Im Rootless Mode übernimmt slirp4netns die Netzwerksimulation im Userspace.

Typischer Aufbau:

eth0 → Container-interne Netzwerkkarte
vethX → Verbindung zum Host
cni0  → Bridge im Hostsystem

Ohne diesen Namespace gäbe es keine Pod-Netzwerke, keine Overlay-Netze und keine Multi-Container-Pods.

Praktisch:

• Container können nicht direkt in Host-Netzwerke eingreifen.
• Netzwerkisolation ist ein wesentliches Sicherheitsmerkmal.
• Kubernetes baut auf Network-Namespace-Isolation + CNI auf.

81.5 Mount Namespace – Dateisystemsicht isolieren

Der Mount Namespace bestimmt, welche Dateisysteme und Mounts ein Prozess sieht. Container erhalten damit eine vollständig unabhängige Mount-Tabelle:

• eigenes Root-Filesystem
• eigenes OverlayFS
• eigene Bind-Mounts
• eigene tmpfs-Bereiche

Mount Namespaces bilden die Grundlage für das Container-Filesystemmodell.

Montagebeispiel:

Wichtig:

• Host-Filesystem bleibt unangetastet
• Container können nur gemountete Bereiche verändern
• rootless Container können keine Host-Mounts anlegen

Der Mount Namespace verhindert direkte Manipulation am System – selbst durch Container, die „root“ sind.

81.6 UTS Namespace – Hostname und Domain

Der UTS Namespace isoliert Hostname und Domainname. Dadurch:

• kann jeder Container seinen eigenen Hostnamen besitzen
• wirken Logs und Tools wie hostname konsistent
• bleiben Containersysteme voneinander unterscheidbar

Beispiel:

Host:       prod-node-01
Container:  web-app

Der UTS Namespace ist klein, aber wertvoll. Er schafft semantische Ordnung in verteilten Umgebungen.

81.7 IPC Namespace – isoliertes Shared Memory

Der IPC Namespace isoliert Interprozesskommunikation:

• System V Shared Memory
• POSIX Message Queues
• Semaphoren

Ohne diesen Namespace könnten Container:

• auf IPC-Ressourcen des Hosts zugreifen
• über Shared Memory untereinander kommunizieren
• über Queue-Mechanismen Daten austauschen

IPC-Isolation verhindert „stille“ Seitkanäle zwischen Containern.

81.8 Zusammenspiel der Namespaces

Kein Namespace bietet vollständige Isolation. Erst die Kombination erzeugt ein Rahmenwerk, das robust genug für produktionsnahe Container ist.

Ein Modell:

Jeder Namespace stärkt Isolation auf einer spezifischen Achse:

• User → Identität
• PID → Prozesse
• Network → Connectivity
• Mount → Dateisystem
• UTS → Namensraum
• IPC → Interprozess-Kanäle

Gemeinsam bilden sie das Container-Sicherheitsmodell.

81.9 Fazit im Betrieb: Namespaces verstehen heißt Container verstehen

Wer Namespaces beherrscht, versteht Container technisch wirklich. Tools wie Podman, containerd oder Kubernetes abstrahieren diese Mechanismen, aber sie ändern nichts an der Tatsache: Container sind keine Blackbox-Technologie, sondern klar definierte Linux-Konstrukte.

Für Architekten bedeutet das:

• Sicherheitsmodelle basieren auf Kernel-Features, nicht auf Tools.
• Rootless Mode wird durch User Namespaces erst möglich.
• Pod-Isolation funktioniert über Network- und PID-Namespace-Pooling.
• Kubernetes skaliert das Namespace-Modell, ersetzt es aber nicht.

Namespaces sind das Betriebssystem-Substrat, auf dem alles Weitere ruht.

# Capabilities

Capabilities sind ein zentrales Sicherheitskonzept des Linux-Kernels und eines der am häufigsten missverstandenen Elemente moderner Container-Laufzeiten. Sie ersetzen das veraltete „Root oder Nicht-Root“-Modell durch eine feingranulare Privilegienmatrix. Containertechnologien wie Podman und Kubernetes nutzen Capabilities intensiv, um Dienste auszuführen, die teilweise root-artige Funktionen benötigen – ohne ihnen den vollen Root-Kontext zu geben. Wer Capabilities versteht, versteht einen der wichtigsten Bausteine für sichere und minimal privilegierte Containerumgebungen.

81.10 Vom Alles-oder-Nichts-Modell zur feingranularen Kontrolle

Historisch war Root ein binäres Konzept: Ein Prozess war entweder root (UID 0) und durfte alles, oder er war ein normaler Benutzer und durfte fast nichts. Dieses Modell ist für moderne Systeme zu grob. Der Kernel führte daher Capabilities ein – einzelne, isolierte Berechtigungsfragmente, die sich einem Prozess flexibel zuweisen lassen.

Beispielhaft:

• CAP_NET_BIND_SERVICE – erlaubt das Binden an Ports < 1024
• CAP_SYS_TIME – erlaubt das Setzen der Systemuhr
• CAP_SYS_ADMIN – der „Chef aller Capabilities“
• CAP_NET_ADMIN – Netzwerkadministration (Routen, Interfaces, Firewall)
• CAP_SYS_MODULE – Laden von Kernelmodulen

Root bekommt standardmäßig alle Capabilities, aber Container erhalten nur einen minimalen Satz.

Ein diagrammatischer Überblick:

Der Container erhält also „ein bisschen Root“ – aber nur genau so viel, wie für seine Aufgabe nötig ist.

81.11 Standard-Capability-Set moderner Container-Engines

Podman und Kubernetes starten Container mit einem reduzierten Capability-Set. Typisch sind aktiv:

• CAP_CHOWN
• CAP_DAC_OVERRIDE
• CAP_FSETID
• CAP_FOWNER
• CAP_MKNOD
• CAP_SETGID
• CAP_SETUID
• CAP_SETFCAP
• CAP_SETPCAP
• CAP_NET_BIND_SERVICE
• CAP_KILL
• CAP_AUDIT_WRITE

Selbst Container-Root erhält damit nur diese Teilmenge – nicht den vollen Root-Zugriff.

Nicht erlaubt sind beispielsweise:

• CAP_SYS_ADMIN (hochgefährlich)
• CAP_NET_ADMIN
• CAP_SYS_MODULE
• CAP_SYS_RAWIO
• CAP_SYS_PTRACE
• CAP_SYS_BOOT

Diese Grenzen verhindern effektiv, dass Container tiefe Systemmodifikationen ausführen können.

81.12 Capabilities im Rootless-Betrieb

Im Rootless Mode ist der Capability-Spielraum noch enger. Da der Kernel User-Namespace-Root keine tiefen Rechte gewährt, reduzieren sich die möglichen Capabilities erheblich:

• Kein CAP_NET_ADMIN
• Kein CAP_SYS_ADMIN
• Kein CAP_SYS_MODULE
• Kein CAP_IPC_LOCK
• Kein direkter Netzwerkzugriff (slirp4netns als Userspace-Lösung)

Das führt zu einem wichtigen Punkt: rootless Container sind sicher, weil Capabilities massiv beschnitten sind.

81.13 Capabilities hinzufügen und entfernen

In Podman:

podman run --cap-add=NET_ADMIN ...
podman run --cap-drop=ALL ...

Ein sehr sicheres Muster:

--cap-drop=all --cap-add=NET_BIND_SERVICE

Das erlaubt dem Container exakt eine privilegierte Funktion: Ports <1024 zu öffnen.

Podman erlaubt auch Kombinationen:

--cap-drop=all
--cap-add=chown
--cap-add=setuid
--cap-add=net_bind_service

Damit entsteht ein präziser Capability-Katalog, den der Prozess wirklich benötigt.

81.14 Capabilities im Kubernetes-Kontext

Kubernetes verwendet Capabilities im securityContext:

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]

Empfohlene Praxis aus Security-Guidelines:

• Immer drop: ["ALL"]
• Nur die Capabilities adden, die wirklich notwendig sind

In Multi-Tenant-Clustern ist dies zwingend – da jeder überschüssige Capability-Vektor potenzielle Eskalationswege öffnet.

81.15 CAP_SYS_ADMIN: das universelle Anti-Pattern

CAP_SYS_ADMIN ist berüchtigt. Sie wird oft als „mini-root“ bezeichnet, aber das ist eine Untertreibung. Diese Capability:

• ermöglicht Mounts
• erlaubt BPF-Operationen
• erlaubt cgroups-Manipulation
• erlaubt Device-Zugriffe
• erlaubt Namespaces zu injizieren
• erlaubt viele „nicht kategorisierte“ Privilegien

Ein Container mit CAP_SYS_ADMIN ist praktisch root in vielerlei Hinsicht.

Erfahrungsregel:

Wenn ein Container CAP_SYS_ADMIN braucht, ist er eigentlich keine Container-Workload, sondern ein Systemprozesse.

81.16 Isolation durch Capabilities: das Zusammenspiel

Capabilities wirken erst in Kombination mit anderen Kernelmechanismen richtig:

Effekt:

• der Prozess läuft isoliert (Namespaces)
• darf nur begrenzte Systemaufrufe machen (Seccomp)
• besitzt nur minimale Privilegien (Capabilities)

Capabilities sind somit der dritte Pfeiler der Container-Sicherheitsarchitektur.

81.17 Praktische Hinweise für Architekten

1. Immer Capabilities droppen – Default ist nicht minimal genug.
2. Capabilities sind nicht rekursiv. Sie gelten pro Prozess, nicht pro Image oder Pod.
3. Capabilities können im Pod geteilt werden, aber nicht automatisch.
4. Rootless Setup ist automatisch capability-minimiert.
5. SecurityContext immer explizit setzen, nie auf Defaults verlassen.

Und ein wichtiger Merksatz:

Ein Container, der viele Capabilities braucht, ist meist falsch modelliert.

Capabilities bilden die feinste Ebene der Privilegsteuerung in Linux. Sie erlauben granulare Rechtezuweisung, machen Container sicherer und bilden – zusammen mit Namespaces und Seccomp – das Fundament eines sauber isolierten Containerbetriebs.