← Übersicht  ·  Skripte & Dateien  ·  cloud-host · OpenShift · Betrieb

RBAC und SCC in OpenShift

Die Zeichnungen dazu stehen hier bei den jeweiligen Schritten. Hier spielst du es von Hand durch: Rollen binden und prüfen, dann sehen, wie dasselbe Binding darüber entscheidet, welche SCC ein Pod bekommt – und warum er ohne sie nicht startet. EX280-relevant.

Stand: 4. September 2026 OKD 4.x / OCP 4.x ns library

Voraussetzung: ein Cluster mit oc login als Admin (kubeadmin reicht), Namespace library (oc new-project library oder oc project library).

1 Das RBAC-Modell

Zwei Objektarten, sauber getrennt: was erlaubt ist und wer es darf.

Nach dem Anmelden (A4) weiß der Cluster wer du bist – aber noch nicht, was du darfst. Das klärt RBAC mit genau zwei Objektarten: einer Rolle (Liste erlaubter Aktionen) und einem Binding (hängt die Rolle an eine Person, Gruppe oder einen ServiceAccount). Ein frischer User darf zuerst fast nichts.

Zwei Objekte: eine Rolle sagt WAS erlaubt ist, ein Binding sagt WER sie bekommt. 1 · Was ist erlaubt? – Role / ClusterRole Datei: du legst an – meist schon im Helm-Chart enthalten Role – gilt in genau einem Namespace ClusterRole – clusterweit, oder als Vorlage für viele Namespaces = Liste von Regeln (rules). Jede Regel kombiniert drei Achsen: verbsget · list · watch · create · update · patch · delete resourcespods · services · routes · deployments · secrets · … apiGroups"" (core) · apps · route.openshift.io · … Beispiel-Regel – „darf Pods und ihre Logs ansehen“: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] 2 · Wer bekommt es? – RoleBinding / ClusterRoleBinding Datei: du legst an – oder oc adm policy erzeugt sie für dich RoleBinding – im Namespace: koppelt roleRef → subjects ClusterRoleBinding – dieselbe Kopplung, clusterweit subjects – wer angesprochen wird: User aus dem IdP (A4)  ·  Group z. B. per LDAP-Sync ServiceAccount – system:serviceaccount:<ns>:<name>  ↗ A6 so entsteht ein Binding – ganz ohne YAML: oc adm policy add-role-to-user edit alice -n biblio → RoleBinding, das die ClusterRole edit an alice hängt – nur in biblio … add-role-to-user edit -z pipeline -n biblio -z statt Benutzername = ein ServiceAccount im selben Namespace … add-cluster-role-to-user cluster-reader bob  (→ clusterweit) roleRef Default-ClusterRoles – vom Cluster mitgeliefert (wichtig zu kennen, nicht editieren) viewnur lesen – Secrets ausgenommen editWorkloads anlegen / ändern / löschen – aber nicht RBAC, nicht Quota & LimitRange adminwie edit + RBAC, aber ohne Quota im eigenen Namespace – oc new-project gibt dem Anleger genau das cluster-adminalles, überall – der Vollzugriff (kubeadmin und system:admin haben ihn) self-provisionerdarf neue Projekte anlegen – an die Gruppe system:authenticated:oauth gebunden Maschinen-Rollen für Build & Registry: system:image-builder · system:deployer · registry-editor · registry-viewer Warum admin / edit / view mit der Zeit „mehr können“ Diese drei sind aggregiert: sie sammeln automatisch jede ClusterRole mit dem Label rbac.authorization.k8s.io/aggregate-to-edit: "true". Ein Operator bringt für seine eigenen CRDs so eine markierte ClusterRole mit. → nach der Operator-Installation kann edit plötzlich z. B. Kafka-Topics verwalten – ohne dass jemand ein Binding angefasst hat. prüfen: oc get clusterrole -l rbac.authorization.k8s.io/aggregate-to-edit  ·  Operatoren & OLM ↗ D1 Bibliothek / cloud-host – der ServiceAccount pipeline Bindings: wird generiert vom Deploy-Skript scripts/jenkins.ps1 Namespace library · SA pipeline – die Identität, unter der Jenkins baut und ausrollt drei RoleBindings, alle nur im Namespace library: adminHelm-Charts der 8 Dienste ausrollen system:image-builderImages in die interne Registry pushen registry-editorImageStreams und Tags pflegen oc policy add-role-to-user admin system:serviceaccount:library:pipeline -n library prüfen und wieder entziehen oc auth can-i --as alice create deploy -n biblio → yes / no – simuliert alice oc adm policy who-can delete route -n biblio → wer darf das im Namespace? oc adm policy remove-role-from-user edit alice -n biblio → löscht das Binding = Entzug (es gibt kein „deny“) oc describe clusterrole edit → welche Regeln in einer Rolle wirklich stecken Reihenfolge: erst authentifiziert (A4 – „wer bist du“), dann autorisiert (RBAC – „was darfst du“). Beides prüft der API-Server, bevor das Objekt geschrieben wird. ↗ RBAC ist rein additiv – mehrere Bindings summieren sich, ein „verbieten“ gibt es nicht. Weniger Rechte = Binding entfernen. SCC (A7) wird ebenfalls über RBAC vergeben: oc adm policy add-scc-to-user bindet die Spezial-ClusterRole system:openshift:scc:<name> ↗ OCP-Unterschied: keiner – reines Kubernetes-RBAC. oc adm policy ist nur Komfort über kubectl create rolebinding / clusterrolebinding.
Rolle + Binding, mehr ist es nicht. Eine Role/ClusterRole zählt erlaubte Aktionen auf (verbs × resources × apiGroups), ein RoleBinding hängt sie an einen User, eine Group oder einen ServiceAccount – im Namespace, oder clusterweit per ClusterRoleBinding. Die Default-Rollen view/edit/admin decken den Alltag ab, oc new-project gibt dir admin auf dein Projekt. RBAC kann nur erlauben, nie verbieten – Entzug heißt: Binding löschen.
  • es gibt zwei Objektarten: Role und ClusterRole sind die Regelliste, RoleBinding und ClusterRoleBinding sind die Zuordnung
  • eine Regel kreuzt drei Achsen: verbs (get, list, watch, create, update, patch, delete), resources und apiGroups (der leere String steht für die Kern-Gruppe)
  • eine Role gilt in einem Namespace, eine ClusterRole clusterweit oder als wiederverwendbare Vorlage
  • Subjekte sind: ein User (aus dem IdP, A4), eine Group oder eine ServiceAccount (system:serviceaccount:<ns>:<name>, A6)
  • die Default-ClusterRoles: view darf lesen (ohne Secrets), edit darf Workloads ändern und Secrets lesen (ohne RBAC), admin darf zusätzlich RBAC im Namespace (aber nicht Quota), cluster-admin darf alles
  • oc new-project legt eine admin-RoleBinding auf den Anleger an (A2) – darum darfst du im eigenen Projekt sofort fast alle normalen Namespace-Ressourcen verwalten
  • eine Rolle binden: oc adm policy add-role-to-user <role> <user> -n <ns>, -z <sa> statt des Namens für eine ServiceAccount, add-cluster-role-to-user für clusterweit
  • aggregierte Rollen: admin, edit und view sammeln automatisch jede ClusterRole mit dem Label aggregate-to-*, so erweitern Operatoren sie von selbst
  • RBAC ist rein additiv, es gibt kein „deny“ – Entzug geht über remove-role-from-user oder das Löschen des Bindings
  • prüfen mit oc auth can-i --as <user> <verb> <resource>, oc adm policy who-can <verb> <resource> oder oc describe clusterrole edit
  • Bibliothek: die SA pipeline in library bekommt drei Bindings – admin (Helm-Deploy), system:image-builder und registry-editor (Push in die interne Registry). Sonst nichts (E1, B12)
  • bei einem kaputten Jenkins-Deploy ist oc auth can-i --as=system:serviceaccount:library:pipeline <verb> <resource> -n library die schnellste Antwort auf „darf die pipeline-SA das“
  • auch die SCC wird über dieselbe Mechanik vergeben: add-scc-to-user bindet die ClusterRole system:openshift:scc:<name> (A7)
