Am 29. Oktober wurde eine neue Version von Anthos-Cluster auf AWS (GKE in AWS) veröffentlicht. Weitere Informationen siehe Versionshinweise.

Mit OpenID Connect (OIDC) authentifizieren

Erfahren Sie, wie Sie Anthos-Cluster in AWS (GKE on AWS) mit OpenID Connect (OIDC) für die Authentifizierung bei Nutzerclustern konfigurieren. In diesem Thema wird der Prozess zur Konfiguration von Anthos-Cluster auf AWS (GKE on AWS) mit einem beliebigen OpenID-Anbieter behandelt.

Informationen zum Upgrade eines Clusters auf Kubernetes 1.21, der die OIDC-Authentifizierung verwendet, finden Sie unter Upgrade auf Version 1.21.

Eine Übersicht über die Anthos-Cluster auf der AWS-Authentifizierung finden Sie unter Authentifizierung.

Übersicht

Anthos-Cluster in AWS unterstützen 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 Nutzerkonten nutzen.

Hinweis

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

  • Das Cloud SDK und das gcloud-Befehlszeilentool müssen auf dem lokalen Computer jedes Entwicklers installiert sein.

  • Monitorlose Systeme werden nicht unterstützt. Zur Authentifizierung müssen Sie einen Browser auf dem lokalen Computer öffnen, auf dem das gcloud-Tool ausgeführt wird. Der Browser fordert Sie dann auf, 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.

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.

Weiterleitungs-URLs erstellen

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Der OpenID-Anbieter verwendet Weiterleitungs-URLs, um ID-Tokens zurückzugeben. Sie müssen Weiterleitungs-URLs für das gcloud-Tool und die Cloud Console erstellen.

Weiterleitungs-URL für das gcloud-Tool festlegen

Wenn Sie Ihren OpenID-Anbieter konfigurieren, geben Sie die Weiterleitungs-URL für die Befehlszeile als http://localhost:PORT/callback an.

Ersetzen Sie PORT durch eine Portnummer größer als 1024.

Weiterleitungs-URL für die Cloud Console festlegen

Die Weiterleitungs-URL für die Cloud Console lautet:

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

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

Clientanwendungen beim OpenID-Anbieter registrieren

Dieser Abschnitt richtet sich an Organisationsadministratoren.

Bevor Ihre Entwickler das gcloud-Befehlszeilentool oder die Cloud Console bei Ihrem OpenID-Anbieter verwenden können, müssen Sie diese beiden Clients beim OpenID-Anbieter registrieren. Die Registrierung umfasst folgende Schritte:

  • Informieren Sie sich über den Aussteller-URI Ihres Anbieters. Das gcloud-Tool oder die Cloud Console senden Authentifizierungsanfragen an diesen URI.

  • Konfigurieren Sie Ihren Anbieter mit der Weiterleitungs-URL, einschließlich Ihrer Portnummer, für das gcloud-Tool.

  • Konfigurieren Sie Ihren Anbieter mit der Weiterleitungs-URL https://console.cloud.google.com/kubernetes/oidc für die Cloud Console.

  • Erstellen Sie eine einzelne Client-ID, mit der Ihr Anbieter sowohl das gcloud-Befehlszeilentool als auch die Cloud Console identifiziert.

  • Erstellen Sie einen einzelnen Clientschlüssel, mit dem das gcloud-Tool und die Cloud Console beim Authentifizieren beim OpenID-Anbieter authentifiziert werden.

  • Erstellen Sie einen benutzerdefinierten Bereich, mit dem das gcloud-Tool oder die Cloud Console die Sicherheitsgruppen des Nutzers anfordern können.

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

Cluster konfigurieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Zum Konfigurieren der OIDC-Authentifizierung müssen Sie die AWSCluster-Ressource Ihres Nutzerclusters mit Authentifizierungsdetails für einen Cluster konfigurieren. Details aus dem AWSCluster werden verwendet, um OIDC für die Cloud Console und das Authentifizierungs-Plug-in für Anthos zu konfigurieren. Die Konfiguration enthält die folgende OIDC-Information:

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

Authentifizierungsfelder

In der folgenden Tabelle sind die Felder des Objekts authentication.awsIAM.adminIdentityARNs beschrieben.

