Mit OpenID Connect (OIDC) authentifizieren

Auf dieser Seite wird beschrieben, wie Sie GKE On-Prem konfigurieren, um einen OpenID-Anbieter für die Authentifizierung bei Nutzerclustern zu verwenden. Informationen zur Verwendung von OIDC mit AD FS finden Sie unter Mit OIDC und AD FS authentifizieren. Informationen zum Verwenden von OIDC mit dem Google OpenID-Anbieter finden Sie unter Mit OIDC und Google authentifizieren.

Eine Übersicht über den Authentifizierungsablauf 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. Mit OIDC können Sie den Zugriff auf Kubernetes-Cluster verwalten und die Standardverfahren in Ihrer Organisation zum Erstellen, Aktivieren und Deaktivieren von Mitarbeiterkonten nutzen.

Für Mitarbeiter gibt es zwei Möglichkeiten zur Verwendung der OIDC-Authentifizierung:

  • Ein Mitarbeiter kann mit kubectl einen OIDC-Ablauf initiieren. Um diesen Ablauf als automatisch festzulegen, stellt GKE On-Prem das Anthos-Plug-in for Kubectl zur Verfügung, ein kubectl-Plug-in.
  • Ein Mitarbeiter kann mithilfe der Google Cloud Console einen OIDC-Authentifizierungsvorgang initiieren.

In dieser Übung konfigurieren Sie beide Optionen: kubectl und die Google Cloud Console.

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äten

In diesem Thema werden drei Identitäten behandelt:

  • Administrator der Organisation: Wählt einen OpenID-Anbieter aus und registriert Clientanwendungen beim Anbieter.

  • Clusteradministrator: Erstellt einen oder mehrere Nutzercluster und Konfigurationsdateien zur Authentifizierung für Entwickler, die die Cluster verwenden.

  • Entwickler: Führt Arbeitslasten auf einem oder mehreren Clustern aus und verwendet OIDC zur Authentifizierung.

OpenID-Anbieter auswählen

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Sie können einen beliebigen OpenID-Anbieter verwenden. Eine Liste der zertifizierten Anbieter finden Sie unter OpenID-Zertifizierung.

Eine Möglichkeit ist die Verwendung von Active Directory Federated Services (ADFS) als OpenID-Anbieter und einer lokalen Instanz von Active Directory als Mitarbeiterdatenbank. Weitere Informationen finden Sie unter Mit OIDC und AD FS authentifizieren.

Eine weitere Möglichkeit ist die Verwendung von Google als OpenID-Anbieter.

Weiterleitungs-URL für das Anthos-Plug-in für Kubectl erstellen

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Beim Einrichten einer Beziehung zu Ihrem OpenID-Anbieter müssen Sie eine Weiterleitungs-URL angeben, mit der der Anbieter ID-Tokens für Kubectl an das Anthos-Plug-in zurückgibt. Das Anthos-Plug-in für Kubectl wird auf den lokalen Computern der einzelnen Entwickler ausgeführt und überwacht einen Port Ihrer Wahl. Wählen Sie eine Portnummer größer als 1024 aus, die für diesen Zweck geeignet ist. Die Weiterleitungs-URL lautet unter diesen Bedingungen so:

http://localhost:[PORT]/callback

Dabei ist [PORT] Ihre Portnummer.

Geben Sie beim Konfigurieren Ihres OpenID-Anbieters http://localhost:[PORT]/callback als eine Ihrer Weiterleitungs-URL an. Die jeweilige Vorgehensweise hängt von Ihrem Anbieter ab.

Weiterleitungs-URL für die Google Cloud Console konfigurieren

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Sie benötigen nicht nur eine Weiterleitungs-URL für kubectl, sondern auch eine Weiterleitungs-URL für die Google Cloud Console. Die Weiterleitungs-URL für die Google Cloud Console lautet:

https://console.cloud.google.com/kubernetes/oidc