ObjektistGeltung
Roleeine Regellisteein Namespace
ClusterRoleeine Regellisteclusterweit – oder als wiederverwendbare Vorlage, per RoleBinding auf einen Namespace begrenzt
RoleBindingordnet ein Subjekt einer Role/ClusterRole zuein Namespace
ClusterRoleBindingordnet ein Subjekt einer ClusterRole zuclusterweit

Eine Regel kreuzt drei Achsen: verbs (get, list, watch, create, update, patch, delete), resources und apiGroups (der leere String meint die Kern-API). Subjekte sind ein User (aus dem IdP), eine Group, oder eine ServiceAccount (system:serviceaccount:<ns>:<name>).

Laptop · Bash
# eine Rolle ansehen:
oc get clusterrole edit -o yaml | head -20

# alle Rollen, die an ein Subjekt gebunden sind:
oc get rolebinding,clusterrolebinding -n library -o wide

2 view / edit / admin live

Leg drei ServiceAccounts an, binde je eine Default-Rolle, und vergleiche live, was jede darf.

Laptop · Bash
oc create sa demo-view -n library
oc create sa demo-edit -n library
oc create sa demo-admin -n library
oc adm policy add-role-to-user view    -z demo-view  -n library
oc adm policy add-role-to-user edit    -z demo-edit  -n library
oc adm policy add-role-to-user admin   -z demo-admin -n library

