Kubernetes-RBAC ist schon eine Grammatik: Roles, Bindings, Verbs, Resources. OpenShift behält die Engine und ergänzt eine zugänglichere Oberfläche. Sagt jemand „leg ein Project für das Payments-Team an“, meint er einen Namespace plus OpenShift-Project-Metadaten — Anzeigename, Beschreibung, optionale Annotations, Default-Quotas und manchmal automatische NetworkPolicy. Sagt jemand „gib edit-Zugriff“, meint er ein ClusterRole-Binding, das OpenShift unter einem Rollennamen dokumentiert, den die meisten Admins kennen.

Kommt man von plain Kubernetes, ist die Überlappung beruhigend — und die Unterschiede zählen. kubectl get ns und oc get projects zeigen verwandte, nicht identische Sichten. oc policy und oc adm policy wrappen RBAC-Operationen, die Platform-Teams täglich nutzen. ServiceAccounts betreiben weiterhin Pods, aber Default-Bindings und Console setzen OpenShift-Konventionen voraus.

Dieser Post deckt Grundlagen ab, die Teams vor dem ersten Produktions-Incident klären sollten: was ein Project ist, was Default-Rollen wirklich erlauben, wie ServiceAccounts passen, wie man mit oc adm policy Zugriff gibt und wie man Berechtigungen testet ohne zu raten.

Project vs Namespace — derselbe Raum, anderes Schild an der Tür

Auf API-Ebene ist ein OpenShift-Project ein Namespace. Jedes Project erzeugt einen Namespace gleichen Namens. Heißt das Project payments-dev, heißt der Namespace payments-dev. Objekte — Deployments, Services, Routes, Secrets — liegen in diesem Namespace wie in upstream Kubernetes.

Was Project zusätzlich liefert, verwaltet OpenShift:

  • Anzeigename und Beschreibung für Menschen in der Web-Console.
  • ProjectRequest-Workflow, damit berechtigte Nutzer innerhalb von Limits selbst provisionieren können.
  • Default-Annotations und Labels durch Plattform oder Templates.
  • Optionale Project-Defaults wie ResourceQuota, LimitRange oder NetworkPolicy bei der Anlage.
  • Sichtbarkeit in oc get projects mit Status und anforderndem Nutzer.

Zwei Sichten vergleichen:

kubectl get namespace payments-dev -o yaml
oc get project payments-dev -o yaml
oc describe project payments-dev

Für portable Automation reicht der Namespace. Für OpenShift-Alltag schaltet oc project payments-dev den Kontext — analog zu kubectl config set-context --current --namespace=..., mit OpenShift-Meldungen, wenn das Project fehlt oder der Zugriff fehlt.

Project anlegen (Recht auf ProjectRequest oder Cluster-Admin nötig):

oc new-project payments-dev --display-name="Payments development"
oc get projects
oc project payments-dev

Löschen (oc delete project payments-dev) entfernt Namespace und namespaced Objekte darin — derselbe destructive Scope wie auf vanilla Kubernetes. „Project“ klingt weicher; die Wirkung nicht.

Wichtiges Modell: Project-Grenzen sind RBAC- und Quota-Grenzen, keine automatische Netzwerk-Isolation. Zwei Projects blockieren Pod-zu-Pod-Traffic nicht magisch, ohne NetworkPolicy oder Platform-Defaults. Zwei Projects stoppen keinen Cluster-Admin davor, beide zu sehen. Project zuerst als Ownership- und Berechtigungs-Scope behandeln.

Default-Rollen — view, edit, admin

OpenShift liefert aggregierte ClusterRoles als view, edit und admin (plus cluster-admin clusterweit). Diese Namen erscheinen in der Console bei „Add user to project“. Unter der Haube sind es ClusterRoleBindings oder RoleBindings auf ClusterRoles wie view, edit und admin.