Geben Sie beim Konfigurieren Ihres OIDC-Anbieters https://console.cloud.google.com/kubernetes/oidc als eine Ihrer Weiterleitungs-URLs an. Wie Sie dabei vorgehen, hängt von Ihrem Anbieter ab.

Client-Anwendungen beim OpenID-Anbieter registrieren

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Bevor Ihre Entwickler das Anthos-Plug-in für Kubectl oder die Google Cloud Console mit Ihrem OpenID-Anbieter verwenden können, müssen Sie diese beiden Clients beim OpenID-Anbieter registrieren. Die Registrierung umfasst folgende Schritte:

  • Ermitteln Sie den Aussteller-URI des Anbieters. Hier sendet das Anthos-Plug-in für Kubectl oder die Google Cloud Console Authentifizierungsanfragen.

  • Geben Sie dem Anbieter die Weiterleitungs-URL für das Anthos-Plug-in für Kubectl.

  • Geben Sie dem Anbieter die Weiterleitungs-URL für die Google Cloud Console. Sie lautet https://console.cloud.google.com/kubernetes/oidc.

  • Richten Sie eine einzelne Client-ID ein. Dies ist die ID, die der Anbieter zum Identifizieren des Anthos-Plug-ins für Kubectl und der Google Cloud Console verwendet.

  • Richten Sie einen einzelnen Clientschlüssel ein. Das Anthos-Plug-in für Kubectl und die Google Cloud Console verwenden dieses Secret zur Authentifizierung beim OpenID-Anbieter.

  • Legen Sie einen benutzerdefinierten Bereich fest, mit dem das Anthos-Plug-in für Kubectl oder die Google Cloud Console die Sicherheitsgruppen des Nutzers anfordern kann.

  • Legen Sie einen benutzerdefinierten Anforderungsnamen fest, mit dem der Anbieter die Sicherheitsgruppen des Nutzers zurückgibt.

Wie Sie diese Schritte durchführen, hängt von Ihrem OpenID-Anbieter ab. Informationen zum Ausführen der Registrierungsschritte mit ADFS finden Sie unter Mit OIDC und ADFS authentifizieren.