In der folgenden Tabelle sind die Felder des Objekts "oidc" beschrieben.
Feld Erforderlich Beschreibung Format
adminIdentityARNs Ja, wenn OIDC konfiguriert wird. ARN (Amazon Resource Name) der AWS IAM-Identitäten (Nutzer oder Rollen) hat Clusteradministrator-Zugriff auf AWS gewährt. Beispiel: arn:aws:iam::123456789012:group/Developers String
Feld Erforderlich Beschreibung Format
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 von 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 zum Beispiel zwei Gruppen mit dem Namen foobar ein Präfix gid- hinzufügen, ist die Ergebnisgruppe 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
kubectlRedirectURI Ja Die für die Autorisierung verwendete Weiterleitungs-URL "kubectl". 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 Nein 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. 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.
  • Die Verwendung von E-Mail-Adressen kann 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 wird) führen.

Anstatt Nutzer-IDs zuzuweisen, empfehlen wir Gruppenrichtlinien, die sowohl persistent als auch einfacher zu prüfen sind.

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 sieht die oidc-Spezifikation Ihrer Konfigurationsdatei so aus:

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Nachdem Sie den Nutzercluster erstellt haben, verwenden Sie die rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes, um den authentifizierten Nutzern autorisierten Zugriff gewähren.

Im folgenden Beispiel erstellen Sie eine ClusterRole, die ihren Nutzern Lesezugriff auf die Secrets des Clusters gewährt, und eine ClusterRoleBinding-Ressource, um die Rolle an die authentifizierte Gruppe zu binden.

  1. Definieren Sie eine ClusterRole. Kopieren Sie das folgende YAML-Manifest in eine Datei mit dem Namen secret-reader-role.yaml:

    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"]
    
  2. Definieren Sie eine ClusterRoleBinding. Kopieren Sie das folgende YAML-Manifest in eine Datei mit dem Namen secret-reader-admins.yaml:

    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
    
  3. Wenden Sie secret-reader-role.yaml und secret-reader-admins.yaml mit kubectl auf Ihren Cluster an.

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl apply -f secret-reader-role.yaml && \
      kubectl apply -f secret-reader-admins.yaml
    

    Nutzer, die in read-secrets-admins Zugriff erhalten, haben jetzt Lesezugriff auf Secrets in Ihrem Cluster.

Anmeldekonfiguration erstellen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Nachdem Sie einen Nutzercluster erstellt haben, müssen Sie mithilfe von gcloud anthos create-login-config eine Konfigurationsdatei für den Cluster erstellen.

  1. Verwenden Sie im anthos-aws-Verzeichnis anthos-gke, um den Kontext zu Ihrem Nutzercluster zu wechseln.

    cd anthos-aws
    env HTTPS_PROXY=http://localhost:8118 \
      anthos-gke aws clusters get-credentials CLUSTER_NAME
    Ersetzen Sie CLUSTER_NAME durch den Nutzerclusternamen.

  2. Erstellen Sie die Konfiguration mit gcloud anthos.

    gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
    

    Ersetzen Sie usercluster-kubeconfig durch den Pfad zur Datei kubeconfig Ihres Nutzerclusters. Unter Linux und macOS befindet sich diese Datei standardmäßig unter ~/.kube/config.

Mit diesem Befehl wird eine Datei (kubectl-anthos-config.yaml) mit den Konfigurationsinformationen generiert, die Ihre Entwickler zur Authentifizierung beim Cluster mit dem gcloud-Tool verwenden. Sie sollten diese Datei nicht ändern.

Weitere Informationen zum Inhalt von kubectl-anthos-config.yaml finden Sie im Anhang.

Anmeldekonfiguration verteilen

Verteilen Sie die Konfigurationsdatei an Nutzer, die sich bei Ihren Nutzerclustern authentifizieren müssen. Sie haben folgende Möglichkeiten, um die Konfiguration zu verteilen:

  • Datei im Standardverzeichnis platzieren
  • Datei sicher verteilen
  • Datei auf einem HTTPS-Server hosten

Standardverzeichnisse für die Anmeldekonfiguration

Dies sind die Standardspeicherorte zum Speichern der Konfigurationsdatei für die einzelnen Betriebssysteme:

Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml, wobei $HOME das Basisverzeichnis des Nutzers ist.
macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, wobei $HOME das Basisverzeichnis des Nutzers ist.
Windows
%APPDATA%/google/anthos/kubectl-anthos-config.yaml, wobei %APPDATA% das Anwendungsdatenverzeichnis des Nutzers ist.

Nach dem Verteilen der Anmeldekonfiguration können Ihre Entwickler das gcloud-Tool für den Zugriff auf den Cluster konfigurieren.

Cluster nach dem Upgrade auf Kubernetes 1.21 ändern

