Mit OIDC und AD FS authentifizieren

So konfigurieren Sie Anthos-Cluster auf VMware (GKE On-Prem) für die Verwendung von OpenID Connect (OIDC) mit Active Directory Federation Services (AD FS) zur Authentifizierung bei Nutzerclustern. Auf dieser Seite wird der Vorgang allgemein erläutert, damit Sie einen AD FS-Server als OpenID-Anbieter mit Active Directory als Nutzerdatenbank konfigurieren können.

Eine Übersicht über die Anthos-Cluster auf VMware-Authentifizierung finden Sie unter Authentifizierung. Informationen zum Konfigurieren von OIDC mit anderen OpenID-Anbietern finden Sie in den folgenden Ressourcen:

Anthos-Cluster auf VMware unterstützt OIDC als einen der Authentifizierungsmechanismen 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 Nutzerkonten verwenden.

Es gibt zwei Möglichkeiten, Konten zu autorisieren:

  • Sie können den OIDC-Ablauf mit dem Google Cloud CLI initiieren und die Nutzerautorisierung über eine browserbasierte Zustimmungsseite abrufen.

  • Sie initiieren den OIDC-Authentifizierungsvorgang mit der Google Cloud Console.

Vorbereitung

  • In diesem Thema wird davon ausgegangen, dass Sie mit den folgenden Authentifizierungs- und OpenID-Konzepten vertraut sind:

  • Um die Schritte in diesem Bereich ausführen zu können, benötigen Sie einen AD FS-Server und eine Active Directory-Nutzerdatenbank.

  • OIDC wird nur in der AD FS-Version 2016 und höher unterstützt.

  • Für AD FS gilt Folgendes:

    • In AD FS-Versionen vor 5.0 ist das LDAP-Attribut Token-Groups Qualified Names in Ihrer Active Directory-Datenbank der Anforderung groups zugeordnet. Ab Version 5.0 lautet das Attribut Token-Groups Qualified by Domain name.

    • Der AD FS-Server gibt Tokens zurück, die die Nutzer-ID, die Aussteller-ID, die openid- und die groups-Anforderung enthalten. Die Anforderung groups (Group in 5.0) listet die Sicherheitsgruppen auf, denen der Nutzer angehört.

  • Monitorlose Systeme werden nicht unterstützt. Über einen browserbasierten Authentifizierungsvorgang werden Sie zur Zustimmung aufgefordert, um dann Ihr Nutzerkonto zu autorisieren.

  • Zur Authentifizierung über die Google Cloud Console muss jeder Cluster, den Sie für die OIDC-Authentifizierung konfigurieren möchten, bei Google Cloud registriert sein.

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-URLs erstellen

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Sie müssen sowohl für die gcloud CLI als auch die Google Cloud Console Weiterleitungs-URLs erstellen, mit denen der OpenID-Anbieter ID-Tokens zurückgeben kann.

gcloud-CLI-Weiterleitungs-URL

Die Google Cloud CLI ist auf dem lokalen Computer jedes Entwicklers installiert und enthält die gcloud CLI. Sie können für die Weiterleitungs-URL eine Portnummer größer als 1024 angeben:

http://localhost:PORT/callback

Ersetzen Sie PORT durch Ihre Portnummer.

Geben Sie bei der Konfiguration Ihres AD FS-Servers als Weiterleitungs-URL http://localhost:PORT/callback an.

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 bei der Konfiguration Ihres AD FS-Servers als Weiterleitungs-URL https://console.cloud.google.com/kubernetes/oidc an.

AD FS konfigurieren

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Verwenden Sie eine Reihe von AD FS-Verwaltungsassistenten, um Ihren AD FS-Server und die Active Directory-Nutzerdatenbank zu konfigurieren:

  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 die gcloud CLI 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. Die gcloud CLI 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 Nutzer ihre Sicherheitsgruppeninformationen mit der gcloud CLI und der 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.