view ist Read-only auf die meisten namespaced Workloads — Logs und Status ohne Writes, meist ohne Secret-Inhalt. edit deckt Deploy und Ändern von Apps, Services und ConfigMaps ab; oft inklusive Secrets — im Cluster prüfen. admin ergänzt Project-RBAC, Quotas und LimitRanges für Team Leads. cluster-admin ist nur Platform-Scope.

Exakte Regeln ändern sich mit OpenShift-Versionen. Nicht jede Regel aus einem Blogpost auswendig lernen. Inspizieren:

oc describe clusterrole view
oc describe clusterrole edit
oc describe clusterrole admin

Einem Nutzer edit auf ein Project geben:

oc adm policy add-role-to-user edit jane -n payments-dev
oc adm policy add-role-to-user view auditor -n payments-dev
oc adm policy add-role-to-user admin team-lead -n payments-dev

Gruppe aus dem Identity Provider:

oc adm policy add-role-to-group edit payments-developers -n payments-dev

Auflisten, wer Zugriff hat:

oc adm policy who-can get pods -n payments-dev
oc adm policy who-can delete deployments -n payments-dev
oc get rolebinding -n payments-dev
oc describe rolebinding edit-0 -n payments-dev

view ist der Startpunkt für jemanden, der nur laufende Workloads troubleshooten muss. edit ist Standard für Engineers mit Deployments und Routes. admin ist für Membership und Namespace-Policy — nicht jeder Entwickler braucht das.

Typischer Fehler: admin geben, weil „Secrets gelesen werden müssen“. Manchmal enthält edit in der Version schon Secret-Read; manchmal ist eine Custom Role mit get secrets richtig. ClusterRole lesen, dann entscheiden.

Weiterer Fehler: OpenShift admin mit cluster-admin verwechseln. Project-admin konfiguriert nicht sicher den ganzen Cluster. cluster-admin sollte selten sein — Break-Glass und auditierte Automation.

ServiceAccounts in OpenShift Projects

Menschen authentifizieren sich über den Cluster-Identity-Provider. Workloads authentifizieren sich an der Kubernetes-API als ServiceAccounts. Jedes Project bekommt automatisch einen default ServiceAccount. Pods ohne serviceAccountName nutzen ihn.

oc get sa -n payments-dev
oc describe sa default -n payments-dev
oc describe sa builder -n payments-dev

OpenShift legt auch ServiceAccounts wie builder und deployer für Image-Build und Deployment-Flows an. Custom-Apps sollten benannte ServiceAccounts nutzen statt default zu überladen.

Dedizierten ServiceAccount für eine Anwendung anlegen:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api
  namespace: payments-dev

Im Deployment referenzieren:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: payments-dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      serviceAccountName: api
      automountServiceAccountToken: true
      containers:
        - name: api
          image: registry.example.org/payments/api:1.8.0
          ports:
            - containerPort: 8080

Ruft die App nie die Kubernetes-API auf, kann automountServiceAccountToken: false sinnvoll sein — nach Prüfung, dass App und Sidecars keinen Token brauchen. Operatoren und Controller brauchen Tokens oft; einfache HTTP-Services meist nicht.

Einem ServiceAccount Berechtigung im Project per RoleBinding geben:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: api-reads-config
  namespace: payments-dev
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-reads-config
  namespace: payments-dev
subjects:
  - kind: ServiceAccount
    name: api
    namespace: payments-dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: api-reads-config

Oder mit oc:

oc create role api-reads-config \
  --verb=get,list,watch \
  --resource=configmaps \
  -n payments-dev
oc adm policy add-role-to-user api-reads-config \
  system:serviceaccount:payments-dev:api \
  -n payments-dev

SCC-Bindings aus dem Security-Post im Kopf behalten: ServiceAccounts brauchen auch Erlaubnis, eine passende Security Context Constraint zu nutzen. API-RBAC und SCC für Pod-Admission sind getrennte Checks. RoleBinding allein fixt keinen SCC-Denial.