Nachdem Sie Ihren Cluster auf Kubernetes 1.21 aktualisiert haben, müssen Sie Anthos Identity Service konfigurieren und die OIDC-Informationen aus der Clusterkonfiguration entfernen. Zum Aktualisieren der Konfiguration führen Sie die folgenden Schritte aus:

  1. Führen Sie die Schritte unter Cluster aktualisieren aus.

  2. Verwenden Sie im anthos-aws-Verzeichnis anthos-gke, um den Kontext zu Ihrem Nutzercluster zu wechseln.

    cd anthos-aws
    env HTTPS_PROXY=http://localhost:8118 \
      anthos-gke aws clusters get-credentials CLUSTER_NAME
    Ersetzen Sie CLUSTER_NAME durch den Nutzerclusternamen.

  3. Öffnen Sie das Manifest mit dem AWSCluster in einem Texteditor. Lassen Sie die Datei geöffnet und verwenden Sie die Werte des oidc-Objekts, um die Schritte unter Cluster für Anthos Identity Service konfigurieren auszuführen.

  4. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.

    cd anthos-aws
    anthos-gke aws management get-credentials

  5. Öffnen Sie die YAML-Datei, die Ihren AWSCluster erstellt hat, in einem Texteditor. Wenn Sie Ihre ursprüngliche YAML-Datei nicht haben, können Sie kubectl edit verwenden.

    YAML bearbeiten

    Wenn Sie der Anleitung unter Nutzercluster erstellen gefolgt sind, hat Ihre YAML-Datei den Namen cluster-0.yaml. Öffnen Sie diese Datei in einem Texteditor.

    kubectl edit

    Führen Sie den folgenden Befehl aus, um Ihren AWSCluster mit kubectl edit zu bearbeiten:

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl edit awscluster cluster-name
    

    Ersetzen Sie cluster-name durch Ihren AWSCluster. Führen Sie beispielsweise den folgenden Befehl aus, um den Standardcluster cluster-0 zu bearbeiten:

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl edit awscluster cluster-0
    
  6. Löschen Sie das Objekt oidc aus dem Manifest Ihres Clusters.

  7. Speichern Sie die Datei. Wenn Sie kubectl edit verwenden, wendet kubectl die Änderungen automatisch an. Wenn Sie die YAML-Datei bearbeiten, wenden Sie sie mit dem folgenden Befehl auf Ihren Verwaltungsdienst an:

    env HTTPS_PROXY=http://localhost:8118 \
      kubectl apply -f cluster-0.yaml
    

    Der Verwaltungsdienst aktualisiert dann Ihren AWSCluster.

gcloud für den Zugriff auf den Cluster konfigurieren

Dieser Abschnitt richtet sich an Entwickler oder Clusteradministratoren.

Vorbereitung

Für diesen Abschnitt benötigen Sie Folgendes:

  • Anmeldekonfiguration
  • Eine aktualisierte Version des gcloud-Tools mit den anthos-auth-Komponenten

    gcloud components update
    gcloud components install anthos-auth
    
  • Prüfen Sie, ob das gcloud-Tool erfolgreich installiert wurde. Führen Sie dazu den folgenden Befehl aus. Dieser sollte Details zu den erforderlichen Argumenten und verfügbaren Optionen ausgeben.

    gcloud anthos auth
    

Beim Cluster authentifizieren

So können Sie sich bei Ihrem Cluster authentifizieren:

  • Mit dem gcloud-Tool auf Ihrem lokalen Rechner
  • Mit dem gcloud-Tool auf einem Remotecomputer mit SSH-Tunnel
  • Mit Connect in der Google Cloud Console

gcloud lokal

Verwenden Sie gcloud anthos auth login, um sich mit Ihrer Anmeldekonfiguration bei Ihrem Cluster zu authentifizieren.

Wenn Sie die Anmeldekonfiguration am Standardspeicherort abgelegt und den Clusternamen konfiguriert haben, können Sie gcloud anthos auth login ohne Optionen verwenden. Sie können den Cluster, den Nutzer und andere Authentifizierungsdetails auch mit optionalen Parametern konfigurieren.

Default

gcloud anthos auth login --cluster CLUSTER_NAME

Ersetzen Sie CLUSTER_NAME durch einen vollständig qualifizierten Clusternamen. Beispiel: projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a

Optionale Parameter

gcloud anthos auth login unterstützt die folgenden optionalen Parameter:

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

Die Parameter werden in der folgenden Tabelle beschrieben.

