Kubernetes-Kern und Authentifizierung in OpenShift

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.

Kurz: der Kubernetes-Kern bleibt unverändert. Alles, was OpenShift ausmacht, läuft als Operatoren (Controller, die eine Fähigkeit automatisieren) und zusätzliche API-Objekte darauf. OKD (die quelloffene Variante) und OCP (das kommerzielle Produkt von Red Hat) sind zwei Auslieferungen derselben Schicht.

OpenShift ist Kubernetes plus eine feste Schicht Operatoren. Der Kern – API-Server, etcd, Scheduler, kubelet – ist unverändertes Kubernetes. Darauf sitzen Router, OAuth, SCC, Registry, Konsole, OLM, das Monitoring und die Build-Kette, alle als Operatoren verwaltet. OKD und OCP liefern dieselbe Schicht – sie unterscheiden sich in Node-OS, Kosten, Support und den Operator-Katalogen, nicht in den Konzepten.

OpenShift ist unverändertes Kubernetes, darauf eine feste Schicht aus Operatoren und CRDs, kein Fork
der Kern bleibt gleich: API-Server, etcd, Scheduler, Controller-Manager, kubelet, CRI-O, OVN-CNI
die OpenShift-Schicht sind lauter Operatoren: Router und Route, OAuth-Server, SCC, interne Registry, Web-Konsole, OLM und OperatorHub, Monitoring, dazu BuildConfig, ImageStream und S2I
der CVO und rund 30 ClusterOperatoren verwalten den Cluster als eine versionierte Einheit und aktualisieren ihn (G5, G6)
ebenfalls Teil der Schicht: Project mit Quota-Vorgaben, OVN-Kubernetes, der DNS- und der Ingress-Operator
das Node-Betriebssystem ist SCOS oder RHCOS, unveränderlich und vom MCO verwaltet (G4), kein eigenes Ubuntu oder Debian
deine Anwendung (Deployment, Service, Ingress, ConfigMap) läuft unverändert
OKD ist die quelloffene Variante: SCOS oder Fedora CoreOS, kostenlos, Community-Support, community-operators, Dummy-Pull-Secret
OCP ist das Produkt von Red Hat: RHCOS, Subscription je Core, SLA, dazu redhat- und certified-operators, echtes Pull-Secret von console.redhat.com
Kern und Schicht sind praktisch gleich – im Job meist OCP, die Konzepte gelten eins zu eins. Dieser Atlas läuft auf OKD (SNO auf Hetzner), OCP-Unterschiede stehen inline
oc ist ein Superset von kubectl – dieselbe Binary redet mit jedem Kubernetes (auch dem k3s aus biblio.yaml), die OpenShift-Extras schalten sich frei, sobald es OpenShift ist
oc adm bündelt Admin-Aufgaben, oc new-app, oc debug, oc rsh und oc rollout sind Abkürzungen
die OpenShift-Objekte kommen über einen aggregierten API-Server, gleicher Port 6443, andere Pfade – oc api-resources und oc explain route zeigen, was dieser Cluster kann
Folge: ein Helm-Chart mit reinen Kubernetes-Objekten läuft auf beiden. Eine Route kennt nur OpenShift – wer portabel bleiben will, schreibt stattdessen ein Ingress
die Web-Konsole hat zwei Perspektiven: Administrator für den Cluster, Developer für ein einzelnes Project

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.

Objekt	läuft auf reinem Kubernetes?
`Deployment`, `Service`, `ConfigMap`, `Secret`, `Ingress`	ja, unverändert – reines Kubernetes
`Route`	nein, kennt nur OpenShift – wer portabel bleiben will, schreibt ein `Ingress` (F3)
`BuildConfig`, `ImageStream`	nein – ein Chart mit ImageStreamTag-Referenzen läuft auf k3s nicht (C1)
`DeploymentConfig`, `SecurityContextConstraints`	nein – 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.

Kubernetes hat keinen Benutzerspeicher. OpenShift bringt einen eigenen OAuth-Server mit, der gegen einen konfigurierten Identity Provider prüft und ein Bearer-Token ausstellt. kubeadmin und system:admin sind zwei Wege daran vorbei.

Ein Server für die Frage „wer bist du“. oc login tauscht Benutzer und Passwort beim OAuth-Server gegen ein Bearer-Token, das dann in der kubeconfig steht und bei jeder Anfrage mitgeht. Welchen Speicher der OAuth-Server befragt, steht in genau einem Objekt (oauth/cluster). kubeadmin ist der Notzugang ohne IdP, system:admin das Zertifikat, das auch dann noch geht, wenn der Auth-Stack streikt.

OpenShift bringt einen eigenen OAuth-Server mit, Kubernetes hat keinen
bis zum ersten Login gibt es keinen User in etcd – danach entstehen ein User, eine Identity und das Mapping dazwischen
IdP-Typen: HTPasswd, LDAP, GitHub, GitLab, Google, OIDC, Keystone, RequestHeader – konfiguriert in genau einem Objekt, oauth/cluster
HTPasswd ist ein Secret mit einer htpasswd-Datei, referenziert in oauth/cluster
oc login -u <user> --server=https://api.<cluster>:6443 holt ein Bearer-Token vom OAuth-Server – das Passwort wird interaktiv eingegeben, das Token läuft nach einer Weile ab und steht dann in der kubeconfig
kubeadmin ist temporär – ein Secret in kube-system, das man nach dem eigenen IdP löscht
system:admin ist ein x509-Client-Zertifikat in der Install-kubeconfig, ganz ohne OAuth
zwei Token-Arten: ein OAuthAccessToken für die Nutzer-Session, ein ServiceAccount-Token für einen Pod (A6)
Gruppen kommen nicht automatisch – per LDAP-Sync (oc adm groups sync) oder von Hand (oc adm groups new <name>)
Rechte kommen nicht vom IdP – erst oc adm policy bindet Rollen an einen User oder eine Gruppe (A5)
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 der erste Ausbau
die SNO-API ist nur übers Tailnet erreichbar – oc login von einem Rechner ohne Tailscale und ohne den hosts-Eintrag scheitert am Zertifikat, nicht am Passwort (Diagramm 03)
Token weg oder abgelaufen: oc whoami sagt Unauthorized – neu oc login, oder oc whoami -t zeigt das aktuelle Token

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

Symptom	meist
ein Helm-Chart läuft auf k3s nicht	er referenziert eine `Route` oder einen `ImageStream` – beides OpenShift-eigen
`oc login` scheitert mit Zertifikatsfehler	kein Tailscale/`hosts`-Eintrag auf der SNO – nicht das Passwort
neuer User darf trotz Login nichts	IdP-Login gibt Identität, nicht Rechte – `oc adm policy` fehlt noch
Gruppen-Mitgliedschaft wirkt nicht	Rolle ist an die falsche Gruppe oder den falschen Namespace gebunden
`kubeadmin` geht nach IdP-Wechsel nicht mehr	erwartet, 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