oc adm policy — Grants, Entzüge und Audits

OpenShift-Zugriffsverwaltung läuft oft über oc adm policy statt handgeschriebenes YAML. Admins nutzen es; Entwickler sollten die Befehle kennen, um den richtigen Grant anzufordern und zu prüfen, was existiert.

Rollen an Nutzer oder Gruppen:

oc adm policy add-role-to-user view jane -n payments-dev
oc adm policy add-role-to-group edit payments-developers -n payments-dev
oc adm policy add-cluster-role-to-user cluster-admin break-glass-admin

Rollen entfernen mit oc adm policy remove-role-from-user und remove-role-from-group bei Teamwechsel. Prüfen, wer eine Aktion ausführen darf:

oc adm policy who-can create deployments -n payments-dev
oc adm policy who-can get secrets -n payments-dev
oc adm policy who-can delete pods -n payments-dev

SCC-Helfer ebenfalls hier:

oc adm policy add-scc-to-user restricted -z api -n payments-dev
oc adm policy who-can use scc restricted -n payments-dev

Sagt die Doku „dem SA Pull-Recht geben“, kann das Image-Pull-Secret am ServiceAccount oder Registry-RBAC meinen — verwandt, nicht dasselbe wie project edit. Den Fehler lesen: 403 Forbidden von der Registry fixt man nicht mit add-role-to-user edit.

Berechtigungen praktisch testen

Raten erzeugt zwei Fehlermodi: jemand fehlt Zugriff und fordert „full admin“, oder jemand hat zu viel und niemand merkt es bis zum Audit. OpenShift erbt Kubernetes-Test-Tools; vor und nach Binding-Änderungen nutzen.

Aktuellen Nutzer testen:

oc auth can-i get pods -n payments-dev
oc auth can-i create deployments -n payments-dev
oc auth can-i delete secrets -n payments-dev
oc auth can-i update routes -n payments-dev

Als anderer Nutzer mit Impersonation (Impersonation-Recht nötig):

oc auth can-i get pods -n payments-dev --as=jane
oc auth can-i get secrets -n payments-dev --as=jane
oc auth can-i create deployments -n payments-dev --as=jane

Als ServiceAccount:

oc auth can-i get configmaps -n payments-dev \
  --as=system:serviceaccount:payments-dev:api
oc auth can-i list secrets -n payments-dev \
  --as=system:serviceaccount:payments-dev:api

Mit -v=6 sieht man, welche Regel matchte. Checks nach Onboarding und Rollenänderungen ausführen.

Sagt can-i ja, scheitert die Console trotzdem: Gruppenmitgliedschaft aus LDAP/OIDC, Cache-Verzögerung und ob oc project das richtige Project setzt prüfen. Sagt can-i nein, obwohl ja erwartet: RoleBinding und ClusterRole beschreiben — häufig edit in payments-dev, getestet wird payments-staging.

cluster-admin vermeiden, um Alltagsarbeit zu entblocken; lieber edit plus gezielte Role für das fehlende Verb. ServiceAccounts pro App benennen statt Rechte an default zu binden. Project-Scope ist keine Netzwerk-Isolation — NetworkPolicy ergänzen, wenn das zählt — und API-RBAC sowie SCC sind getrennte Checks.

Abschluss

OpenShift Projects ersetzen Kubernetes-RBAC nicht — sie verpacken Namespaces für Multi-Team-Plattformen. view, edit und admin sind lesbare Defaults, wenn man prüft, was die eigene Version wirklich gewährt. ServiceAccounts tragen Workload-Identität und SCC-Berechtigung. oc adm policy und oc auth can-i machen Zugriff demonstrierbar statt Folklore.

Der Gewinn: weniger Mitternachts-Nachrichten nach „vollem Zugriff“ und weniger Incidents, in denen ein Controller still ein Verb fehlte. Project benennen, Rolle benennen, Binding testen, dann deployen.