Parameter Beschreibung
cluster Der Name des Clusters, bei dem die Authentifizierung erfolgen soll. Die Standardeinstellung ist der Cluster in "kubectl-anthos-config.yaml".
user Nutzername für Anmeldedaten in kubeconfig. Die Standardeinstellung ist {cluster-name}-anthos-default-user.
login-config Entweder der Pfad zur Konfigurationsdatei, die vom Clusteradministrator für den Entwickler erstellt wurde, oder eine URL, unter der die Datei gehostet wird. Die Standardeinstellung ist kubectl-anthos-config.yaml.
login-config-cert Bei Verwendung einer URL für login-config der Pfad zur CA-Zertifikatsdatei zum Herstellen von HTTPS-Verbindungen.
kubeconfig Pfad zur kubeconfig-Datei, die Tokens enthält. Die Standardeinstellung ist $HOME/.kube/config`.
Probelauf Sie können Ihre Befehlszeilenoptionen testen, ohne Ihre Konfiguration oder Ihren Cluster zu ändern.

Der Befehl gcloud anthos login startet einen Browser, in dem der Nutzer aufgefordert wird, sich mit seinen Unternehmensanmeldedaten anzumelden. Im Browser wird der OIDC-Anmeldedatenaustausch durchgeführt und die relevanten Tokens werden abgerufen. Das gcloud-Tool schreibt dann die Tokens in eine kubeconfig-Datei. kubectl verwendet diese Datei zur Authentifizierung beim Nutzercluster.

Führen Sie einen beliebigen kubectl-Befehl mit der Datei kubeconfig aus, um zu prüfen, ob die Authentifizierung erfolgreich war:

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud-Tunnel

Wenn Sie sich von einem Remotecomputer aus bei einem Nutzercluster authentifizieren möchten, können Sie die Authentifizierung mit einem SSH-Tunnel machen. Damit Sie einen Tunnel verwenden können, muss sich die Konfigurationsdatei für die Authentifizierung auf dem Remotecomputer befinden und Sie müssen den Open ID-Anbieter über Ihren lokalen Computer erreichen.

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

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Dabei gilt:

  • USERNAME durch einen Nutzer, der SSH-Zugriff auf den Remotecomputer hat.

  • REMOTE_MACHINE durch den Hostnamen oder die IP-Adresse des Remotecomputers.

  • LOCAL_PORT ist ein verfügbarer Port auf Ihrem lokalen Computer, den ssh verwendet, um einen Tunnel zum Remotecomputer zu erstellen.

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

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

Ersetzen Sie AUTH_CONFIG_FILE durch den Pfad Ihrer Authentifizierungskonfigurationsdatei auf dem Remotecomputer. Das gcloud-Tool führt einen Webserver auf dem Remotecomputer aus.

Rufen Sie auf einem lokalen Computer im Browser http://localhost:LOCAL_PORT/login auf und folgen Sie dem OIDC-Anmeldeablauf.

Die Datei kubeconfig auf Ihrem Remotecomputer enthält nun das Token für den Zugriff auf den Nutzercluster.

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Console

Sie können sich bei der Google Cloud Console authentifizieren und den Authentifizierungsablauf von der Seite der Kubernetes-Cluster in der Cloud Console aus initiieren:

  1. Öffnen Sie die Cloud Console.

    Zur Seite „Kubernetes-Cluster“

  2. Suchen Sie in der Liste Ihre Anthos-Cluster auf AWS-Cluster und klicken Sie dann auf Login (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 Cloud Console anmelden, die auf Ihr Konto zugreift, und sich damit einverstanden sein. Sie werden dann zur Seite Kubernetes-Cluster in der Cloud Console zurückgeleitet.

OIDC-Konfiguration aktualisieren

Aktualisieren Sie die OIDC-Konfiguration in Ihrem Cluster mit dem Befehl kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

Das kubectl-Tool lädt die ClientConfig-Ressource in Ihren Standard-Editor. Speichern Sie die Datei, um die Konfiguration zu aktualisieren. Das kubectl-Tool aktualisiert die ClientConfig-Ressource in Ihrem Cluster.

Informationen zum Inhalt der ClientConfig-Ressource finden Sie im folgenden Abschnitt.

Anhang: Beispiel für die Anmeldekonfiguration

Es folgt ein Beispiel für kubectl-anthos-config.yaml. Es dient zum besseren Verständnis des Inhalts. Die Datei sollte immer mit gcloud anthos create-login-config generiert werden.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Erläuterungen zu den Feldinhalten finden Sie unter Authentifizierungsfelder.

Nächste Schritte

Stellen Sie Ihre erste Arbeitslast in Anthos-Clustern auf AWS bereit.