Warum scheitert ein ganz normales Container-Image auf OpenShift - und wie findet man eins, das dort laeuft?

OpenShift verbietet ueber Security Context Constraints (SCC) standardmaessig, dass Container als Root laufen - die SCC restricted-v2 lehnt das grundsaetzlich ab. Ein stinknormales Image wie das offizielle nginx scheitert deshalb einfach. Das steht zwar mittlerweile in einigen Vergleichsartikeln als Feature-Stichpunkt. Was dort fehlt: wie man ueberhaupt ein Image findet, das ohne Root laeuft - auf Docker Hub ist das kaum erkennbar. Die verlaessliche Reihenfolge: zuerst ein Red Hat UBI-Laufzeit-Image aus dem Red Hat Ecosystem Catalog (laeuft bereits als eigener Non-Root-User in der Gruppe 0), sonst eine dedizierte unprivilegierte Variante wie nginx-unprivileged von Nginx Inc, sonst das Image selbst per chgrp/chmod auf Gruppe 0 anpassen.

Ist das Root-Verbot in OpenShift eine Einstellung, die man abschalten kann?

Technisch ja - ueber die SCC anyuid, die Root wieder erlaubt, oder die Namespace-Annotation openshift.io/sa.scc.uid-range, die den zulaessigen UID-Bereich lockert. Davon rate ich in jedem Training ab: Die Einschraenkung ist ein echter Sicherheitsgewinn, kein Bugreport-Anlass. Der richtige Weg ist ein Image, das ohnehin ohne Root auskommt, nicht ein aufgeweichtes SCC-Profil.

Wo finde ich Images, die auf OpenShift garantiert laufen?

In dieser Reihenfolge: Zuerst pruefen, ob es das Tool als Red Hat UBI-Laufzeit-Image im Red Hat Ecosystem Catalog gibt (Python, Node.js, Java und mehr) - die laufen bereits als eigener Non-Root-User in der Gruppe 0, extra fuer OpenShift vorbereitet (die konkrete User-ID unterscheidet sich je Laufzeit, z.B. 1001 bei Python/Node.js, 185 bei den OpenJDK-Images - die Gruppe 0 ist das eigentlich Entscheidende). Gibt es das nicht, nach einer dedizierten unprivilegierten Variante des Herstellers suchen, wie nginx-unprivileged von Nginx Inc. Bleibt nur das generische Image, hilft nur noch, es selbst anzupassen: die betroffenen Verzeichnisse per chgrp -R 0 und chmod -R g=u auf die Gruppe 0 umstellen, der Gruppe, in der jede beliebige OpenShift-UID automatisch steckt. Ein Blick auf Tags oder Sternezahl ersetzt keinen dieser drei Schritte.

Braucht man fuer UBI-Images eine Red-Hat-Subscription?

Nein - und das ist der ganze Witz an UBI (Universal Base Image), im Unterschied zu regulaeren RHEL-Images. Laut Red Hats eigener UBI-Lizenz sind Nutzung, Deployment und Weiterverteilung komplett subscription-frei, das gilt auch fuer die Sprach-Laufzeit-Varianten wie Python oder Node.js. Eine Subscription brauchst du erst, wenn du zusaetzliche, nicht-UBI-RHEL-Pakete ins Image holst - fuer den reinen Root-freien Einsatz auf OpenShift ist das nicht noetig.

Ist OpenShift damit sicherer als Vanilla Kubernetes?

In diesem einen Punkt: ja, spuerbar. Vanilla Kubernetes erlaubt Root-Container standardmaessig, OpenShift verbietet sie von Haus aus. Das ist aber kein Grund, sich bei Vanilla Kubernetes zurueckzulehnen - dort musst du dieselbe Absicherung ueber Pod Security Standards oder eine eigene Policy selbst aktiv einrichten, sie kommt nur nicht automatisch.

Strategien

OpenShift verbietet Root-Container - das steht in jedem Vergleich. Wie man trotzdem ein lauffaehiges Image findet, in keinem.

Das passende Training Kubernetes Security Training – Cluster hacken, verstehen, absichern (3 Tage)

OpenShift verbietet Root-Container - das steht in jedem Vergleich. Wie man trotzdem ein lauffähiges Image findet, in keinem.

Kurz und schmerzlos vorweg, die Antwort auf die Frage aus der Überschrift: Dein ganz normales Image scheitert auf OpenShift, weil Root-Container dort grundsätzlich verboten sind - das steht mittlerweile in einigen Vergleichsartikeln als Haken hinter “integrierte Security”. Was da nirgends steht: wie du dann überhaupt an ein Image kommst, das ohne Root läuft. Genau das hat mir bei einer Schulung so richtig die Augen geöffnet.

