Auf dieser Seite wird gezeigt, wie Sie mit OpenID Connect (OIDC) und Active Directory Federated Services (ADFS) die Authentifizierung für GKE On-Prem-Nutzercluster konfigurieren.
Eine Übersicht über den Authentifizierungsablauf finden Sie unter Authentifizierung.
Übersicht
GKE On-Prem unterstützt OpenID Connect (OIDC) als Authentifizierungsmechanismus für die Interaktion mit dem Kubernetes API-Server eines Nutzerclusters. GKE On-Prem liefert das Kubectl-Plug-in für OIDC, ein kubectl-Plug-in, mit dem die Authentifizierung für Clusternutzer automatisch aktiviert wird.
In dieser Übung verwenden Sie eine Reihe von ADFS-Verwaltungsassistenten, um eine Beziehung zwischen dem kubectl
-Befehlszeilentool, Ihrem ADFS-Server und Ihrer AD-Mitarbeiterdatenbank zu konfigurieren.
Hinweis
In diesem Thema wird davon ausgegangen, dass Sie mit OAuth 2.0 und OpenID Connect vertraut sind. In diesem Thema wird davon ausgegangen, dass Sie mit OpenID-Bereichen und Anforderungen vertraut sind.
Dieses Thema gilt für Unternehmen mit folgender Infrastruktur:
- Das Unternehmen verwendet Active Directory (AD) für seine Mitarbeiterdatenbank.
- Das Unternehmen betreibt einen Active Directory Federation Services-Server (ADFS).
- Der ADFS-Server fungiert als OpenID-Anbieter.
Kubectl-Plug-in für OIDC herunterladen
Laden Sie das Plug-in herunter und legen Sie Zugriffsberechtigungen fest:
Linux
gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/linux_amd64/kubectl-oidc . chmod +x kubectl-oidc
Windows
gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/windows_amd64/kubectl-oidc .
macOS
gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/darwin_amd64/kubectl-oidc . chmod +x kubectl-oidc
Plug-in installieren
Installieren Sie das Plug-in durch Verschieben der ausführbaren Datei an einen beliebigen Speicherort unter Ihrem PATH
. Die ausführbare Datei muss den Namen kubectl-oidc
haben. Weitere Informationen finden Sie unter kubectl-Plug-ins installieren.
Weiterleitungs-URI erstellen
Sie müssen einen Weiterleitungs-URI angeben, mit dem der OpenID-Anbieter ID-Tokens zurückgeben kann. Die Tokens gehen an das Kubectl-Plug-in für OIDC, das auf dem lokalen Computer jedes Mitarbeiters ausgeführt wird und einen Port Ihrer Wahl überwacht. Wählen Sie eine Portnummer größer als 1024, die für diesen Zweck geeignet ist. Dann lautet der Weiterleitungs-URI:
http://localhost:[PORT]/callback
Dabei ist [PORT] Ihre Portnummer.
ADFS konfigurieren
In den folgenden Abschnitten wird erläutert, wie ADFS für GKE On-Prem konfiguriert wird.
Weiterleitungs-URI festlegen
Öffnen Sie das ADFS-Verwaltungsfenster.
Wählen Sie Anwendungsgruppen, Aktionen und Anwendungsgruppe hinzufügen aus.
Wählen Sie Server Application aus. Geben Sie einen Namen und eine Beschreibung ein. Klicken Sie auf Weiter.
Geben Sie den Weiterleitungs-URI ein. Sie erhalten eine Client-ID. So identifiziert der OpenID-Anbieter die Anwendung
kubectl
. Speichern Sie die Client-ID für eine spätere Verwendung.Wählen Sie Generate a shared secret aus. Die
kubectl
-Anwendung verwendet dieses Secret zur Authentifizierung beim OpenID-Anbieter. Speichern Sie das Secret für eine spätere Verwendung.
Sicherheitsgruppen konfigurieren (optional)
Wählen Sie in der ADFS-Verwaltung Vertrauensstellungen der vertrauenden Seite und dann Vertrauensstellung der vertrauenden Seite hinzufügen aus.
Wählen Sie Ansprüche unterstützend aus und klicken Sie auf Starten.
Wählen Sie Enter data about relying party manually aus.
Geben Sie einen Anzeigenamen ein.
Überspringen Sie die beiden nächsten Schritte.
Geben Sie eine Vertrauensstellungs-ID für die vertrauende Seite ein. Vorschlag:
token-groups-claim
.Wählen Sie für Access control policy die Option Permit everyone aus. Das bedeutet, dass alle Mitarbeiter ihre Sicherheitsgruppeninformationen mit
kubectl oidc
teilen.Klicken Sie auf Finish (Beenden).
LDAP-Attribute zu Anspruchsnamen zuordnen
Wählen Sie in der ADFS-Verwaltung Vertrauensstellungen der vertrauenden Seite und dann Anspruchsausstellungsrichtlinie bearbeiten aus.
Wählen Sie LDAP-Attribute als Ansprüche senden aus und klicken Sie auf Weiter.
Geben Sie für Claim rule name den Wert
groups
ein.Wählen Sie für Attributspeicher die Option Active Directory aus.
Wählen Sie in der Tabelle für LDAP-Attribut die Option Tokengruppen – Qualifizierte Namen aus. Wählen Sie unter Typ des ausgehenden Anspruchs die Option Gruppen aus.
Klicken Sie auf Beenden und dann auf Übernehmen.
kubectl mit ADFS registrieren
Öffnen Sie im Administratormodus ein PowerShell-Fenster und geben Sie folgenden Befehl ein:
Grant-AdfsApplicationPermission ` -ClientRoleIdentifier "[CLIENT_ID]" ` -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] ` -ScopeName "allatclaims", "openid"
Dabei gilt:
[CLIENT_ID] ist die
kubectl
-Client-ID, die Sie zuvor abgerufen haben.[SERVER_ROLE_IDENTIFIER] ist die Anforderungs-ID, die Sie zuvor eingegeben haben. Denken Sie daran, dass als ID
token-groups-claim
vorgeschlagen wurde.
Die oidc
-Spezifikation in die GKE On-Prem-Konfigurationsdatei einsetzen
Während der Installation generieren Sie mithilfe von gkectl create-config
eine GKE On-Prem-Konfigurationsdatei. Die Konfiguration enthält die folgende oidc
-Spezifikation. Sie befüllen "oidc" mit Werten, die für Ihren Anbieter spezifisch sind:
oidc: issuerurl: kubectlredirecturl: clientid: clientsecret: username: usernameprefix: group: groupprefix: scopes: extraparams: usehttpproxy: capath:
issuerurl
: Die URL Ihres OpenID-Anbieters, beispielsweisehttps://example.com/adfs
. Clientanwendungen wie das Kubectl-Plug-in für OIDC senden Autorisierungsanfragen an diese URL. Der Kubernetes API-Server verwendet diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens festzustellen. Es muss HTTPS verwendet werden. Das ist ein Pflichtfeld.kubectlredirecturl
: localhost-Weiterleitungs-URL für das Kubectl-Plug-in für OIDC. Sie müssen die Weiterleitungs-URL bei Ihrem OpenID-Provider für die Verwendung durch die diesem Cluster zugewiesene Client-ID registrieren. Das ist ein Pflichtfeld.clientid
: ID für die Clientanwendung, z. B. das Kubectl-Plug-in für OIDC, die Authentifizierungsanfragen an den OpenID-Anbieter sendet. Das ist ein Pflichtfeld.clientsecret
: Secret für die Client-Anwendung. Das ist ein Pflichtfeld.usehttpproxy
: Wählen Sie aus, ob ein Reverse-Proxy im Cluster bereitgestellt werden soll, um Connect-Agent Zugriff auf den lokalen OIDC-Anbieter zur Authentifizierung von Nutzern zu gewähren. Der Wert muss ein String sein:"true"
oder"false"
. Das ist ein Pflichtfeld.username
: JWT-Anspruch zur Verwendung als Nutzername. Der Standardwert istsub
. Dies ist eine eindeutige ID des Endnutzers. Sie können je nach OIDC-Anbieter andere Ansprüche wieemail
odername
auswählen. Allerdings wird anderen Ansprüchen alsemail
die Aussteller-URL vorangestellt, um Namenskonflikte mit anderen Plug-ins zu vermeiden.usernameprefix
: Präfix, das Nutzernamensanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn dieses Flag nicht angegeben wird undusername
ein anderer Wert als "email" ist, wird standardmäßig das Präfixissueruri#
verwendet. Mit dem Wert-
können Sie das gesamte Präfix deaktivieren.group
: JWT-Anspruch, der als Gruppe des Nutzers verwendet werden soll. Wenn der Anspruch vorhanden ist, muss dies ein Array von Strings sein.groupprefix
: Präfix, das Gruppenansprüchen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Es sind beispielsweise die Gruppefoobar
und das Präfixgid-
gid-foobar
gegeben.scopes
: Zusätzliche Bereiche, die als durch Kommentare getrennte Liste an den OpenID-Anbieter gesendet werden.extraparams
: Zusätzliche Schlüssel/Wert-Parameter, die an den OpenID-Anbieter gesendet werden.capath
: Pfad zum Zertifikat der Zertifizierungsstelle, die das Webzertifikat Ihres Identitätsanbieters signiert hat.GKE On-Prem-Cluster verwenden TLS, um die Kommunikation zwischen ihren Komponenten zu sichern. Damit Kubernetes bei der Installation und beim Knoten-Bootstrapping automatisch Clientzertifikate erzeugen kann, muss GKE On-Prem mit einer Zertifizierungsstelle installiert werden.
Standardmäßig erstellt GKE On-Prem während der Installation eine neue Zertifizierungsstelle, die TLS-Zertifikate generiert. Die Zertifizierungsstelle und die generierten Zertifikate werden lokal im Admin-Cluster gespeichert.
Beispiel: Gruppe authentifizieren und autorisieren
Viele Anbieter codieren Eigenschaften zur Identifizierung von Nutzern wie E-Mail-Adressen und Nutzer-IDs in einem Token. Diese Attribute bringen jedoch implizite Risiken für Authentifizierungsrichtlinien mit sich:
- Nutzer-IDs können das Lesen und Prüfen von Richtlinien erschweren.
- E-Mail-Adressen können sowohl ein Verfügbarkeitsrisiko (wenn ein Nutzer seine primäre E-Mail-Adresse ändert) als auch ein Sicherheitsrisiko (wenn eine E-Mail neu zugewiesen werden kann) bewirken.
Deshalb empfiehlt es sich, Gruppenrichtlinien zu verwenden, da die GID sowohl nichtflüchtig als auch einfacher zu überwachen sein kann.
Angenommen, Ihr Anbieter erstellt OpenID-Tokens, die die folgenden Felder enthalten:
{ 'iss': 'https://server.example.com' 'sub': 'u98523-4509823' 'groupList: ['developers@example.corp', 'us-east1-cluster-admins@example.corp'] ... }Bei diesem Tokenformat würde dann die
oidc
-Spezifikation Ihrer Konfigurationsdatei so aussehen:
issueruri: 'https://server.example.com' username: 'sub' usernameprefix: 'uid-' group: 'groupList' groupprefix: 'gid-' ...
Nachdem Sie den Nutzercluster erstellt haben, können Sie den authentifizierten Nutzern mithilfe der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) einen autorisierten Zugriff gewähren. Sie können beispielsweise eine ClusterRole erstellen, die ihren Nutzern Lesezugriff auf die Secrets des Clusters gewährt, und eine ClusterRoleBinding-Ressource erstellen, um die Rolle an die authentifizierte Gruppe zu binden:
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secrets-admins subjects: # Allows anyone in the "us-east1-cluster-admins" group to # read Secrets in any namespace within this cluster. - kind: Group name: gid-us-east1-cluster-admins # Name is case sensitive apiGroup: rbac.authorization.k8s.io # Allows this specific user to read Secrets in any # namespace within this cluster - kind: User name: uid-u98523-4509823 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Serverzertifikat der Zertifizierungsstelle erstellen
Die kubeconfig-Datei Ihres Nutzerclusters speichert die CA-Daten des Hosts im Feld certificate-authority-data
. Sie müssen diesen Wert decodieren und in einer lokalen Datei wie server-ca-cert
speichern:
cat [USER_CLUSTER_KUBECONFIG] | grep certificate-authority-data | awk '{ print $2}' | base64 --decode > server-ca-cert
Die Konfigurationsdatei für die Clientauthentifizierung generieren
Nachdem Sie den Nutzercluster für OpenID konfiguriert und erstellt haben, kann sich ein Nutzer im Cluster anmelden, indem er eine Konfigurationsdatei für die Clientauthentifizierung an kubectl oidc login
übergibt. Sie generieren eine Konfigurationsdatei für die Clientauthentifizierung, indem Sie folgenden Befehl eingeben:
PowerShell
kubectl oidc client-config ` --issuer-uri [ISSUER_URI] ` --redirect-uri [REDIRECT_URI] ` --client-id [CLIENT_ID] ` --client-secret [CLIENT_SECRET] ` --scopes "allatclaims" ` --cluster-name [USER_CLUSTER_NAME] ` --server [CLUSTER_URL] ` --server-ca-file server-ca-cert ` --issuer-ca-file [ADFS_CA_CERT] ` --extra-params "resource=token-groups-claim" > client-config.yaml
- [ISSUER_URI] ist der URI des Ausstellers.
- [REDIRECT_URI] ist Ihr Weiterleitungs-URI.
- [CLIENT_ID] ist die Client-ID für die Anwendung "kubectl".
- [CLIENT_SECRET] ist der Clientschlüssel, der für Sie generiert wurde.
- [USER_CLUSTER_NAME] ist der Name Ihres Nutzerclusters.
- [CLUSTER_URL] ist die URL des Kubernetes API-Servers Ihres Clusters.
--server-ca-file
akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.- [ADFS_CA_CERT] ist der Pfad zur öffentlichen Zertifikatsdatei für die ADFS-CA.
--extra-param
sendet ein Schlüssel/Wert-Paar mit der Authentifizierungsanfrage an den OIDC-Anbieter.
Linux
kubectl oidc client-config \ --issuer-uri [ISSUER_URI] \ --redirect-uri [REDIRECT_URI] \ --client-id [CLIENT_ID] \ --client-secret [CLIENT_SECRET] \ --scopes "allatclaims" \ --cluster-name [USER_CLUSTER_NAME] \ --server [CLUSTER_URL] \ --server-ca-file server-ca-cert \ --issuer-ca-file [ADFS_CA_CERT] \ --extra-params "resource=token-groups-claim" > client-config.yaml
- [ISSUER_URI] ist der URI des Ausstellers.
- [REDIRECT_URI] ist Ihr Weiterleitungs-URI.
- [CLIENT_ID] ist die Client-ID für die Anwendung "kubectl".
- [CLIENT_SECRET] ist der Clientschlüssel, der für Sie generiert wurde.
- [USER_CLUSTER_NAME] ist der Name Ihres Nutzerclusters.
- [CLUSTER_URL] ist die URL des Kubernetes API-Servers Ihres Clusters.
--server-ca-file
akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.- [ADFS_CA_CERT] ist der Pfad zur öffentlichen Zertifikatsdatei für die ADFS-CA.
--extra-param
sendet ein Schlüssel/Wert-Paar mit der Authentifizierungsanfrage an den OIDC-Anbieter.
Mit diesem Befehl wird eine Client-Authentifizierungsdatei namens client-config.yaml
erstellt.
Bearbeiten Sie diese Datei nicht manuell. Jeder Mitarbeiter, der sich beim Nutzercluster authentifizieren muss, sollte client-config.yaml
erhalten.
Mit dem Kubectl-Plug-in für OIDC einen Nutzercluster authentifizieren
Führen Sie die folgenden Schritte von Ihrem lokalen Computer oder Ihrer VM aus, um sich mithilfe der Clientauthentifizierungsdatei bei einem Nutzercluster zu authentifizieren:
Initialisieren Sie das Plug-in mit der Datei
client-config.yaml
:kubectl oidc login --clientconfig-file=client-config.yaml --user [NAME] \ --kubeconfig [KUBECONFIG_OUTPUT_PATH]
Dabei gilt:
- [NAME] ist der von Ihnen gewählte Nutzername.
- [KUBECONFIG_OUTPUT_PATH] ist der Ausgabespeicherort der kubeconfig-Datei, in der die Anmeldedaten gespeichert sind.
kubectl oidc login
startet einen Browser, in dem der Nutzer oder Mitarbeiter seine Anmeldedaten eingeben kann.Die bereitgestellte kubeconfig-Datei enthält jetzt ein ID-Token, das von kubectl zur Authentifizierung beim Kubernetes API-Server auf dem Nutzercluster verwendet werden kann.
ausführen.Sie sollten sich jetzt authentifizieren. Geben Sie einen
kubectl
-Befehl ein, um festzustellen, ob Sie sich erfolgreich authentifiziert haben. Beispiel:kubectl get nodes --kubeconfig [KUBECONFIG_OUTPUT_PATH]
Fazit
Ihr Unternehmen betreibt einen ADFS-Server, der als OpenID-Anbieter fungiert. Ihr OpenID-Anbieter kennt die Anwendung kubectl
und weiß, dass kubectl
die Bereiche openid
und allatclaims
anfordern kann.
Das LDAP-Attribut Token-Groups Qualified Names
in Ihrer AD-Datenbank wird dem Anspruch groups
in Ihrem OpenID-Anbieter zugeordnet. Der Anbieter gibt Tokens zurück, die die Mitarbeiter-ID, die Aussteller-ID, den openid
-Anspruch und den groups
-Anspruch enthalten.
Der Anspruch groups
listet die Sicherheitsgruppen auf, zu denen ein Mitarbeiter gehört.
Weitere Informationen
Übersicht über die Authentifizierung mit OpenID Connect in GKE On-Prem ansehen
Mehr über benutzerdefinierte Anforderungen in ID-Tokens erfahren