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

Kubernetes-Kern und Authentifizierung in OpenShift

Das Modell steht in den Atlas-Diagrammen A1 und A4. Zwei Fragen, die vor allem anderen stehen: welche Teile sind reines Kubernetes und welche sind OpenShift obendrauf – live mit oc api-resources geprüft, nicht behauptet. Und wie kommt ein echter Login zustande, wenn Kubernetes selbst gar keinen Auth-Server mitbringt. EX280-relevant.

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

Voraussetzung: ein Cluster mit oc login als cluster-admin (kubeadmin reicht). Schritt 5 legt einen zweiten Login-Weg an – kubeadmin bleibt danach weiter nutzbar.

1 Kern plus Schicht, kein Fork

OpenShift ist unverändertes Kubernetes, darauf eine feste Schicht aus Operatoren und CRDs.

KernAPI-Server, etcd, Scheduler, Controller-Manager, kubelet, CRI-O, OVN-CNI – identisch zu jedem Kubernetes
Schichtlauter Operatoren obendrauf: Router/Route, OAuth-Server, SCC, interne Registry, Web-Konsole, OLM/OperatorHub, Monitoring, BuildConfig/ImageStream/S2I
Node-OSSCOS oder RHCOS – unveränderlich, vom MCO verwaltet (G4), kein eigenes Ubuntu/Debian

Der CVO und rund 30 ClusterOperatoren (G6) verwalten den Cluster als eine versionierte Einheit. OKD ist die quelloffene Variante (SCOS/Fedora CoreOS, kostenlos, community-operators, Dummy-Pull-Secret), OCP das Red-Hat-Produkt (RHCOS, Subscription je Core, SLA, echtes Pull-Secret von console.redhat.com). Kern und Schicht sind praktisch gleich – im Job meist OCP, die Konzepte gelten eins zu eins.

2 Die OpenShift-Schicht live trennen

Nicht behaupten, nachsehen: welche API-Gruppen kommen von Kubernetes, welche von OpenShift?

Laptop · Bash
# alle API-Gruppen dieses Clusters:
oc api-resources -o wide | awk '{print $NF}' | grep -oE '[a-z0-9.-]+\.[a-z]+$' | sort -u | head -40

# gezielt die OpenShift-eigenen Gruppen herausfiltern:
oc api-resources | grep '\.openshift\.io'

# eine davon im Detail:
oc explain route.spec.tls
oc explain route.spec.tls.termination

# zum Vergleich: dieselbe Frage auf einem reinen Kubernetes gestellt
# (falls ein k3s/kind-Kontext existiert, sonst diesen Schritt auslassen):
# KUBECONFIG=~/.kube/biblio.yaml kubectl api-resources | grep '\.openshift\.io'
# -> leer, kein Treffer

oc ist ein Superset von kubectl – dieselbe Binary redet mit jedem Kubernetes, die OpenShift-Extras (oc adm, oc new-app, oc debug, oc rsh, oc rollout als Abkürzungen) schalten sich frei, sobald es OpenShift ist. Die OpenShift-Objekte laufen über einen aggregierten API-Server – gleicher Port 6443, andere Pfade, für dich unsichtbar.

3 Was portabel bleibt, was nicht

Die Konsequenz aus Schritt 2 für einen Helm-Chart oder ein Manifest.

Objektläuft auf reinem Kubernetes?
Deployment, Service, ConfigMap, Secret, Ingressja, unverändert – reines Kubernetes
Routenein, kennt nur OpenShift – wer portabel bleiben will, schreibt ein Ingress (F3)
BuildConfig, ImageStreamnein – ein Chart mit ImageStreamTag-Referenzen läuft auf k3s nicht (C1)
DeploymentConfig, SecurityContextConstraintsnein – OpenShift-eigen (B2, A7)

Die Web-Konsole hat zwei Perspektiven: Administrator für den Cluster, Developer für ein einzelnes Project – beide schreiben nur dieselben Objekte, die auch oc schreibt.

4 Das OAuth-Modell

OpenShift bringt einen eigenen OAuth-Server mit – Kubernetes hat keinen.