Der Moment, in dem die Übung einfach nicht startete

Ich hatte eine Helm-Schulung bei einem großen Finanzinstitut, OpenShift-Umgebung. Deployment-Übung, ganz normales Setup, das ich auf Vanilla-Kubernetes-Clustern hundertfach durchgespielt habe: ein Standard-nginx-Image rein, Service davor, fertig. Nur diesmal kam der Pod nicht hoch. CrashLoopBackOff, und in den Logs eine Fehlermeldung, die auf den ersten Blick nach einem kaputten Manifest aussah.

War es aber nicht. nginx will beim Start auf Port 80 ran und ein paar Systempfade anfassen - beides geht nur mit Root. Und genau das verweigert OpenShift von der ersten Sekunde an: Jedes Projekt bekommt automatisch die strengste Voreinstellung im System, die SCC restricted-v2. Root-Container? Geht nicht, Punkt. Keine Sonderkonfiguration von diesem einen Kunden - einfach Werkszustand, laut offizieller Dokumentation.

Was daraus wurde

Seitdem gilt bei mir eine feste Reihenfolge. Erster Griff: Gibt’s das Tool als Red Hat UBI-Laufzeit-Image? Die Python-, Node.js- und Java-Images im Red Hat Ecosystem Catalog laufen bereits als eigener Non-Root-User in der Gruppe 0. Welche User-ID das genau ist, variiert - 1001 bei Python und Node.js, 185 bei den OpenJDK-Images. Entscheidend ist ohnehin nur die Gruppe 0, fix und fertig für OpenShift gebaut, kein Rätselraten nötig. Und nein, dafür brauchst du keine Red-Hat-Subscription - Nutzung und Weiterverteilung sind laut UBI-Lizenz bewusst frei, das ist ja der Witz an “Universal” Base Image.

Zweiter Griff, wenn’s das nicht gibt: eine dedizierte unprivilegierte Variante des Herstellers suchen, so wie nginx-unprivileged von Nginx Inc. Ein eigenes, offizielles Image, genau für diesen Fall gebaut: anderer Standard-Port (8080 statt 80), keine Root-Direktive mehr, alle Pfade auf /tmp umgebogen.

Und wenn’s auch das nicht gibt? Dann liegt der eigentliche Pferdefuß vor dir, über den kein Vergleichsartikel spricht: Du stehst vor Hunderten generischen Images auf Docker Hub, und keins davon sagt dir vorher, ob’s ohne Root läuft. Kein Filter, kein Tag, kein Hinweis in der Kurzbeschreibung. Dann bleibt nur, selbst Hand anzulegen: die betroffenen Verzeichnisse per chgrp -R 0 und chmod -R g=u auf die Gruppe 0 umstellen - genau die Gruppe, in der jede beliebige OpenShift-UID automatisch steckt. Mehr Aufwand, aber kein Zufall mehr.

Warum das wichtiger ist als die Feature-Liste

Wenn du OpenShift und Kubernetes vergleichst, liest du meistens eine Tabelle: eingebautes CI/CD hier, Security Context Constraints dort, fertig. Technisch stimmt das. Nur merkt in der Praxis niemand etwas von einer Tabellenzeile - man merkt den Pod, der nicht hochkommt, drei Tage vor dem Go-Live.

Und ja, das ist in diesem einen Punkt ein echter Sicherheitsgewinn für OpenShift: Vanilla Kubernetes erlaubt Root-Container standardmäßig, du musst die Einschränkung selbst aktiv einrichten (über Pod Security Standards, dazu mehr in unserem Kubernetes-Security-Training). OpenShift nimmt dir die Entscheidung von vornherein ab - gut gemeint, aber eben nur dann komfortabel, wenn du vorher weißt, worauf du achten musst.

Meine klare Ansage

Erst UBI checken, dann nach einer unprivilegierten Herstellervariante suchen, erst als letzten Ausweg selbst patchen - in genau dieser Reihenfolge. Kommt das Image nicht aus dem Red Hat Ecosystem Catalog, zusätzlich in die Werkstatt schicken. Der Test: docker run --user 12345:0 - eine willkürliche User-ID, aber Gruppe 0, genau wie OpenShift es macht. Kommt der Container hoch, läuft er überall. Sternezahl und Bekanntheit auf Docker Hub oder Artifact Hub sagen über Root-Tauglichkeit exakt gar nichts aus.

Fazit

Root-Verbot per SCC steht mittlerweile in etlichen OpenShift-vs-Kubernetes-Vergleichen. Was daraus für dein nächstes Deployment folgt, steht in keinem. Ich zeig dir das lieber einmal live im Training, als dass es dir wie bei diesem Kunden drei Tage vor dem Go-Live passiert.