# Secrets lesen:
oc auth can-i get secrets --as=system:serviceaccount:library:demo-view  -n library   # no
oc auth can-i get secrets --as=system:serviceaccount:library:demo-edit  -n library   # yes
# RBAC selbst aendern:
oc auth can-i create rolebindings --as=system:serviceaccount:library:demo-edit  -n library   # no
oc auth can-i create rolebindings --as=system:serviceaccount:library:demo-admin -n library   # yes
Rolledarfdarf nicht
viewalles lesenSecrets lesen, irgendetwas ändern
editWorkloads ändern, Secrets lesenRBAC ändern, Quota sehen/ändern
adminzusätzlich RBAC im Namespace, ResourceQuotaden Namespace selbst löschen, clusterweite Objekte
cluster-adminalles, überall–

Aggregierte Rollen: admin, edit und view sammeln automatisch jede ClusterRole mit dem Label rbac.authorization.k8s.io/ aggregate-to-edit: "true" – so erweitern Operatoren die Default-Rollen, ohne dass du etwas änderst.

3 Eine Rolle binden

Der Befehl, der die Bibliothek-Pipeline real benutzt.

Laptop · Bash
oc create sa pipeline -n library
oc adm policy add-role-to-user admin -z pipeline -n library
oc adm policy add-cluster-role-to-user system:image-builder -z pipeline -n library
oc adm policy add-cluster-role-to-user registry-editor       -z pipeline -n library

# das Ergebnis nachsehen:
oc describe rolebinding -n library | grep -A3 pipeline
oc get sa/pipeline -n library -o yaml

-z <sa> statt eines Namens bindet eine ServiceAccount im aktuellen (oder mit -n angegebenen) Namespace – kurz für system:serviceaccount:library:pipeline.

4 Prüfen: can-i / who-can

Befehlbeantwortet
oc auth can-i <verb> <resource> --as=<subjekt> -n <ns>darf dieses Subjekt das tun?
oc adm policy who-can <verb> <resource> -n <ns>welche Subjekte dürfen es – alle auf einmal
oc whoami / oc whoami --show-tokenwer bin ich gerade, und mit welchem Token

Erster Griff bei einem kaputten Jenkins-Deploy: oc auth can-i create deployments --as=system:serviceaccount:library:pipeline -n library – sekundenschnell die Antwort, ob es RBAC ist oder etwas anderes.

5 RBAC ist additiv

Es gibt kein deny. jedes Binding gibt Rechte dazu, nie weg.

Laptop · Bash
# Entzug = die Bindung weg, nicht ein Verbot:
oc adm policy remove-role-from-user edit demo-edit -n library
# oder direkt das RoleBinding-Objekt loeschen:
oc delete rolebinding  -n library

Wenn zwei Bindings sich „widersprechen“ (eine erlaubt, eine erlaubt nicht), gewinnt immer die erlaubende – ein zweites, engeres Recht schränkt ein weiteres nie ein. Das ist der wichtigste Unterschied zu Firewall-Regeln oder NetworkPolicy (F2), wo Reihenfolge und deny zählen.

6 Was eine SCC ist

Eine Security Context Constraint ist eine OpenShift-Admission für den securityContext eines Pods – sie begrenzt ihn und setzt offene Felder selbst. Älter als Kubernetes-PodSecurity, und Kern-OpenShift.

Eine SCC ist eine OpenShift-Admission, die beim Erstellen eines Pods prüft, was sein securityContext darf – und Felder, die der Pod offen lässt, selbst setzt (vor allem die UID). Welche SCC ein Pod bekommt, hängt daran, welche SCCs seine ServiceAccount (A6) per RBAC (A5) nutzen darf. Die Vorgabe restricted-v2 verbietet Root – das ist die häufigste Starthürde bei fremden Images.

