Ein auf dem CNCF-Blog veröffentlichter Beitrag empfiehlt, die Zugriffskontrolle für Kubernetes-Cluster als Bestandteil der grundlegenden Einrichtung zu behandeln, neben Netzwerken und Speicher – insbesondere in selbst gehosteten Umgebungen, die normalerweise keine sofort einsatzbereite IAM- oder SSO-Integration wie verwaltete Kubernetes-Dienste bieten. Der zentrale Gedanke besteht darin, einen OIDC-kompatiblen Identitätsanbieter wie Keycloak mit einem als öffentlicher Client registrierten Client zu verwenden, der PKCE nutzt, statt eines vertraulichen Clients mit einem gemeinsam genutzten Schlüssel.
In vielen lokalen Clustern basiert der Zugriff auf einem statischen Clientzertifikat oder einem langlebigen Token, das einmalig ausgestellt wird. Diese Daten bleiben gültig, selbst nachdem ein Mitarbeiter das Unternehmen verlassen hat, seine Rolle geändert wurde oder er das Gerät mit diesen Daten verloren hat. Außerdem erfordert der Widerruf des Zugriffs, jede Kopie der Zertifikatsdatei oder des Tokens zu finden. Wenn die Zahl der Personen steigt und sich die Berechtigungsstufen unterscheiden, wird die Verteilung und Verwaltung der Dateien zu einer fortlaufenden betrieblichen Aufgabe.
Was ändert sich mit OIDC?
Statt die Berechtigung an eine Zertifikatsdatei zu binden, wird sie mit dem Benutzerkonto und seiner Gruppenmitgliedschaft beim Identitätsanbieter verknüpft. Die Integration besteht aus drei miteinander verbundenen Komponenten: dem Tool kubectl mit dem Plug-in kubelogin oder kubectl oidc-login, dem Identitätsanbieter, der den Benutzer authentifiziert und das ID-Token ausstellt, sowie dem kube-apiserver, der das Token überprüft, den Benutzernamen und die Gruppen extrahiert und anschließend Kubernetes RBAC die Bestimmung der zulässigen Vorgänge überlässt.
kubectl verbindet sich nicht zuerst mit dem API-Server, um die Anmeldung zu starten. Das Exec-Credential-Plug-in startet die Anmeldung über den Browser beim Identitätsanbieter und gibt anschließend das ID-Token an kubectl zurück, damit es als Bearer-Credential gesendet wird. Der API-Server überprüft das Token anhand der öffentlichen Signaturschlüssel des Identitätsanbieters. Laut dem Beitrag benötigt der Server keine dauerhafte Verbindung zum Identitätsanbieter, abgesehen vom Abrufen dieser Schlüssel bei Bedarf.
Warum sollte der Client öffentlich sein?
Ein vertraulicher Client verwendet einen Schlüssel, der den Einstellungen des kubelogin-Plug-ins hinzugefügt und auf jedes Gerät verteilt wird, das Zugriff benötigt. Der Beitrag vertritt die Ansicht, dass ein Schlüssel, der an alle Clients verteilt werden muss, faktisch kein Geheimnis mehr ist, sondern eine gemeinsam genutzte statische Berechtigung, die sich nur schwer rotieren lässt. Für Befehlszeilen- und native Anwendungen ist daher ein öffentlicher Client ohne Geheimnis mit aktiviertem PKCE – Proof Key for Code Exchange – die geeignetere Wahl.
Der Client erzeugt lokal einen Zufallswert und sendet in der anfänglichen Anmeldeanfrage einen Hash davon. Beim Austausch des Autorisierungscodes gegen ein Zugriffstoken weist er anschließend den Besitz des ursprünglichen Werts nach. Daher kann jemand, der nur den Autorisierungscode abfängt, den Vorgang nicht abschließen. Die im Beitrag genannten Keycloak-Einstellungen empfehlen, die Clientauthentifizierung zu deaktivieren, den Standardablauf zu aktivieren, direkte Zugriffsgewährungen zu deaktivieren und PKCE mit S256 zu erzwingen. Außerdem sollen Weiterleitungsadressen und Web-Ursprünge auf Loopback-Adressen wie 127.0.0.1 und localhost beschränkt werden.
Grundlegende Einrichtungsschritte
- Den Gruppenmitgliedschafts-Mapper zum Client-Bereich in Keycloak hinzufügen, sodass im ID-Token ein Claim mit dem Namen groups erscheint.
- Den kube-apiserver mit Flags wie oidc-issuer-url, oidc-client-id, oidc-username-claim und oidc-groups-claim konfigurieren.
- oidc-ca-file hinzufügen, wenn der Identitätsanbieter ein Zertifikat verwendet, das nicht von einer öffentlichen vertrauenswürdigen Stelle signiert wurde, damit der API-Server die TLS-Verbindung überprüfen und die Signaturschlüssel abrufen kann.
- Die kubeconfig so anpassen, dass sie über kubectl oidc-login einen Exec-Credential-Eintrag verwendet, statt Zertifikate oder statische Token einzubetten – ohne ein Geheimnisfeld hinzuzufügen.
- Gruppen des Identitätsanbieters mit Kubernetes-RBAC-Rollen verknüpfen, beispielsweise die Gruppe platform-viewer mit der Rolle view.
Praktische Auswirkungen und Grenzen
Nach dieser Verknüpfung werden Zugriffsänderungen innerhalb des Identitätsanbieters vorgenommen: Ein Benutzer wird einer Gruppe hinzugefügt oder aus ihr entfernt, anstatt den Cluster zu ändern oder die kubeconfig neu zu verteilen. Das nächste vom Benutzer ausgestellte Token enthält die neue Gruppenmitgliedschaft, sodass die damit verknüpfte RBAC-Regel angewendet wird. Der Beitrag erklärt, dass die erste Anmeldung den Browser öffnet, während kubelogin das zwischengespeicherte Token bis zu seinem Ablauf wiederverwendet und anschließend das Aktualisierungstoken ohne einen neuen Browserdurchlauf nutzt. Die tatsächliche Identität und die Gruppen können mit dem Befehl kubectl auth whoami überprüft werden.
Das bedeutet nicht, dass die Integration ohne betriebliche Anforderungen auskommt. Der Gruppen-Claim muss präzise konfiguriert, das Zertifikat des Identitätsanbieters überprüft, die Weiterleitungsadressen müssen eingeschränkt und es muss sichergestellt werden, dass die RBAC-Rollen die erforderlichen Berechtigungen abbilden. Außerdem liefert der Beitrag keine unabhängigen Messwerte zur Einrichtungsdauer oder zu den Betriebskosten, sondern schätzt, dass die Vorbereitung innerhalb eines einzigen Arbeitstags erfolgen kann und keine vollständige Migration der Plattform erfordert.
Der wichtigste Sicherheits- und Verwaltungsvorteil besteht darin, dass Kubernetes-Protokolle mit der tatsächlichen Benutzeridentität verknüpft werden. Protokolle, die auf einem allgemeinen Konto wie cluster-admin basieren, unterscheiden nicht zwischen den Ausführenden der Anfragen, während jede über OIDC gesendete Anfrage den Benutzernamen und die zugehörigen Gruppen enthält. Diese Einordnung ist eine redaktionelle Schlussfolgerung aus den Details des Beitrags: Die Verbesserung betrifft nicht nur die Art der Anmeldung, sondern auch die Möglichkeit, Handlungen ihren Urhebern zuzuordnen, während die Vergabe und der Entzug von Berechtigungen zu einem zentralen Identitätsprozess werden, statt nach verteilten Zugangsdaten suchen zu müssen.