bis zum ersten Loginkein User in etcd – danach entstehen ein User, eine Identity und das Mapping dazwischen
IdP-TypenHTPasswd, LDAP, GitHub, GitLab, Google, OIDC, Keystone, RequestHeader – konfiguriert in genau einem Objekt, oauth/cluster
Tokenzwei Arten: OAuthAccessToken für die Nutzer-Session, ein ServiceAccount-Token für einen Pod (A6)

kubeadmin ist temporär – ein Secret in kube-system, gelöscht sobald ein eigener IdP steht. system:admin ist ein x509- Client-Zertifikat in der Install-kubeconfig, ganz ohne OAuth. Rechte kommen nicht vom IdP – erst oc adm policy bindet Rollen an einen User oder eine Gruppe (A5).

5 Einen HTPasswd-IdP live anlegen

Der einfachste IdP – ein Secret mit einer htpasswd-Datei.

Laptop · Bash
htpasswd -c -B -b users.htpasswd demo-user 'ein-langes-testpasswort'

oc create secret generic htpass-secret -n openshift-config \
  --from-file=htpasswd=users.htpasswd

oc patch oauth cluster --type=merge -p '{
  "spec": {
    "identityProviders": [{
      "name": "demo-htpasswd",
      "mappingMethod": "claim",
      "type": "HTPasswd",
      "htpasswd": { "fileData": { "name": "htpass-secret" } }
    }]
  }
}'

# der OAuth-Server-Operator rollt sich selbst neu - kurz abwarten:
oc get co authentication -w

# anmelden mit dem neuen IdP:
oc login -u demo-user -p 'ein-langes-testpasswort'
oc whoami
oc whoami --show-console

SNO nur übers TailnetEin oc login von einem Rechner ohne Tailscale und ohne den hosts-Eintrag scheitert am Zertifikat, nicht am Passwort (Diagramm 03).

6 Rechte binden, Gruppen pflegen

demo-user existiert jetzt, darf aber noch nichts.

Laptop · Bash
# zurueck als Admin einloggen, um Rechte zu vergeben:
oc login -u kubeadmin -p $(cat cfg/auth/kubeadmin-password)

oc auth can-i get pods --as=demo-user -n library   # no
oc adm policy add-role-to-user view demo-user -n library
oc auth can-i get pods --as=demo-user -n library   # yes

# Gruppen entstehen nicht automatisch - von Hand:
oc adm groups new demo-team demo-user
oc adm policy add-role-to-group edit demo-team -n library

# per LDAP kaeme das ueber einen Sync statt von Hand:
# oc adm groups sync --sync-config=ldap-sync.yaml --confirm

Token weg oder abgelaufen: oc whoami sagt Unauthorized – neu oc login, oder oc whoami -t zeigt das aktuelle Token.

7 Typische Fallen

Symptommeist
ein Helm-Chart läuft auf k3s nichter referenziert eine Route oder einen ImageStream – beides OpenShift-eigen
oc login scheitert mit Zertifikatsfehlerkein Tailscale/hosts-Eintrag auf der SNO – nicht das Passwort
neuer User darf trotz Login nichtsIdP-Login gibt Identität, nicht Rechte – oc adm policy fehlt noch
Gruppen-Mitgliedschaft wirkt nichtRolle ist an die falsche Gruppe oder den falschen Namespace gebunden
kubeadmin geht nach IdP-Wechsel nicht mehrerwartet, sobald das Secret in kube-system gelöscht wurde

8 Wie das Projekt es macht

Im Projekt ist kein eigener IdP eingerichtet – der Zugang läuft komplett über oc login -u kubeadmin -p $(cat cfg/auth/kubeadmin-password), dasselbe für CRC. Für ein Bewerbungsgespräch wäre HTPasswd (Schritt 5) der erste Ausbau – genau das Muster, das diese Anleitung durchspielt. Dieser Atlas läuft auf OKD (SNO auf Hetzner), OCP-Unterschiede stehen wo nötig inline.

+ Die Kurzfassung

Kern + Schichtreines Kubernetes plus eine feste Operator-Schicht – oc api-resources zeigt live, was dazukommt
PortabelDeployment/Service/ConfigMap ja, Route/BuildConfig/ImageStream/DC/SCC nein
AuthLogin gibt Identität, nicht Rechte – oc adm policy bindet die Rolle danach separat