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.
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?
# 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.
oauth/clusterOAuthAccessToken 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.
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.
# 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
oc api-resources zeigt live, was dazukommtoc adm policy bindet die Rolle danach separat