Warum sollten Container nicht standardmäßig als Root ausgeführt werden?

Die Ausführung von Containern als Root ist eine der häufigsten — und gefährlichsten — Fehlkonfigurationen in Produktionsumgebungen. Sie vergrößert stillschweigend die Angriffsfläche jedes Workloads, und die meisten Teams bemerken das Problem erst, wenn ein Incident die Sache erzwingt.

Was "Ausführung als Root" tatsächlich bedeutet

Standardmäßig führen viele Container-Images (besonders minimalistische oder ältere) ihren Hauptprozess als UID 0 innerhalb des Containers aus. Da Container den Host-Kernel mit anderen Containern und dem Host selbst teilen, ist Root innerhalb eines Containers nicht dasselbe wie Root auf einer vollständig isolierten virtuellen Maschine — aber es ist immer noch weitaus leistungsstarker, als es sein sollte. Wenn ein Angreifer Code-Ausführung in einem Root-eigenen Container erreicht, erbt er:

• Vollständigen Lese-/Schreibzugriff auf alle Dateien, die in den Container eingebunden sind, unabhängig von beabsichtigten Berechtigungen
• Die Möglichkeit, Pakete zu installieren, Binärdateien zu ändern oder Anwendungsstatus zu manipulieren
• Einen viel einfacheren Weg zum Container-Escape, wenn eine Kernel- oder Runtime-Schwachstelle ausnutzbar ist
• Erhebliche Hebelwirkung in Kombination mit fehlkonfigurierten Volumes, wie einem eingebundenen Docker-Socket oder Host-Dateisystem-Pfad

Selbst ohne Kernel-Exploit vergrößert Root-Zugriff innerhalb des Containers die Auswirkungen jeder Schwachstelle auf Anwendungsebene (SSRF, Deserialisierungsfehler, beliebiges Datei-Schreiben usw.) dramatisch.

Warum dies in orchestrierten Umgebungen wichtiger ist

In Kubernetes-Clustern kann ein Root-Container in Kombination mit übermäßigen Linux-Capabilities oder einem zu permissiven Security-Context einem Angreifer Folgendes ermöglichen:

• /proc oder /sys auf Weise zu ändern, die den Host beeinflussen
• Privilegien zu eskalieren, wenn hostPID, hostNetwork oder hostIPC aktiviert sind
• Ein eingebundenes Service-Account-Token auszunutzen, um sich lateral über den Cluster zu bewegen
• Zum Node zu entkommen, wenn privileged: true gesetzt ist oder gefährliche Capabilities wie SYS_ADMIN gewährt sind

Der Root-Benutzer selbst ist nicht immer die Schwachstelle — es ist die Kombination aus Root plus übermäßig großzügigen Kernel-Capabilities, Host-Mounts oder Namespace-Sharing, die einen begrenzten Kompromiss in einen clusterweiten umwandelt.

Praktische Härtungsschritte

1. Einen Nicht-Root-Benutzer im Image definieren

Definieren Sie explizit einen Nicht-Root-Benutzer in Ihrem Dockerfile, anstatt sich auf Standardwerte zu verlassen:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Erzwingung auf Orchestrator-Ebene

Verlassen Sie sich nicht nur auf das Image — erzwingen Sie die Policy zur Laufzeit. In Kubernetes verwenden Sie einen securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true führt dazu, dass der Pod bei der Zulassung fehlschlägt, wenn das Image versucht, als UID 0 auszuführen, und gibt Ihnen eine harte Garantie anstelle einer Best-Effort-Konvention.

3. Unnötige Capabilities streichen

Die meisten Anwendungen benötigen keine der Standardkapazitäten, die Containern gewährt werden. Löschen Sie alles und fügen Sie nur das hinzu, was absolut erforderlich ist (seltene Fälle wie das Binden an Low-Ports könnten NET_BIND_SERVICE benötigen).

4. Privilegierten Modus und Host-Namespace-Sharing vermeiden

privileged: true, hostNetwork: true und hostPID: true sollten bestimmten Infrastruktur-Workloads (wie bestimmten CNI- oder Monitoring-Agenten) vorbehalten sein — nie für allgemeine Anwendungs-Container.

5. Scannen und Erzwingung mit Policy-Tools

Verwenden Sie Admission Controller oder Policy-Engines (z. B. Kyverno, OPA/Gatekeeper), um Deployments, die diese Regeln verletzen, automatisch abzulehnen, anstatt sich auf manuelle Code-Review zu verlassen. Kombinieren Sie dies mit Image-Scanning in CI, um Root-User-Images zu erfassen, bevor sie einen Cluster erreichen.

Eine geschichtete, nicht perfekte Verteidigung

Die Ausführung als Nicht-Root eliminiert das Risiko nicht vollständig — Kernel-Level-Container-Escapes existieren unabhängig vom In-Container-Benutzer — aber sie entfernt eine riesige Klasse von Low-Effort-Privilege-Escalation und Lateral-Movement-Techniken. In Kombination mit Read-Only-Filesystemen, gelöschten Capabilities und restriktiven Netzwerk-Policies bildet sie eine der billigsten und wirksamsten Schichten in einer Defense-in-Depth-Container-Security-Strategie.

Wollen Sie mehr über das Härten von Cloud-Native-Workloads erfahren? Erkunden Sie verwandte Korra Studio-Segmente zu Cloud-Sicherheit und DevOps-Pipeline-Härtung, um den Rest Ihrer Defense-in-Depth-Strategie aufzubauen.