Das in dieser Dokumentation beschriebene Produkt Anthos-Cluster in AWS (vorherige Generation) befindet sich jetzt im Wartungsmodus. Alle neuen Installationen müssen Anthos-Cluster in AWS der aktuellen Generation verwenden.

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:
Die Google Cloud-CLI muss auf dem lokalen Computer jedes Entwicklers installiert werden.
Monitorlose Systeme werden nicht unterstützt. Zur Authentifizierung müssen Sie einen Browser auf dem lokalen Computer öffnen, auf dem die gcloud CLI 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 sowohl für die gcloud CLI als auch für die Google Cloud Console erstellen.

Weiterleitungs-URL für die gcloud-CLI 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 Google Cloud Console festlegen

Die Weiterleitungs-URL für die Google 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 die Google Cloud-CLI 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:

Informieren Sie sich über den Aussteller-URI Ihres Anbieters. Die gcloud CLI oder die Google Cloud Console senden Authentifizierungsanfragen an diesen URI.
Konfigurieren Sie Ihren Anbieter mit der Weiterleitungs-URL, einschließlich Ihrer Portnummer, für die gcloud CLI.
Konfigurieren Sie Ihren Anbieter mit der Weiterleitungs-URL https://console.cloud.google.com/kubernetes/oidc für die Google Cloud Console.
Erstellen Sie eine einzelne Client-ID, mit der Ihr Anbieter sowohl die Google Cloud-CLI als auch die Google Cloud Console identifiziert.
Erstellen Sie einen einzelnen Clientschlüssel, mit dem die gcloud CLI und die Google Cloud Console beim Authentifizieren beim OpenID-Anbieter authentifiziert werden.
Richten Sie einen benutzerdefinierten Bereich ein, mit dem die gcloud CLI oder die Google Cloud Console die Sicherheitsgruppen des Nutzers anfordern kann.
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 Google 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 werden die Felder des „oidc“-Objekts 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.

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"]

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

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.

Verwenden Sie im Verzeichnis anthos-aws 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.
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 der gcloud CLI verwenden. Sie sollten diese Datei nicht ändern.

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

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 die gcloud CLI 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:

Führen Sie die Schritte unter Cluster aktualisieren aus.
Verwenden Sie im Verzeichnis anthos-aws 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.
Ö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.
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
```
Hinweis: anthos-gke verwendet die Anmeldedaten, die Sie bei der Ausführung von aws configure angegeben haben.
Ö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
```
Löschen Sie das Objekt oidc aus dem Manifest Ihres Clusters.
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 der gcloud CLI mit den Komponenten anthos-auth.
```
gcloud components update
gcloud components install anthos-auth
```
Prüfen Sie, ob die gcloud-Befehlszeile 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 der gcloud CLI auf Ihrem lokalen Computer.
Mit der gcloud CLI 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.

Standard

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. Die gcloud CLI schreibt die Tokens dann 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

Ersetzen Sie Folgendes:

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. Die gcloud CLI 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 mit der Google Cloud Console authentifizieren. Starten Sie dazu den Authentifizierungsvorgang auf der Seite "Kubernetes-Cluster" in der Google Cloud Console:

Öffnen Sie die Google Cloud Console:

Zur Seite „Kubernetes-Cluster“
Suchen Sie in der Liste Ihre Anthos-Cluster auf AWS-Cluster und klicken Sie dann auf Login (Anmelden).
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. Sie werden dann zur Seite Kubernetes-Cluster in der Google 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"
    proxy: PROXY_URL #Optional
  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.

Weitere Informationen

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

Mit OpenID Connect (OIDC) authentifizieren

Übersicht

Hinweis

Identitäten

OpenID-Anbieter auswählen

Weiterleitungs-URLs erstellen

Weiterleitungs-URL für die gcloud-CLI festlegen

Weiterleitungs-URL für die Google Cloud Console festlegen

Clientanwendungen beim OpenID-Anbieter registrieren

Cluster konfigurieren

Authentifizierungsfelder

Beispiel: Nutzer und Gruppen autorisieren

Anmeldekonfiguration erstellen

Anmeldekonfiguration verteilen

Standardverzeichnisse für die Anmeldekonfiguration

Cluster nach dem Upgrade auf Kubernetes 1.21 ändern

YAML bearbeiten

kubectl edit

gcloud für den Zugriff auf den Cluster konfigurieren

Vorbereitung

Beim Cluster authentifizieren

gcloud lokal

Standard

Optionale Parameter

gcloud-Tunnel

Console

OIDC-Konfiguration aktualisieren

Anhang: Beispiel für die Anmeldekonfiguration

Weitere Informationen