Die Frage ist nie „darf der Pod Root?“ – sondern „welche SCC lässt Root zu, und darf die ServiceAccount diese SCC nutzen?“ 1 · Pod wird erstellt von Deployment / DC / oc run – mit einer SA der securityContext ist teils leer 2 · welche SCCs? Admission sammelt alle SCCs, die die ServiceAccount (A6) per RBAC (A5) nutzen darf direkt + über Gruppen 3 · sortieren Priorität absteigend, dann Restriktivität aufsteigend (streng vor locker) 4 · erste passende erste SCC, die den Pod zulässt – notfalls mit Mutation: UID, fsGroup, SELinux-Label setzen 5 · festschreiben Name → Pod-Annotation openshift.io/scc wird generiert – nicht anfassen Wenn Schritt 2 sonst nichts findet: jeder authentifizierte Account hat restricted-v2 über die Gruppe system:authenticated – das ist die Vorgabe. SCC prüft den Pod, nicht den Container einzeln – alle Container müssen in dieselbe SCC passen. restricted-v2 – die Vorgabe für alle Pods SCC-Objekt: wichtig zu kennen – vom Cluster verwaltet, eigene SCC nur mit Bedacht runAsUser: MustRunAsRange – zufällige UID, kein Wunsch-UID   aus der Namespace-Annotation openshift.io/sa.scc.uid-range (z. B. 1000700000/10000)   die Annotation entsteht bei oc new-project (A2) privileged: false · allowPrivilegeEscalation: false requiredDropCapabilities: ALL – nur NET_BIND_SERVICE nachrüstbar seccompProfile: RuntimeDefault – v2 verlangt das explizit kein hostPath / hostNetwork / hostPID / hostIPC / hostPort SELinux MustRunAs · fsGroup / supplementalGroups ebenso aus Namespace-Annotationen readOnlyRootFilesystem: nicht erzwungen, aber empfohlen (H2) der Unterschied zu restricted (v1): v2 fordert seccomp + allowPrivilegeEscalation:false ausdrücklich wird seit OCP 4.11 automatisch statt restricted vergeben die eingebauten SCCs – locker ↓ streng privileged alles: Root, host-NS, alle Caps – nur Cluster anyuid UID aus dem Image (auch 0), kein privileged/host hostmount-anyuid + hostPath – Backup / Storage hostnetwork-v2 + hostNetwork / hostPort nonroot-v2 beliebige UID, nur nicht 0 – der häufigste Fix restricted-v2 Vorgabe (siehe links) die Varianten ohne -v2 sind die alten v1-SCCs, für Altlasten Operatoren bringen oft eigene mit (node-exporter usw.) oc get scc listet alle · oc describe scc <name> zeigt die Regeln Reihenfolge = Auswahl in Schritt 3: die strengste passende gewinnt Warum startet mein Container nicht? – die vier Klassiker Image hat USER 0 / schreibt nach /etc /var → Permission denied (EACCES) App bindet Port < 1024 → ohne NET_BIND_SERVICE nicht erlaubt – auf 8080 lauschen Image erwartet festen UID + macht chown → scheitert unter zufälliger UID „container has runAsNonRoot and image will run as root“ → CrashLoopBackOff Fixes in dieser Reihenfolge: 1  Image UID-agnostisch bauen: Dateien gehören Gruppe root, chmod g=u, hoher Port – Red-Hat-UBI ist so 2  Bitnami / Community-Chart: securityContext-Overrides oder global.compatibility.openshift.adaptSecurityContext=auto 3  letzter Ausweg: lockere SCC an genau die eine SA – nonroot-v2 reicht meist, anyuid nur bei festem Nicht-Root-UID, nie privileged als Reflex Bibliothek / cloud-host die 8 Spring-Dienste laufen unverändert unter restricted-v2   (die JVM ist die UID egal, lauscht auf 8080) Keycloak / Postgres / Redis / Kafka (Bitnami): adaptSecurityContext   -Flag oder eine lockere SCC an ihre SA was konkret bricht, wenn eine EJB/WAS-App UID 0 erwartet → H1 ↗ der local-path-provisioner-SA bekommt hostmount-anyuid (SNO-Setup) zuweisen + PodSecurity Admission oc adm policy add-scc-to-user nonroot-v2 -z <sa> -n <ns> → RoleBinding auf ClusterRole system:openshift:scc:<name> – das ist RBAC (A5) ↗ besser als add-scc-to-group: nur die eine SA, nicht alle PodSecurity Admission (Kubernetes) läuft parallel: pod-security.kubernetes.io/enforce: restricted|baseline|privileged OpenShift synct das Namespace-Label meist selbst aus den nutzbaren SCCs prüfen: welche SCC ein Pod bekam → oc get pod <p> -o jsonpath='{.metadata.annotations.openshift\\.io/scc}' Merksatz: nicht „darf der Pod X“ – sondern „welche SCC lässt X zu, und darf die SA (A6) diese SCC nutzen (A5)“ OCP-Unterschied: keiner – SCC ist Kern-OpenShift, auch in OKD. SELinux-Typ container_t auf SCOS / RHCOS.
Kein Root, keine Wunsch-UID – per Vorgabe. Die SCC-Admission wählt für jeden Pod die strengste SCC, die seine ServiceAccount nutzen darf und die den Pod (ggf. nach Mutation der UID) zulässt, und schreibt sie in openshift.io/scc. restricted-v2 gilt für alle: zufällige UID, privileged: false, alle Capabilities weg, kein Host-Zugriff. Startet ein Image nicht, ist fast immer das Image schuld (will Root, fester UID, kleiner Port) – der Fix ist das Image, nicht reflexhaft eine lockere SCC.
  • eine SCC ist eine OpenShift-Admission für den securityContext – sie begrenzt ihn und setzt offene Felder selbst. Älter als das Kubernetes-PodSecurity
  • die Auswahl: die Admission nimmt alle SCCs, die die ServiceAccount (A6) per RBAC (A5) nutzen darf, sortiert nach Priorität absteigend und dann Restriktivität aufsteigend, und nimmt die erste, die passt
  • welche SCC gewonnen hat, steht in der Pod-Annotation openshift.io/scc (sie wird generiert)
  • die Vorgabe restricted-v2 gilt für jeden authentifizierten Account, über die Gruppe system:authenticated
  • restricted-v2 setzt eine zufällige UID (runAsUser: MustRunAsRange), privileged: false, wirft alle Capabilities weg, verlangt seccomp RuntimeDefault und erlaubt keinen Host-Zugriff
  • UID, MCS-Label und fsGroup kommen aus den Namespace-Annotationen openshift.io/sa.scc.*, gesetzt bei oc new-project (A2)
  • die eingebauten SCCs von locker nach streng: privileged, anyuid, hostmount-anyuid, hostnetwork-v2, nonroot-v2, restricted-v2
  • Unterschied restricted (v1) zu restricted-v2: v2 verlangt seccomp und allowPrivilegeEscalation:false ausdrücklich
  • typische Startfehler: das Image hat USER 0 und schreibt ins RootFS, bindet einen Port unter 1024, erwartet einen festen UID und macht chown, oder gerät in den runAsNonRoot-Konflikt
  • Fix in dieser Reihenfolge: erstens das Image UID-agnostisch bauen (UBI ist es schon), zweitens ein Chart-Override oder adaptSecurityContext=auto, drittens als letztes eine lockere SCC an genau die eine SA
  • zuweisen mit oc adm policy add-scc-to-user nonroot-v2 -z <sa> -n <ns> – das erzeugt eine RoleBinding auf die ClusterRole system:openshift:scc:<name> (A5)
  • Bibliothek: die 8 Spring-Dienste passen unter restricted-v2, die Bitnami-Images brauchen global.compatibility.openshift.adaptSecurityContext=auto (Keycloak, Postgres, Redis, Kafka)
  • library-frontend läuft als nginx-unprivileged – trotzdem braucht das Image chmod g+w /etc/nginx/conf.d, weil der Entrypoint die Config zur Laufzeit schreibt und die zufällige UID sonst nicht darf
  • Legacy-Vertiefung: was bei einer EJB- oder WAS-App bricht, die UID 0 erwartet, steht in H1
