Kubernetes OIDC bedeutet, dass sich Benutzer über einen externen OpenID-Connect-Anbieter (Identity Provider, kurz IdP) am Cluster anmelden. Der API-Server vertraut dem IdP, prüft die ausgestellten ID-Tokens und leitet daraus Benutzername und Gruppen ab – Kubernetes selbst speichert dabei keine Benutzerkonten.
Konfiguration am API-Server
--oidc-issuer-url=https://login.beispiel.de
--oidc-client-id=kubernetes
--oidc-username-claim=sub
--oidc-groups-claim=groups--oidc-issuer-url: Adresse des IdP, von der der API-Server die Discovery-Daten und den Schlüsselsatz (JWKS) lädt.--oidc-client-id: Client-ID, die der Cluster als Zielgruppe (Audience) der Tokens erwartet.--oidc-username-claim: JWT-Claim, aus dem der Benutzername entsteht – standardmäßigsub.--oidc-groups-claim: optionaler Claim mit den Gruppen des Benutzers.
Login mit kubectl
Kubectl selbst kennt kein Passwort; das Plugin kubelogin (auch kubectl oidc-login) öffnet den Browser, holt beim IdP ein kurzlebiges ID-Token und trägt es in die kubeconfig ein. Da die Tokens schnell ablaufen, verlangt das Plugin bei Bedarf einen Refresh – so bleibt der Zugriff sicher, ohne dass ein Passwort im Klartext liegt.
Weil Kubernetes keine User-Objekte kennt, steuert RBAC die Berechtigungen über den abgeleiteten Benutzernamen und die Gruppen-Claims. Als IdP kommen etwa Keycloak, Dex, Okta oder Azure AD infrage; das Protokoll selbst erklärt der Artikel OpenID Connect. Für Workloads im Cluster sind dagegen TokenRequest-Tokens der übliche Weg.
Praxis-Tipps
- Den IdP nur über HTTPS anbinden und die Issuer-URL exakt angeben.
- Kurze Token-Lebensdauern einstellen und RBAC strikt an Claims ausrichten.
- OIDC eignet sich für Menschen, nicht für Maschinen – dort ServiceAccounts oder CSR-Zertifikate verwenden.
Verwandte Grundlagen: Kubernetes, Impersonation.