gcloud CLI 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-AdfsApplicationPermission `
     -ClientRoleIdentifier "CLIENT_ID" `
     -ServerRoleIdentifier SERVER_ROLE_IDENTIFIER `
     -ScopeName "allatclaims", "openid"

Dabei gilt:

  • CLIENT_ID: die Client-ID, die Sie zuvor abgerufen haben

  • SERVER_ROLE_IDENTIFIER: die zuvor eingegebene Anforderungs-ID; die vorgeschlagene ID war token-groups-claim

oidc auf Anthos-Cluster auf VMware-Clustern konfigurieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Zum Konfigurieren der OIDC-Authentifizierung müssen Sie das ClientConfig CRD Ihres Nutzerclusters mit Authentifizierungsdetails für einen Cluster konfigurieren. Dazu bearbeiten Sie das KRM-Standardobjekt vom Typ clientconfig im Namespace kube-public.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Details aus dem ClientConfig CRD werden verwendet, um OIDC für die Google Cloud Console und das Authentication Plug-in für Anthos zu konfigurieren. Die Konfiguration enthält die folgende OIDC-Information:

authentication:
  - name: NAME_STRING
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "https://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

In der folgenden Tabelle werden die Felder des ClientConfig CRD-Objekts oidc beschrieben.

Feld Erforderlich Beschreibung Format
Name Ja Der Name der zu erstellenden OIDC-Konfiguration. String
certificateAuthorityData Nein

Ein base64-codiertes PEM-codiertes Zertifikat für den OIDC-Anbieter. Codieren Sie das Zertifikat, einschließlich der Header, in base64, um den String zu erstellen. Fügen Sie den resultierenden String in certificateAuthorityData als eine Zeile ein.

Beispiel:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==

String
clientID Ja Die ID für die Clientanwendung, die Authentifizierungsanfragen an den OpenID-Anbieter sendet. String
clientSecret Nein Gemeinsames Secret vom OIDC-Clientanwendung und OIDC-Anbieter. String
extraParams Nein

Zusätzliche Schlüssel/Wert-Parameter, die an den OpenID-Anbieter gesendet werden. Wenn Sie eine Gruppe autorisieren, übergeben Sie resource=token-groups-claim.

Wenn Ihr Autorisierungsserver zur Einwilligung auffordert, legen Sie für die Authentifizierung mit Microsoft Azure und Okta extraParams auf prompt=consent fest. Legen Sie für Cloud Identity extraParams auf prompt=consent,access_type=offline fest.

Durch Kommas getrennte Liste
groupsClaim Nein Die JWT-Anforderung, mit der der Anbieter Ihre Sicherheitsgruppen zurückgibt. String
groupPrefix Nein Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn Sie beispielsweise zwei Gruppen mit dem Namen foobar haben, fügen Sie das Präfix gid- hinzu. Die resultierende Gruppe ist gid-foobar. String
issuerURI Ja Die URL, über die Autorisierungsanfragen an Ihren OpenID-Anbieter gesendet werden, z. B. https://example.com/adfs. Der Kubernetes API-Server verwendet diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens festzustellen. Für den URI muss HTTPS verwendet werden. URL String
cloudConsoleRedirectURI Ja Die Weiterleitungs-URL, die Google Cloud console für die Autorisierung verwendet. Der Wert sollte https://console.cloud.google.com/kubernetes/oidc sein. URL String
kubectlRedirectURI Ja Die Weiterleitungs-URL, die kubectl für die Autorisierung verwendet. URL String
scopes Ja Zusätzliche Bereiche, die an den OpenID-Anbieter gesendet werden. Microsoft Azure und Okta benötigen den Bereich offline_access. Durch Kommas getrennte Liste
userClaim Ja Die JWT-Anforderung, die als Nutzername verwendet wird. Je nach OpenID-Anbieter können Sie andere Anforderungen auswählen, beispielsweise E-Mail-Adresse oder Name. Allerdings wird anderen Anforderungen als der E-Mail-Adresse die Aussteller-URL vorangestellt, um Namenskonflikte zu vermeiden. String
userPrefix Nein Das Präfix, das Nutzernamensanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn Sie dieses Feld nicht angeben und userClaim ein anderer Wert als email ist, wird standardmäßig das Präfix issuerurl# verwendet. Sie können mit dem Wert - alle Präfixe deaktivieren. String
proxy Nein Proxyserver, der ggf. für die Methode auth verwendet werden soll. Beispiel: http://user:password@10.10.10.10:8888. String

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ürden Sie die Spezifikation oidc Ihrer Konfigurationsdatei so darstellen:

issuerURL: '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 mithilfe der rollenbasierten Zugriffssteuerung von Kubernetes den authentifizierten Nutzern privilegierten 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, 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

Der Kubernetes API-Server behandelt derzeit einen umgekehrten Schrägstrich als Escape-Zeichen. Wenn der Name des Nutzers oder der Gruppe also einen doppelten umgekehrten Schrägstrich (\\) enthält, wird er vom API-Server beim Parsen des Feldwerts als einzelner \ gelesen. Damit der API-Server die \\ in einem Textfeld richtig interpretiert, müssen Sie diese durch \\\\ ersetzen. Beispielsweise parst der Kubernetes API-Server

"unique_name": "EXAMPLE\\\\cluster-developer" als

"unique_name": "EXAMPLE\\cluster-developer".

Konfigurationsdatei für die Authentifizierung erstellen und verteilen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Nachdem Sie einen Nutzercluster erstellt haben, legen Sie für diesen Cluster eine Konfigurationsdatei für die Authentifizierung an. Sie können in einer einzigen Konfigurationsdatei für die Authentifizierung mehrere Cluster konfigurieren. Sie müssen die Konfigurationsdatei für die Authentifizierung dann allen Nutzern bereitstellen, die sich bei jedem dieser Cluster authentifizieren möchten.

Konfigurationsdatei für die Authentifizierung erstellen

Wenn Sie die Konfigurationsdatei für die Authentifizierung im aktuellen Verzeichnis erstellen möchten, führen Sie den folgenden gkectl-Befehl aus:

gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der Datei kubeconfig Ihres Nutzerclusters. Ihre kubeconfig-Datei wurde erstellt, als Sie Ihren Nutzercluster mit gkectl create cluster erstellt haben.

Ergebnis: Im aktuellen Verzeichnis wird die Konfigurationsdatei für die Authentifizierung mit dem Namen kubectl-anthos-config.yaml erstellt.

Mehrere Cluster zur Konfigurationsdatei für die Authentifizierung hinzufügen

Sie können für mehrere Cluster die Details der Authentifizierungskonfiguration in einer einzigen Konfigurationsdatei für die Authentifizierung speichern.

Mit dem folgenden Befehl haben Sie die Möglichkeit, zusätzliche Authentifizierungsdetails für Nutzercluster mit vorhandenen Details in einer Konfigurationsdatei für die Authentifizierung zusammenzuführen. Bei einer vorhandenen Konfigurationsdatei für die Authentifizierung können Sie zusätzliche Authentifizierungsdetails für Nutzercluster entweder mit den vorhandenen Details zusammenführen oder kombinieren:

  • Führen Sie entweder die zusätzlichen Authentifizierungsdetails für Nutzercluster mit den Details in der vorhandenen Konfigurationsdatei für die Authentifizierung zusammen
  • oder kombinieren Sie die zusätzlichen Details zur Nutzercluster-Authentifizierung mit den vorhandenen Details in einer neuen Datei.

Beispielsweise kann es sein, dass Sie die beiden Konfigurationsdateien für die Authentifizierung anthos-config-1cluster.yaml und anthos-config-3clusters.yaml verwalten müssen, um die Zugriffsanforderungen mehrerer Nutzergruppen in Ihrer Organisation zu erfüllen.

So fügen Sie Ihrer vorhandenen Konfigurationsdatei für die Authentifizierung zusätzliche Nutzercluster hinzu:

  1. Achten Sie darauf, dass jeder Cluster einen eindeutigen Namen hat. Wenn Ihre Cluster gleiche Namen haben, können ihre Details nicht in einer Konfigurationsdatei für die Authentifizierung kombiniert werden. Ein einmal erstellter Cluster kann nicht umbenannt werden.

  2. Führen Sie den folgenden gkectl-Befehl aus, um Konfigurationsdetails zusammenzuführen oder zu kombinieren:

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

    Dabei gilt:

    • USER_CLUSTER_KUBECONFIG gibt die kubeconfig-Datei des Nutzerclusters an, den Sie hinzufügen möchten.

    • IN_AUTH_CONFIG_FILE gibt den Pfad der vorhandenen Konfigurationsdatei für die Authentifizierung an, deren Details Sie mit den zusätzlichen Clusterinformationen zusammenführen möchten.

    • OUT_AUTH_CONFIG_FILE gibt den Pfad der Datei an, in der Sie die zusammengeführte Konfiguration für die Authentifizierung speichern möchten:

      • Geben Sie dieselbe Datei wie unter IN_AUTH_CONFIG_FILE an, wenn Sie die zusätzlichen Clusterinformationen in dieser vorhandenen Datei zusammenführen möchten.
      • Geben Sie einen neuen Pfad und Dateinamen an, wenn die Details der Konfiguration für die Authentifizierung in einer neuen Datei kombiniert werden sollen.

Konfigurationsdatei für die Authentifizierung verteilen

Damit sich Ihre Nutzer bei Ihren Nutzerclustern authentifizieren können, müssen Sie ihnen Zugriff auf eine oder mehrere von Ihnen erstellte Konfigurationsdateien für die Authentifizierung gewähren. In den folgenden Schritten werden der Standarddateiname und der Standardspeicherort verwendet, die von der gcloud CLI erwartet werden. Informationen zur Verwendung alternativer Dateinamen und Speicherorte finden Sie unter Benutzerdefinierte Konfiguration.

Konfigurationsdateien für die Authentifizierung können so verteilt werden:

  • Durch Hosten der Datei unter einer zugänglichen URL. Wenn Sie den Befehl gcloud anthos auth login mit dem Flag --login-config verwenden, ruft die gcloud CLI die Konfigurationsdatei für die Authentifizierung von diesem Speicherort ab.

    Durch Hosten der Datei auf einem sicheren Host. Weitere Informationen zur Verwendung von PEM-Zertifikaten für sicheren HTTPS-Zugriff finden Sie im Flag --login-config-cert der gcloud CLI.

  • Durch manuelles Bereitstellen der Datei für jeden Nutzer. Wenn Nutzer die Datei heruntergeladen haben, müssen sie die Datei am Standardspeicherort und mit dem Standarddateinamen speichern, den die gcloud CLI erwartet.

    Nutzer können beispielsweise mit den folgenden Befehlen die Konfigurationsdatei für die Authentifizierung mit dem Standarddateinamen kubectl-anthos-config.yaml am Standardspeicherort speichern:

    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. Beispiel: kubectl-anthos-config.yaml.

    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. Beispiel: kubectl-anthos-config.yaml.

    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. Beispiel: kubectl-anthos-config.yaml.

  • Übertragen Sie mit Ihren internen Tools die Konfigurationsdatei für die Authentifizierung per Push auf den Computer jedes Nutzers. Sie können beispielsweise Ihre Tools verwenden, um Dateien mit dem Standarddateinamen kubectl-anthos-config.yaml zu deren Standardspeicherorten auf jedem Nutzercomputer per Push zu übertragen:

    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

Benutzerdefinierte Konfiguration

Die gcloud CLI erwartet, dass die Konfigurationsdatei für die Authentifizierung am Standardspeicherort und mit dem Standarddateinamen kubectl-anthos-config.yaml gespeichert wird, wie im vorherigen Abschnitt dargestellt. Sie haben aber die Möglichkeit, die Konfigurationsdatei für die Authentifizierung umzubenennen oder an einem anderen Speicherort zu speichern. Wenn der Name und der Speicherort der Datei vom Standard abweichen, müssen Sie das Flag --login-config an jeden Befehl anhängen, den Sie für die Authentifizierung beim Cluster ausführen. Das zusätzliche Befehls-Flag übergibt den benutzerdefinierten Pfad und den Dateinamen. Weitere Informationen zum Befehls-Flag finden Sie unter Über die gcloud CLI authentifizieren.

gcloud-CLI installieren

Dieser Abschnitt richtet sich sowohl an Clusteradministratoren als auch an Entwickler.

Jeder Entwickler oder Nutzer, der sich bei einem Cluster authentifizieren muss, muss auf seinem eigenen Computer das Google Cloud CLI installieren. Die Anthos-Authentifizierungsbefehle wurden in die gcloud CLI als anthos-auth-Komponente eingebunden.

Alte Plug-ins entfernen

Sie müssen das alte Plug-in deinstallieren, bevor Sie die Komponente anthos-auth der gcloud CLI verwenden können. Mit dem folgenden Befehl können Sie prüfen, ob eines der bisherigen kubectl-basierten Plug-ins auf Ihrem Computer vorhanden ist:

kubectl anthos version

  • Wenn der Befehl die Meldung Error: unknown command "anthos" for "kubectl" ausgibt, wurde kein Plug-in gefunden und Sie können mit dem nächsten Abschnitt fortfahren.

  • Wenn die Version 1.0beta des Plug-ins gefunden wurde, müssen Sie die Plug-in-Binärdatei suchen und löschen. Mit dem folgenden Befehl können Sie den Speicherort feststellen und anschließend die Binärdatei von Ihrem Computer entfernen:

    kubectl plugin list

gcloud CLI und die gcloud-Befehlszeile installieren

Installieren Sie zuerst die gcloud CLI, um die gcloud-Befehlszeile zu installieren:

  1. Installieren Sie die gcloud CLI, aber überspringen Sie den Befehl gcloud init.

  2. Führen Sie die folgenden Befehle aus, um die Komponente anthos-auth zu installieren:

    gcloud components update
    gcloud components install anthos-auth
  3. Führen Sie einen der folgenden Befehle aus, um zu prüfen, ob die gcloud CLI installiert wurde:

    gcloud anthos auth
    gcloud anthos auth login

    Ergebnis: Jeder Befehl sollte Details zu den erforderlichen Argumenten und verfügbaren Optionen ausgeben.

Konfigurationsdatei für die Authentifizierung abrufen

Dieser Abschnitt richtet sich an Entwickler.

Ihr Administrator ist dafür verantwortlich, dass Ihre Konfigurationsdatei für die Authentifizierung erstellt und Ihnen dann zur Verfügung gestellt wird. Weitere Informationen finden Sie unter Konfigurationsdatei für die Authentifizierung verteilen.

Standardmäßig verwendet die gcloud CLI einen Standarddateinamen und -speicherort für Ihre Konfigurationsdatei für die Authentifizierung. Wenn Ihnen die Datei manuell zur Verfügung gestellt wurde und auf Ihrem Computer gespeichert werden muss, verwenden Sie die Standardeinstellungen, um die gcloud-Authentifizierungsbefehle zu vereinfachen.

Verwenden Sie die im Folgenden aufgeführten Befehle, um die Konfigurationsdatei für die Authentifizierung an den Standardspeicherort zu kopieren:

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. Beispiel: kubectl-anthos-config.yaml.

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. Beispiel: kubectl-anthos-config.yaml.

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. Beispiel: kubectl-anthos-config.yaml.

Wenn Sie einen anderen Dateinamen oder Speicherort verwenden möchten, können Sie dafür das Flag --login-config in jede Authentifizierungsanfrage einfügen. Weitere Informationen zur Verwendung des Befehls gcloud anthos auth login finden Sie im folgenden Abschnitt.

Bei Nutzerclustern authentifizieren

Dieser Abschnitt richtet sich an Entwickler.

Nachdem die gcloud CLI auf Ihrem Computer installiert wurde und der Administrator Ihnen die Konfigurationsdatei für die Authentifizierung zur Verfügung gestellt hat, können Sie sich entweder über die gcloud CLI oder über die Google Cloud Console bei Ihren Clustern authentifizieren.

Über die gcloud-CLI authentifizieren

Zum Authentifizieren bei Ihren Clustern verwenden Sie gcloud-Befehle.

  1. Führen Sie den Befehl gcloud anthos auth login aus, um den Authentifizierungsvorgang zu starten:

    gcloud anthos auth login \
     --cluster CLUSTER_NAME \
     --user USER_NAME \
     --login-config AUTH_CONFIG_FILE_PATH \
     --login-config-cert CA_CERT_PEM_FILE \
     --kubeconfig USER_CLUSTER_KUBECONFIG

    Dabei gilt:

    • CLUSTER_NAME ist optional und gibt den Namen des Nutzerclusters an. Wenn dieses Flag weggelassen wird, werden Sie aufgefordert, einen der Nutzercluster auszuwählen, die in Ihrer Konfigurationsdatei für die Authentifizierung angegeben sind.

    • USER_NAME ist optional und gibt den Nutzernamen für die in der kubeconfig-Datei gespeicherten Anmeldedaten an. Der Standardwert ist CLUSTER_NAME-anthos-default-user.

    • AUTH_CONFIG_FILE_PATH ist optional und gibt den benutzerdefinierten Pfad oder die URL an, unter dem bzw. unter der die Konfigurationsdatei für die Authentifizierung gespeichert ist oder gehostet wird. Sie können diesen Parameter weglassen, wenn sich die Datei am Standardspeicherort befindet. Beispiel: --login-config /path/to/custom/authentication-config.yaml.

    • CA_CERT_PEM_FILE ist optional und gibt den Pfad zu einer PEM-Zertifikatsdatei von Ihrer Zertifizierungsstelle an. Wenn Ihre Konfigurationsdatei für die Authentifizierung sicher gehostet wird, können Sie über eine HTTPS-Verbindung auf die Datei zugreifen. Beispiel: --login-config-cert my-cert.pem.

    • USER_CLUSTER_KUBECONFIG ist optional und gibt den benutzerdefinierten Pfad zur kubeconfig-Datei Ihres Nutzerclusters an. Die OIDC-ID-Tokens, die von Ihrem OpenID-Anbieter zurückgegeben werden, sind in der kubeconfig-Datei gespeichert.

      Verwenden Sie dieses Flag, wenn sich die kubeconfig-Datei nicht am Standardspeicherort befindet. Wird dieses Flag nicht angegeben, wird am Standardspeicherort eine neue kubeconfig-Datei erstellt. Beispiel: --kubeconfig /path/to/custom.kubeconfig.

    Beispiele:

    • Bei einem bestimmten Cluster authentifizieren:

      gcloud anthos auth login --cluster my-production-cluster
      
    • Mithilfe einer Eingabeaufforderung den Cluster für die Authentifizierung auswählen:

      gcloud anthos auth login
      

      Ergebnis:

      Please use the --cluster flag to specify a cluster from the list below:
      Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml
      1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443
      2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443
      3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
      
    • Gehostete Konfigurationsdatei für die Authentifizierung verwenden:

      gcloud anthos auth login \
       --cluster my-production-cluster \
       --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
       --login-config-cert my-cert.pem
      
  2. Geben Sie im browserbasierten Zustimmungsbildschirm Ihre Anmeldedaten ein.

  3. Führen Sie einen kubectl-Befehl aus, um Details zu Ihrem Cluster abzurufen und zu prüfen, ob die Authentifizierung erfolgreich war. Beispiel:

    kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ergebnis: Die kubeconfig-Datei enthält jetzt ein ID-Token, das von Ihren kubectl-Befehlen zur Authentifizierung beim Kubernetes API-Server auf Ihrem Nutzercluster verwendet wird.

SSH zur Authentifizierung von einen Remote-Computer aus verwenden

Angenommen, Sie möchten eine SSH-Verbindung zu einem Remote-Computer herstellen und sich von diesem aus bei einem Nutzercluster authentifizieren. Dazu muss sich Ihre Konfigurationsdatei für die Authentifizierung auf dem Remote-Computer befinden und Sie müssen Ihren Open-ID-Anbieter von Ihrem lokalen Computer aus erreichen können.

Führen Sie auf Ihrem lokalen Computer den folgenden Befehl aus:

ssh USER_NAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Dabei gilt:

  • USER_NAME und REMOTE_MACHINE sind die Standardwerte, die für die Anmeldung mit SSH verwendet werden.

  • LOCAL_PORT ist ein offener Port Ihrer Wahl auf Ihrem lokalen Computer, über den Sie auf den Remote-Computer zugreifen.

  • REMOTE_PORT ist der Port, den Sie für Ihre OIDC-Weiterleitungs-URL konfiguriert haben. Diesen Port finden Sie im Feld kubectlRedirectURI Ihrer Konfigurationsdatei für die Authentifizierung.

Führen Sie in Ihrer SSH-Shell den folgenden Befehl aus, um die Authentifizierung zu starten:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

Dabei ist AUTH_CONFIG_FILE der Pfad Ihrer Konfigurationsdatei für die Authentifizierung auf dem Remote-Computer.

Geben Sie auf Ihrem lokalen Computer in einem Browser http://localhost:LOCAL_PORT/login ein und schließen Sie den OIDC-Anmeldevorgang ab.

Die kubeconfig-Datei auf Ihrem Remote-Computer enthält jetzt das Token, das Sie für den Zugriff auf den Nutzercluster benötigen.

Prüfen Sie in der SSH-Shell, ob Sie Zugriff auf den Nutzercluster haben:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Über die Google Cloud Console authentifizieren

Starten Sie in der Google Cloud Console den Authentifizierungsvorgang auf der Seite "Kubernetes-Cluster":

  1. Öffnen Sie die Google Cloud Console.

    Zur Seite „Kubernetes-Cluster“

  2. Suchen Sie in der Liste Ihre Anthos-Cluster auf VMware-Cluster und klicken Sie dann auf Anmelden.

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

    Sie werden zu Ihrem Identitätsanbieter weitergeleitet. Dort müssen Sie sich bei der Google Cloud Console anmelden, die auf Ihr Konto zugreift, und sich mit diesem Zugriff einverstanden erklären. Anschließend werden Sie wieder zurück zur Seite Kubernetes-Cluster in der Google Cloud Console geleitet.

Fehlerbehebung bei der OIDC-Konfiguration

Prüfen Sie die folgenden Verhaltensweisen und Fehler zur Behebung von OIDC-Problemen:

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 der anbieterspezifischen Anleitung, um den Anbieter oder Ihren Cluster richtig 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 möglicherweise auf, wenn der Autorisierungsserver zur Zustimmung auffordert, der erforderliche Authentifizierungsparameter jedoch nicht angegeben wurde. Geben Sie den Parameter prompt=consent im Feld oidc: extraparams der Anthos-Cluster auf VMware-Konfigurationsdatei an und generieren Sie die Clientauthentifizierungsdatei mit dem Flag --extra-params prompt=consent neu.

Nächste Schritte