Auswahldie Admission nimmt alle SCCs, die die ServiceAccount des Pods per RBAC nutzen darf (genau das Binding aus Schritt 3), sortiert nach Priorität absteigend, dann Restriktivität aufsteigend
Trefferdie erste passende SCC gewinnt, steht danach in der Pod-Annotation openshift.io/scc
Vorgaberestricted-v2 gilt für jeden authentifizierten Account, über die Gruppe system:authenticated – ohne ein SA-spezifisches Binding landest du immer hier

restricted-v2 setzt eine zufällige UID (runAsUser: MustRunAsRange), privileged: false, wirft alle Capabilities weg, verlangt Seccomp RuntimeDefault und erlaubt keinen Host-Zugriff. UID, MCS-Label und fsGroup kommen dabei aus den Namespace-Annotationen openshift.io/sa.scc.* (von oc new-project gesetzt).

7 Eine SCC live gewinnen

Ein Image, das USER 0 erwartet, scheitert unter restricted-v2 – dann geben wir ihm die passende SCC.

Laptop · Bash
oc create sa demo-root -n library
oc run rootcheck -n library --image=registry.access.redhat.com/ubi9/ubi-minimal \
  --overrides='{"spec":{"serviceAccountName":"demo-root"}}' -- id
oc get pod rootcheck -n library                       # CreateContainerConfigError / Error
oc get events -n library --field-selector involvedObject.name=rootcheck

