Auf dieser Seite wird gezeigt, wie Sie mit einem OpenID-Anbieter die Authentifizierung für GKE On-Prem-Nutzercluster konfigurieren. Informationen zur Verwendung von OIDC mit ADFS finden Sie unter Mit OIDC und ADFS authentifizieren.
Eine Übersicht über den Authentifizierungsvorgang in GKE On-Prem 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 konfigurieren Sie eine Beziehung zwischen Ihrem OpenID-Anbieter und kubectl
.
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.
Identitätsanbieter auswählen
- Verwenden Sie Active Directory Federated Services (ADFS) als OpenID-Anbieter und verwenden Sie eine lokale Instanz von AD als Ihre Mitarbeiterdatenbank. Weitere Informationen unter Mit OIDC und ADFS authentifizieren.
- Verwenden Sie einen anderen OpenID-Anbieter.
Unabhängig von der gewählten Option können Sie das in dieser Anleitung beschriebene Kubectl-Plug-in für OIDC verwenden, um die Konfiguration der Authentifizierung und den Authentifizierungsprozess selbst zu beschleunigen. In diesem Thema wird erläutert, wie Sie einen anderen OpenID-Anbieter als ADFS verwenden.
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
Beim Aufbau einer Beziehung zu Ihrem OpenID-Anbieter müssen Sie einen Weiterleitungs-URI angeben, mit dem der 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.
Kubectl-Plug-in für OIDC bei Ihrem OpenID-Anbieter registrieren
Bevor Sie das Kubectl-Plug-in für OIDC mit Ihrem OpenID-Anbieter verwenden können, müssen Sie das Plug-in beim Anbieter registrieren. Die Registrierung umfasst folgende Schritte:
Informieren Sie sich über den URI des Dienstleisters. Hier sendet das Plug-in Authentifizierungsanfragen.
Teilen Sie dem Anbieter Ihren Weiterleitungs-URI mit.
Legen Sie eine Client-ID fest. Dies ist die ID, mit der der Anbieter das Plug-in identifiziert.
Richten Sie einen Clientschlüssel ein. Das Plug-in verwendet dieses Secret für die Authentifizierung beim OpenID-Anbieter.
Legen Sie einen benutzerdefinierten Bereich fest, mit dem das Plug-in die Sicherheitsgruppen des Nutzers anfordern kann.
Legen Sie einen benutzerdefinierten Anforderungsnamen fest, mit dem der Anbieter die Sicherheitsgruppen des Nutzers zurückgibt.
Die jeweilige Vorgehensweise hängt von Ihrem OpenID-Anbieter ab. Informationen zum Ausführen der Registrierungsschritte mit ADFS finden Sie unter Mit OIDC und ADFS authentifizieren.
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:
Linux
kubectl oidc client-config --issuer-uri [ISSUER_URI] \ --redirect-uri [REDIRECT_URI] \ --client-id [CLIENT_ID] \ --client-secret [CLIENT_SECRET] \ --scopes "[CUSTOM_SCOPES]" \ --cluster-name [USER_CLUSTER_NAME] \ --server [CLUSTER_URL] \ --server-ca-file server-ca-cert \ --issuer-ca-file [CA_CERT] \ --extra-params [KEY]=[VALUE] > 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 des Nutzerclusters.
--server-ca-file
akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.- [CA_CERT] ist der Pfad zur öffentlichen CA-Datei des Ausstellers.
- [CUSTOM_SCOPES] ist die durch Kommas getrennte Liste Ihrer benutzerdefinierten Bereiche für Sicherheitsgruppen.
--extra-param
sendet ein Schlüssel/Wert-Paar mit der Authentifizierungsanfrage an den OIDC-Anbieter.
PowerShell
kubectl oidc client-config --issuer-uri [ISSUER_URI] ` --redirect-uri [REDIRECT_URI] ` --client-id [CLIENT_ID] ` --client-secret [CLIENT_SECRET] ` --scopes "[CUSTOM_SCOPES]" ` --cluster-name [USER_CLUSTER_NAME] ` --server [CLUSTER_URL] ` --server-ca-file server-ca-cert ` --issuer-ca-file [CA_CERT] ` --extra-params [KEY]=[VALUE] > 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 des Nutzerclusters.
--server-ca-file
akzeptiert den Pfad zur CA-Datei, die Sie im vorherigen Abschnitt erstellt haben.- [CA_CERT] ist der Pfad zur öffentlichen CA-Datei des Ausstellers.
- [CUSTOM_SCOPES] ist die durch Kommas getrennte Liste Ihrer benutzerdefinierten Bereiche für Sicherheitsgruppen.
--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.
TLS-Zertifikate
GKE On-Prem-Nutzercluster verwenden TLS, um die gesamte Kommunikation zwischen Clusterkomponenten 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.
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] der Ausgabespeicherort für die 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]