Ist OpenShift sicherer als Kubernetes? Ein ehrlicher Blick auf SCC, SELinux und PSP

„Ist OpenShift sicherer als Kubernetes?" Diese Frage höre ich seit Jahren, meistens in Kundenmeetings, in denen jemand eine Architektur-Entscheidung treffen muss, bei der viel Geld und viel Reputation auf dem Tisch liegen. Die kurze Antwort ist: Ja, oft ja, aber aus anderen Gründen, als die meisten vermuten. Die lange Antwort lohnt sich, weil Security bei Container-Plattformen ein Feld ist, auf dem Halbwahrheiten sich hartnäckig halten.

Der Ausgangspunkt: Default-Zustand

Der wichtigste Unterschied zwischen OpenShift und einem frisch installierten Kubernetes ist nicht die Technologie, sondern der Default. OpenShift kommt mit einem voreingestellten Sicherheitsmodell, das produktionsnah ist. Kubernetes kommt mit einem Modell, das flexibel ist, weil es sich an viele Welten anpassen muss.

Das bedeutet konkret: Wer auf OpenShift ein Deployment anlegt, bekommt standardmäßig einen sehr restriktiven Sicherheitskontext. Keine root-Container, keine privilegierten Pods, eingeschränkte Capabilities, erzwungene User-Namespaces, definierte SELinux-Labels. Wer auf Kubernetes ein Deployment anlegt, bekommt, was er eingibt. Inklusive root, inklusive privileged, inklusive aller Linux-Capabilities, wenn niemand gebremst hat.

Für die Frage nach Sicherheit ist das entscheidend. Security ist in der Praxis fast immer eine Frage der Defaults. Die wenigsten Angriffe passieren, weil jemand eine exotische Lücke ausnutzt. Die meisten passieren, weil irgendwo eine großzügige Default-Konfiguration stand, die niemand absichtlich so wollte.

Security Context Constraints als Backbone

OpenShifts zentrales Konzept sind die Security Context Constraints, kurz SCC. SCCs legen fest, welche Sicherheitseigenschaften ein Pod haben darf. Das geht deutlich weiter als die Pod Security Standards in Kubernetes. Ein SCC kann präzise regeln, welche User-IDs erlaubt sind, welche SELinux-Kontexte angewandt werden, welche FSGroups, welche Volumes, welche Capabilities, ob Host-Netzwerk erlaubt ist und vieles mehr.

Aus meiner Erfahrung ist das das Feature, das OpenShift im Unternehmenseinsatz wirklich auszeichnet. Nicht, weil Kubernetes nichts Vergleichbares könnte – Pod Security Admission in neueren K8s-Versionen geht in diese Richtung –, sondern weil SCCs seit Jahren stabil und breit genutzt sind. Wer in einem regulierten Umfeld arbeitet, hat hier eine Mechanik, die auditierbar und nachvollziehbar ist.

Kubernetes hatte früher Pod Security Policies (PSP), die gerne als Gegenstück genannt wurden. PSPs sind inzwischen deprecated und in modernen Clustern entfernt. Der Nachfolger, Pod Security Admission (PSA), funktioniert mit drei Stufen (privileged, baseline, restricted) und ist deutlich einfacher als SCC. Einfacher heißt hier nicht besser, es heißt grobkörniger. Wer sehr fein granulare Policies braucht, ergänzt PSA in der Praxis oft mit Kyverno oder Gatekeeper. Dann ist man plötzlich wieder bei einem Tool-Stack, den OpenShift nativ mitbringt.

SELinux ist kein Detail

Ein Punkt, der in Kubernetes-Debatten oft untergeht: SELinux. OpenShift läuft auf Red Hat CoreOS, und SELinux ist dort im enforcing-Modus aktiv. Das heißt, selbst wenn ein Container ausbricht oder ein Prozess ungewollt privilegiert läuft, greift noch eine zweite Schutzschicht auf Betriebssystemebene.

Kubernetes-Cluster laufen auf einer sehr heterogenen Basis. Von Ubuntu über Debian bis hin zu Windows-Nodes ist alles möglich. SELinux-enforcing ist hier nicht der Standard. Das ist kein Bug des Ökosystems, das ist das Wesen eines offenen Ökosystems. Aber es ist ein Sicherheitsfaktor, den man sauber bewerten muss.

Wer in einer regulierten Umgebung arbeitet, für den ist SELinux-enforcing faktisch ein Plus, das OpenShift out-of-the-box mitbringt. Wer diese Schicht in Kubernetes haben will, muss sie bewusst bauen, validieren und betreiben. Das ist machbar, aber es ist Arbeit.

Was Kubernetes ausgleicht

Damit die Bilanz fair bleibt: Kubernetes hat Bereiche, in denen es deutlich voraus ist. Das Ökosystem ist breiter. Die Community-Innovationen fließen oft zuerst in Kubernetes und kommen dann in OpenShift an. Tools wie OPA/Gatekeeper, Kyverno, Falco, Cilium und viele andere sind im K8s-Umfeld extrem stark und lassen sich zu einem Sicherheitsstack kombinieren, der in Teilen über das hinausgeht, was OpenShift standardmäßig mitbringt.

Der entscheidende Unterschied ist nicht „sicher vs. unsicher", sondern „ab Werk vs. selbst zusammengebaut". Wer ein Team hat, das K8s-Security wirklich beherrscht, kann sehr sichere Cluster bauen. Wer ein Team hat, das eine Plattform mit sinnvollen Defaults und klar definierten Grenzen sucht, ist mit OpenShift besser beraten.

Mein Fazit

Ist OpenShift sicherer als Kubernetes? In der Praxis, vor allem am ersten Tag, ja. In der Theorie kann man mit Kubernetes genau so weit kommen. Der Punkt ist: Sicherheit ist nie das, was theoretisch möglich ist. Sicherheit ist das, was real läuft, während niemand hinschaut.

Wer Container-Plattformen bewertet, sollte deshalb weniger über „welche Technologie ist besser" diskutieren und mehr über die eigene Organisation. Wie viel Security-Know-how ist im Team? Welche Defaults reichen euch? Wie gut seid ihr darin, eure eigene Konfiguration auditierbar zu halten?

Für viele Unternehmen im Mittelstand ist OpenShift genau aus diesen Gründen die ehrlichere Wahl. Für erfahrene Plattform-Teams mit eigenem Security-Ansatz kann Kubernetes mindestens so sicher sein. Die Antwort liegt in der Organisation, nicht im Logo auf dem Cluster.