oidc-Spezifikation in der GKE On-Prem-Konfigurationsdatei festlegen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Generieren Sie, bevor Sie einen Nutzercluster erstellen, erst mit gkectl create-config eine GKE On-Prem-Konfigurationsdatei. Die Konfiguration enthält die unten aufgeführte oidc-Spezifikation. Für oidc geben Sie die für Ihren Anbieter spezifischen Werte an:

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:
  • issuerurl: erforderlich. Die URL Ihres OpenID-Anbieters, beispielsweise "https://example.com/adfs". Clientanwendungen wie das Anthos-Plug-in für Kubectl und die Google Cloud Console senden Autorisierungsanfragen an diese URL. Der Kubernetes API-Server nutzt diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens zu ermitteln. Es muss HTTPS verwendet werden.
  • kubectlredirecturl: erforderlich. Die zuvor für das Anthos-Plug-in für Kubectl konfigurierte Weiterleitungs-URL.
  • clientid: erforderlich. Die ID für die Clientanwendung, die Authentifizierungsanfragen an den OpenID-Anbieter sendet. Sowohl das Anthos-Plug-in für Kubectl als auch die Google Cloud Console verwenden diese ID.
  • clientsecret: optional. Das Secret für die Clientanwendung. Sowohl das Anthos-Plug-in für Kubectl als auch die Google Cloud Console verwenden dieses Secret.
  • username: Optional. Die JWT-Anforderung, die als Nutzername verwendet wird. Der Standardwert ist sub. Dies ist eine eindeutige ID des Endnutzers. Je nach OpenID-Anbieter können Sie andere Anforderungen auswählen, wie beispielsweise email oder name. Allerdings wird anderen Anforderungen als email die Aussteller-URL vorangestellt, um Namenskonflikte mit anderen Plug-ins zu vermeiden.
  • usernameprefix: optional. Das Präfix, das Nutzernamensanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn Sie dieses Feld nicht angeben und username ein anderer Wert als email ist, wird standardmäßig das Präfix issuerurl# verwendet. Sie können mit dem Wert - alle Präfixe deaktivieren.
  • group: optional. Die JWT-Anforderung, mit der der Anbieter Ihre Sicherheitsgruppen zurückgibt.
  • groupprefix: optional. Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Ein Beispiel ist gid-foobar für die Gruppe foobar und das Präfix gid-. Standardmäßig ist dieser Wert leer und es gibt kein Präfix.
  • scopes: optional. Zusätzliche Bereiche, die als durch Kommas getrennte Liste an den OpenID-Anbieter gesendet werden.
    • Für die Authentifizierung mit Microsoft Azure oder Okta übergeben Sie offline_access.

  • extraparams: optional. Zusätzliche Schlüssel/Wert-Paar-Parameter, die als durch Kommas getrennte Liste an den OpenID-Anbieter gesendet werden.
  • usehttpproxy: Optional. Gibt an, ob ein Reverse-Proxy im Cluster bereitgestellt werden soll, um der Google Cloud Console für das Authentifizieren von Nutzern Zugriff auf den lokalen OIDC-Anbieter zu gewähren. Der Wert muss ein String sein: "true" oder "false". Wenn Ihr Identitätsanbieter nicht über das öffentliche Internet erreichbar ist und Sie sich mit der Google Cloud Console authentifizieren möchten, muss für dieses Feld "true" festgelegt werden. Wenn Sie hier nichts eingeben, wird standardmäßig "false" verwendet.

  • capath: optional. Pfad zum Zertifikat der Zertifizierungsstelle, die das Webzertifikat Ihres Identitätsanbieters ausgestellt hat. Dieser Wert ist möglicherweise nicht erforderlich. Wenn das Zertifikat Ihres Identitätsanbieters beispielsweise von einer bekannten öffentlichen Zertifizierungsstelle ausgestellt wurde, müssen Sie hier keinen Wert angeben. Wenn für "usehttpproxy" aber "true" gilt, müssen Sie diesen Wert auch für eine bekannte öffentliche Zertifizierungsstelle angeben.

Beispiel: Nutzer und Gruppen autorisieren

Viele Anbieter codieren nutzeridentifizierende Attribute 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 zu einem Verfügbarkeitsrisiko (wenn ein Nutzer seine primäre E-Mail-Adresse ändert) als auch zu einem Sicherheitsrisiko (wenn eine E-Mail neu zugewiesen werden kann) führen.

Daher wird empfohlen, Gruppenrichtlinien zu verwenden, da eine Gruppen-ID sowohl persistent als auch einfacher zu prüfen ist.

Beispiel: Ihr Anbieter erstellt Identitätstokens, 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-'
extraparams: 'resource=token-groups-claim'
...

Nachdem Sie den Nutzercluster erstellt haben, können Sie den authentifizierten Nutzern mithilfe der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) autorisierten Zugriff gewähren. Sie haben beispielsweise die Möglichkeit, eine ClusterRole zu erstellen, die ihren Nutzern Lesezugriff auf die Secrets des Clusters gewährt, sowie eine ClusterRoleBinding-Ressource, 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

Erste Konfigurationsdatei für die Authentifizierung erstellen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Nachdem Sie einen Nutzercluster angelegt haben, erstellen Sie eine Authentifizierungs-Konfigurationsdatei für Ihren Cluster:

gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG]

Dabei ist [USER_CLUSTER_KUBECONFIG] der Pfad für die kubeconfig-Datei Ihres Nutzerclusters. Beim Anlegen des Nutzerclusters wurde mit gkectl create cluster eine kubeconfig-Datei für den Cluster generiert.