# die Pod-Annotation zeigt die gewonnene (Vorgabe-)SCC:
oc get pod rootcheck -n library -o jsonpath='{.metadata.annotations.openshift\.io/scc}{"\n"}'

# jetzt die SA-Bindung geben und neu starten:
oc adm policy add-scc-to-user anyuid -z demo-root -n library
oc delete pod rootcheck -n library --ignore-not-found
oc run rootcheck -n library --image=registry.access.redhat.com/ubi9/ubi-minimal \
  --overrides='{"spec":{"serviceAccountName":"demo-root"}}' -- id
oc get pod rootcheck -n library -o jsonpath='{.metadata.annotations.openshift\.io/scc}{"\n"}'
# jetzt: anyuid

Die eingebauten SCCs, von locker nach streng: privileged, anyuid, hostmount-anyuid, hostnetwork-v2, nonroot-v2, restricted-v2. Unterschied restricted (v1, älter) zu restricted-v2: v2 verlangt Seccomp und allowPrivilegeEscalation: false ausdrücklich.

oc adm policy add-scc-to-user ist selbst nur RBAC – der Befehl erzeugt eine RoleBinding auf die ClusterRole system:openshift:scc:<name>. SCC-Vergabe ist RBAC, nur mit einem speziellen Rollen-Namensschema.

8 Die Fix-Reihenfolge

Ein Image scheitert unter restricted-v2. In dieser Reihenfolge vorgehen – nicht umgekehrt.

1das Image UID-agnostisch bauen – UBI-Images sind es schon, sonst Dateien der Gruppe root gehören lassen und chmod g+w auf die Pfade, in die zur Laufzeit geschrieben wird
2ein Chart-Override prüfen – viele Community-Charts (Bitnami) haben global.compatibility.openshift.adaptSecurityContext=auto eingebaut, genau dafür
3erst als Letztes eine lockere SCC an genau die eine ServiceAccount – nie an system:authenticated, das hält niemanden mehr unter restricted-v2

Typische Startfehler, die auf Schritt 1 zeigen: das Image hat USER 0 und schreibt ins RootFS, bindet einen Port unter 1024, erwartet eine feste UID und macht chown, oder gerät in den runAsNonRoot-Konflikt.

9 Wie die Bibliothek es macht

SA / KonsumentBindings
pipelineadmin in library (Helm-Deploy) + system:image-builder + registry-editor (Registry-Push) – keine SCC-Sonderrechte
die 8 Spring-Dienstelaufen unter der default-SA, ganz normal unter restricted-v2 – kein Override nötig
Bitnami-Infra (Postgres/Redis/Kafka/Keycloak)brauchen keine SCC-Binding, sondern global.compatibility.openshift.adaptSecurityContext=auto im Helm-Wert – der Chart passt sich restricted-v2 selbst an
library-frontend (nginx-unprivileged)läuft ebenfalls unter restricted-v2, das Image braucht trotzdem chmod g+w /etc/nginx/conf.d, weil der Entrypoint die Config zur Laufzeit schreibt

Keiner der Bibliothek-Workloads hat eine SCC-Sonderrechte-Binding – das ist genau der Beweis, dass Schritt 1 und 2 der Fix-Reihenfolge (Image + Chart-Override) fast immer reichen. Nur eine Legacy-App, die UID 0 fest erwartet, bräuchte Schritt 3 (Novaris, H1).

+ Die Kurzfassung

RBACRole/ClusterRole = was, *Binding = wer. Rein additiv, kein deny. Prüfen mit oc auth can-i --as=<subjekt>
SCCwelche SCC ein Pod bekommt, entscheidet dieselbe RBAC-Binding – die Admission nimmt die restriktivste, die die SA per RBAC nutzen darf
Fix-ReihenfolgeImage → Chart-Override → erst zuletzt eine lockere SCC an genau eine SA, nie an system:authenticated
⌂ Cockpit