Mit OIDC und AD FS authentifizieren

Auf dieser Seite wird gezeigt, wie Sie mit OpenID Connect (OIDC) und Active Directory Federation Services (AD FS) die Authentifizierung für Anthos GKE On-Prem-Nutzercluster konfigurieren. Beachten Sie, dass AD FS OIDC nur ab Version 2016 unterstützt.

Eine Übersicht über den Authentifizierungsablauf finden Sie unter Authentifizierung. Informationen zum Verwenden anderer OpenID-Anbieter als AD FS finden Sie unter Mit OpenID Connect authentifizieren.

Ü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. Sie verwenden eine Reihe von AD FS-Verwaltungsassistenten, um Ihren AD FS-Server und Ihre AD-Mitarbeiterdatenbank zu konfigurieren.

Hinweis

In diesem Thema wird davon ausgegangen, dass Sie mit OAuth 2.0 und OpenID Connect vertraut sind. Außerdem 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 AD FS-Server (Active Directory Federation Services).
  • Der AD FS-Server fungiert als OpenID-Anbieter.

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.

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

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Beim Aufbau einer Beziehung zu Ihrem AD FS-Server müssen Sie eine Weiterleitungs-URL angeben, mit der der AD FS-Server ID-Tokens an das Anthos-Plug-in für Kubectl zurückgeben kann. 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 bei der Konfiguration Ihres AD FS-Servers http://localhost:[PORT]/callback als eine Ihrer Weiterleitungs-URLs an.

Weiterleitungs-URL für die Google Cloud Console konfigurieren

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Zusätzlich zur Weiterleitungs-URL für das Anthos-Plug-in für Kubectl benötigen Sie 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

Wenn Sie Ihren AD FS-Server konfigurieren, geben Sie https://console.cloud.google.com/kubernetes/oidc als eine Ihrer Weiterleitungs-URLs an.

AD FS konfigurieren

In den folgenden Abschnitten wird erläutert, wie AD FS für GKE On-Prem konfiguriert wird.

Weiterleitungs-URLs festlegen

Dieser Abschnitt richtet sich an Organisationsadministratoren.

  1. Öffnen Sie das AD FS-Verwaltungsfenster.

  2. Wählen Sie Application Groups, Actions und Add an Application Group aus.

  3. Wählen Sie Server Application aus. Geben Sie einen Namen und eine Beschreibung ein. Klicken Sie auf Next.

  4. Geben Sie Ihre beiden Weiterleitungs-URLs ein. Sie erhalten dann eine Client-ID. Damit identifiziert der AD FS-Server das Anthos-Plug-in für Kubectl und die Google Cloud Console. Speichern Sie die Client-ID für eine spätere Verwendung.

  5. Wählen Sie Generate a shared secret aus. Das Anthos-Plug-in für Kubectl und die Google Cloud Console verwenden dieses Secret zur Authentifizierung beim AD FS-Server. Speichern Sie das Secret für eine spätere Verwendung.

Sicherheitsgruppen konfigurieren (optional)

Dieser Abschnitt richtet sich an Organisationsadministratoren.

  1. Wählen Sie in der AD FS-Verwaltung Relying party trusts und dann Add a new relying party trust aus.

  2. Wählen Sie Claims aware aus und klicken Sie auf Start.

  3. Wählen Sie Enter data about relying party manually aus.

  4. Geben Sie einen Anzeigenamen ein.

  5. Überspringen Sie die beiden nächsten Schritte.

  6. Geben Sie eine Vertrauensstellungs-ID für die vertrauende Seite ein. Vorschlag: token-groups-claim.

  7. Wählen Sie für Access control policy die Option Permit everyone aus. Mit dieser Auswahl wird festgelegt, dass alle Mitarbeiter ihre Sicherheitsgruppeninformationen mit dem Anthos-Plug-in für Kubectl und die Google Cloud Console teilen.

  8. Klicken Sie auf Beenden.

LDAP-Attribute zu Anforderungsnamen zuordnen

Dieser Abschnitt richtet sich an Organisationsadministratoren.

  1. Wählen Sie in der AD FS-Verwaltung Relying party trusts und dann Edit claim issuance policy aus.

  2. Wählen Sie Send LDAP Attributes as Claims aus und klicken Sie auf Weiter.

  3. Geben Sie für Claim rule name den Wert groups ein.

  4. Wählen Sie für Attribute store die Option Active Directory aus.

  5. Wählen Sie in der Tabelle unter LDAP Attribute Folgendes aus:

    • AD FS Version 5.0 und höher: Token-Groups Qualified by Domain name
    • AD FS-Versionen vor 5.0: Token Groups – Qualified Names

  6. Wählen Sie unter Outgoing Claim Type Folgendes aus:

    • AD FS-Version 5.0 und höher: Group
    • AD FS-Versionen vor 5.0: Groups

  7. Klicken Sie auf Finish und dann auf Apply.

Anthos-Plug-in für Kubectl und die Google Cloud Console bei AD FS registrieren

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Öffnen Sie im Administratormodus ein PowerShell-Fenster und geben Sie folgenden Befehl ein:

Grant-AD FSApplicationPermission `
    -ClientRoleIdentifier "[CLIENT_ID]" `
    -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
    -ScopeName "allatclaims", "openid"

Dabei gilt:

  • [CLIENT_ID] ist die 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.

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 ü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.

  • 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 haben die Möglichkeit, die Authentifizierungskonfiguration für mehrere Cluster in einer einzigen Datei zu speichern. Anschließend können Sie diese Datei an die Entwickler verteilen, die Zugriff auf alle diese Cluster haben sollen.

Starten 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.

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

Unabhängig von der Verteilungsmethode muss die Konfigurationsdatei für die Authentifizierung unter den folgenden Pfaden auf dem Computer jedes Entwicklers platziert 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

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. Die ausführbare Datei muss den Namen kubectl-anthos haben. 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.

Fazit

Ihr Unternehmen betreibt einen AD FS-Server, der als OpenID-Anbieter fungiert. Ihr OpenID-Anbieter kennt Ihre beiden Clientanwendungen: das Anthos-Plug-in für Kubectl und die Google Cloud Console. Ihr OpenID-Anbieter weiß, dass Ihre Clientanwendungen die Bereiche openid und allatclaims anfordern können.

In der AD FS-Version vor 5.0 wird das Token-Groups Qualified Names-LDAP-Attribut in Ihrer AD-Datenbank der groups-Anforderung in Ihrem OpenID-Anbieter zugeordnet. Ab Version 5.0 lautet das Attribut Token-Groups Qualified by Domain name. Der Anbieter gibt Tokens zurück, die die Mitarbeiter-ID, die Aussteller-ID, die openid-Anforderung und die groups-Anforderung enthalten. Der groups-Anspruch (Group in 5.0) listet die Sicherheitsgruppen auf, zu denen ein Mitarbeiter gehört.

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.

Weitere Informationen