Mit dem vorherigen Befehl wird eine Datei namens kubectl-anthos-config.yaml im aktuellen Verzeichnis erstellt.

Der Konfigurationsdatei für die Authentifizierung weitere Cluster hinzufügen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Sie können die Authentifizierungskonfiguration für mehrere Cluster in einer einzigen Datei speichern. Anschließend können Sie diese Datei an die Entwickler verteilen, die Zugriff auf alle diese Cluster benötigen.

Beginnen Sie mit einer vorhandenen Konfigurationsdatei für die Authentifizierung. Verwenden Sie dann den folgenden Befehl, um diese Datei mit der Konfiguration für einen zusätzlichen Cluster zusammenzuführen:

gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG] \
    --merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

Dabei gilt:

  • [USER_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei des zusätzlichen Clusters.

  • [IN_AUTH_CONFIG_FILE] ist der Pfad der vorhandenen Konfigurationsdatei für die Authentifizierung.

  • [OUT_AUTH_CONFIG_FILE] ist der Pfad, unter dem Sie die Datei mit der zusammengeführten Konfiguration speichern möchten. Dieser kann mit [IN_AUTH_CONFIG_FILE] identisch sein.

Konfigurationsdatei für die Authentifizierung verteilen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Der Name der Konfigurationsdatei für die Authentifizierung, die Sie an Ihre Entwickler verteilen, muss kubectl-anthos-config.yaml lauten. Sie können die Konfigurationsdatei für die Authentifizierung auf verschiedene Art verteilen:

  • Sie übergeben die Datei manuell an jeden Entwickler.

  • Sie hosten die Datei unter einer URL, mit der Entwickler sie herunterladen können.

  • Übertragen Sie die Datei per Push auf den Computer jedes Entwicklers.

Unabhängig von der Verteilungsmethode muss die Authentifizierungs-Konfigurationsdatei an diesem Speicherort auf dem Computer jedes Entwicklers abgelegt werden:

Linux

$HOME/.config/google/anthos/kubectl-anthos-config.yaml

macOS

$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

Windows

%APPDATA%\google\anthos\kubectl-anthos-config.yaml

Wenn Sie die Standardkonfiguration nicht verwenden möchten, können Sie eine benutzerdefinierte Konfiguration erstellen.

Konfigurationsdatei für die Authentifizierung platzieren

Dieser Abschnitt richtet sich an Entwickler.

Die Konfigurationsdatei für die Authentifizierung enthält die Details zu allen Clustern, bei denen Sie sich authentifizieren können. Beachten Sie, dass der Inhalt dieser Datei nicht geändert werden darf.

Wenn Ihr Clusteradministrator eine Konfigurationsdatei zur Authentifizierung für Sie bereitgestellt hat, platzieren Sie die Datei im entsprechenden Verzeichnis. Wenn Ihr Clusteradministrator die Konfiguration bereits auf Ihrem Computer platziert hat, können Sie diesen Abschnitt überspringen.

Kopieren Sie die Konfigurationsdatei für die Authentifizierung an ihren Standardspeicherort:

Linux

mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung.

macOS

mkdir -p  $HOME/Library/Preferences/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung.

Windows

md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung.

Anthos-Plug-in für Kubectl abrufen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Das Anthos-Plug-in für Kubectl befindet sich auf Ihrer Administrator-Workstation unter folgenden Pfaden:

Linux

/usr/bin/kubectl_anthos/v1.0beta/linux_amd64/kubectl-anthos

macOS

/usr/bin/kubectl_anthos/v1.0beta/darwin_amd64/kubectl-anthos

Windows

/usr/bin/kubectl_anthos/v1.0beta/windows_amd64/kubectl-anthos

Sie können das Plug-in an Ihre Entwickler verteilen oder sie bitten, das Plug-in direkt herunterzuladen.

Anthos-Plug-in für Kubectl herunterladen

Dieser Abschnitt richtet sich an Clusteradministratoren und Entwickler.

Jeder Entwickler benötigt das Anthos-Plug-in für Kubectl auf seinem eigenen Computer. Die Entwickler können das Plug-in selbst herunterladen oder der Clusteradministrator kann das Plug-in herunterladen und dann an die Entwickler verteilen.

Hinweis für Entwickler: Fragen Sie Ihren Clusteradministrator, welche Version des Plug-ins Sie verwenden müssen.

Laden Sie das Anthos-Plug-in für Kubectl herunter:

Linux

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/linux_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

macOS

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/darwin_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

Windows

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/windows_amd64/kubectl-anthos ./
rename kubectl-anthos kubectl-anthos.exe.

Anthos-Plug-in für Kubectl installieren

Dieser Abschnitt richtet sich an Entwickler.

Das Anthos-Plug-in für Kubectl kann Ihnen von Ihrem Clusteradministrator zur Verfügung gestellt werden. Alternativ werden Sie von Ihrem Clusteradministrator eventuell gebeten, das Plug-in selbst herunterzuladen.

Zum Installieren des Anthos-Plug-ins für Kubectl verschieben Sie die ausführbare Datei an einen beliebigen Speicherort in Ihrem PFAD. Für Linux und macOS muss die ausführbare Datei den Namen kubectl-anthos haben. Unter Windows muss sie kubectl-anthos.exe heißen. Weitere Informationen finden Sie unter Kubectl-Plug-ins installieren.

Prüfen Sie, ob das Anthos-Plug-in für Kubectl installiert ist:

kubectl plugin list
kubectl anthos version

Verfügbare Cluster auflisten

Dieser Abschnitt richtet sich an Entwickler.

Wenn sich die Konfigurationsdatei für die Authentifizierung im Standardpfad befindet, geben Sie folgenden Befehl ein, um die Cluster aufzulisten, bei denen Sie sich authentifizieren können:

kubectl anthos listclusters

Wenn sich die Konfigurationsdatei für die Authentifizierung nicht im Standardpfad befindet, geben Sie folgenden Befehl zum Auflisten der Cluster ein:

kubectl anthos listclusters --loginconfig [AUTH_CONFIG_FILE]

Dabei ist [AUTH_CONFIG_FILE] der Pfad zur Konfigurationsdatei für die Authentifizierung.

Anthos-Plug-in für Kubectl zum Authentifizieren verwenden

Dieser Abschnitt richtet sich an Entwickler.

Melden Sie sich bei einem Nutzercluster an:

kubectl anthos login --cluster [CLUSTER_NAME] --user [USER_NAME] \
     --loginconfig [AUTH_CONFIG_FILE] --kubeconfig [USER_CLUSTER_KUBECONFIG]

Dabei gilt:

  • [CLUSTER_NAME] ist der Name Ihres Nutzerclusters. Dieser Name muss aus der vom Befehl kubectl anthos listclusters bereitgestellten Liste ausgewählt werden.

  • [USER_NAME] ist ein optionaler Parameter, der den Nutzernamen für die Anmeldedaten angibt, die in der kubeconfig-Datei gespeichert sind. Der Standardwert ist [CLUSTER_NAME]-anthos-default-user.

  • [AUTH_CONFIG_FILE] ist der Pfad zur Konfigurationsdatei für die Authentifizierung. Wenn sich die Konfigurationsdatei für die Authentifizierung im Standardspeicherort befindet, können Sie diesen Parameter weglassen.

  • [USER_CLUSTER_KUBECONFIG] ist der Pfad der kubeconfig-Datei Ihres Nutzerclusters. Wenn keine kubeconfig-Datei vorhanden ist, generiert der Befehl eine neue kubeconfig-Datei aus der Konfigurationsdatei für die Authentifizierung und fügt der kubeconfig-Datei die Clusterdetails und Tokens hinzu.

kubectl anthos login ruft einen Browser auf, in dem Sie Ihre Anmeldedaten eingeben können.

Die bereitgestellte kubeconfig-Datei enthält jetzt ein ID-Token, mit dem sich kubectl beim Kubernetes API-Server im Nutzercluster authentifizieren kann.

Der Befehl kubectl anthos login hat ein optionales Flag --dry-run. Wenn Sie das Flag --dry-run verwenden, gibt der Befehl die kubectl-Befehle aus, mit denen der kubeconfig-Datei Tokens hinzugefügt werden. Die Tokens werden aber nicht tatsächlich in der kubeconfig-Datei gespeichert.

Geben Sie einen kubectl-Befehl ein, um zu prüfen, ob die Authentifizierung erfolgreich war. Beispiel:

kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

OIDC mit der Google Cloud Console verwenden

Dieser Abschnitt richtet sich an Entwickler.

  1. Prüfen Sie, ob Ihr Cluster für OIDC konfiguriert ist.

  2. Prüfen Sie, ob Ihr Cluster bei Google Cloud registriert wurde, entweder automatisch bei der Clustererstellung oder manuell.

  3. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

    Zur Seite „Kubernetes-Cluster“

  4. Ermitteln Sie in der Liste der Cluster Ihren GKE On-Prem-Cluster und klicken Sie auf Anmelden.

  5. Wählen Sie Mit dem für den Cluster konfigurierten Identitätsanbieter authentifizieren aus und klicken Sie auf ANMELDEN.

    Sie werden dann zu Ihrem Identitätsanbieter weitergeleitet. Dort müssen Sie sich möglicherweise anmelden oder dem Zugriff der Google Cloud Console auf Ihr Konto zustimmen. Anschließend werden Sie zurück zur Seite Kubernetes-Cluster in der Google Cloud Console geleitet.

Benutzerdefinierte Konfiguration

Standardmäßig erwartet das Anthos-Plug-in für Kubectl, dass sich die Konfigurationsdatei für die Authentifizierung an einem bestimmten Ort befindet. Wenn Sie die Konfigurationsdatei für die Authentifizierung nicht am Standardspeicherort speichern möchten, können Sie den Pfad der Konfigurationsdatei für die Authentifizierung mithilfe des Flags --login-config manuell an die Plug-in-Befehle übergeben. Ein entsprechendes Beispiel finden Sie unter Anthos-Plug-in für Kubectl zum Authentifizieren verwenden.

Fehlerbehebung bei OIDC in GKE On-Prem

Ungültige Konfiguration

Wenn in der Google Cloud Console die OIDC-Konfiguration aus Ihrem Cluster nicht gelesen werden kann, wird die Schaltfläche ANMELDEN deaktiviert.

Ungültige Anbieterkonfiguration

Wenn die Konfiguration Ihres Identitätsanbieters ungültig ist, wird nach dem Klicken auf ANMELDEN eine Fehlermeldung Ihres Identitätsanbieters angezeigt. Folgen Sie dann der anbieterspezifischen Anleitung, um den Anbieter oder Ihren Cluster ordnungsgemäß zu konfigurieren.

Ungültige Berechtigungen

Wenn Sie den Authentifizierungsvorgang abgeschlossen haben, die Details des Clusters aber noch nicht sichtbar sind, prüfen Sie, ob Sie dem mit OIDC verwendeten Konto die erforderlichen RBAC-Berechtigungen erteilt haben. Dieses Konto kann sich von dem Konto unterscheiden, mit dem Sie auf die Google Cloud Console zugreifen.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

Dieser Fehler tritt eventuell auf, wenn der Autorisierungsserver zur Zustimmung auffordert, der erforderliche Authentifizierungsparameter aber nicht angegeben wurde. Geben Sie den Parameter prompt=consent im Feld oidc: extraparams der GKE On-Prem-Konfigurationsdatei an und generieren Sie die Clientauthentifizierungsdatei mit dem Flag --extra-params prompt=consent neu.