Anthos Clusters on VMware heißt jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Probleme mit der Authentifizierung in Google Distributed Cloud beheben

In diesem Dokument erfahren Sie, wie Sie Authentifizierungsprobleme in Google Distributed Cloud beheben. Es werden allgemeine Informationen und Anleitungen zur Fehlerbehebung sowie spezifische Informationen zu OpenID Connect (OIDC) und Lightweight Directory Access Protocol (LDAP) bereitgestellt.

Für die OIDC- und LDAP-Authentifizierung wird GKE Identity Service verwendet. Bevor Sie GKE Identity Service mit Google Distributed Cloud verwenden können, müssen Sie einen Identitätsanbieter konfigurieren. Wenn Sie noch keinen Identitätsanbieter für GKE Identity Service konfiguriert haben, folgen Sie der Anleitung für einen der folgenden gängigeren Anbieter:

In der Anleitung zur Fehlerbehebung bei Identitätsanbietern für GKE Identity Service erfahren Sie, wie Sie Identitätslogs aktivieren und prüfen und die Verbindung testen.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Allgemeine Fehlerbehebung

Die folgenden Tipps zur Fehlerbehebung können bei allgemeinen Problemen mit der Authentifizierung und Autorisierung mit Google Distributed Cloud helfen. Wenn diese Probleme nicht zutreffen oder Sie Probleme mit OIDC oder LDAP haben, fahren Sie mit dem Abschnitt zur Fehlerbehebung für GKE Identity Service fort.

`gcloud anthos auth` auf dem neuesten Stand halten

Sie können viele häufige Probleme vermeiden, indem Sie prüfen, ob die Komponenten Ihrer gcloud anthos auth-Installation auf dem neuesten Stand sind.

Es müssen zwei Elemente bestätigt werden. Der gcloud anthos auth-Befehl enthält Logik in der Google Cloud CLI-Kernkomponente und eine separat verpackte anthos-auth-Komponente.

So aktualisieren Sie die Google Cloud CLI:
```
gcloud components update
```
So aktualisieren Sie die anthos-auth-Komponente:
```
gcloud components install anthos-auth
```

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 Konfiguration

Wenn die Google Cloud Console die OIDC-Konfiguration aus Ihrem Cluster nicht lesen kann, ist die Schaltfläche LOGIN deaktiviert. Informationen zur Fehlerbehebung bei der OIDC-Konfiguration Ihres Clusters finden Sie im Abschnitt Fehlerbehebung bei OIDC dieses Dokuments.

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.

Aktualisierungstoken fehlt

Das folgende Problem tritt auf, wenn der Autorisierungsserver um eine Einwilligung bittet, aber der erforderliche Authentifizierungsparameter nicht bereitgestellt wurde.

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

Fügen Sie in der ClientConfig-Ressource prompt=consent zum Feld authentication.oidc.extraParams hinzu, um dieses Problem zu beheben. Erstellen Sie dann die Clientauthentifizierungsdatei noch einmal.

Aktualisierungstoken abgelaufen

Das folgende Problem tritt auf, wenn das Aktualisierungstoken in der Datei „kubeconfig“ abgelaufen ist:

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

Führen Sie den Befehl gcloud anthos auth login noch einmal aus, um dieses Problem zu beheben.

Fehler bei gcloud anthos auth login mit `proxyconnect tcp`

Dieses Problem tritt auf, wenn die Konfigurationen der Umgebungsvariablen https_proxy oder HTTPS_PROXY fehlerhaft sind. Wenn in den Umgebungsvariablen https:// angegeben ist, können die GoLang-HTTP-Clientbibliotheken fehlschlagen, wenn der Proxy für die Verarbeitung von HTTPS-Verbindungen mit anderen Protokollen konfiguriert wird, wie etwa SOCK5.

Das folgende Beispiel einer Fehlermeldung kann möglicherweise zurückgegeben werden:

proxyconnect tcp: tls: first record does not look like a TLS handshake

Um dieses Problem zu beheben, ändern Sie die Umgebungsvariablen https_proxy und HTTPS_PROXY so, dass das https:// prefix weggelassen wird. Wenn Sie Windows verwenden, ändern Sie die Systemumgebungsvariablen. Ändern Sie beispielsweise den Wert der Umgebungsvariablen https_proxy von https://webproxy.example.com:8000 in webproxy.example.com:8000.

Clusterzugriff schlägt fehl, wenn von `gcloud anthos auth login` generierte kubeconfig verwendet wird

Dieses Problem tritt auf, wenn der Kubernetes API-Server den Nutzer nicht autorisieren kann. Dies kann auftreten, wenn die entsprechenden RBACs fehlen oder falsch sind oder in der OIDC-Konfiguration für den Cluster ein Fehler auftritt. Möglicherweise wird der folgende Beispielfehler angezeigt:

Unauthorized

So beheben Sie das Problem:

Kopieren Sie in der von gcloud anthos auth login generierten kubeconfig-Datei den Wert von id-token.

kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

Installieren Sie jwt-cli und führen Sie Folgendes aus:
```
jwt ID_TOKEN
```
OIDC-Konfiguration prüfen

Die ClientConfig-Ressource enthält die Felder group und username. Mit diesen Feldern werden die Flags --oidc-group-claim und --oidc-username-claim auf dem Kubernetes API-Server festgelegt. Wenn dem API-Server das Token präsentiert wird, leitet er es an GKE Identity Service weiter, das den extrahierten group-claim und username-claim an den API-Server zurückgibt. Der API-Server prüft anhand der Antwort, ob die entsprechende Gruppe oder der Nutzer über die erforderlichen Berechtigungen verfügt.

Prüfen Sie, ob die für group und user in der ClientConfig-Ressource festgelegten Anforderungen im ID-Token vorhanden sind.
Prüfen Sie die angewendeten RBACs.

Vergewissern Sie sich, dass ein RBAC mit den richtigen Berechtigungen entweder für den mit username-claim angegebenen Nutzer oder für eine der mit group-claim aufgeführten Gruppen aus dem vorherigen Schritt vorhanden ist. Dem Namen des Nutzers bzw. der Gruppe in der RBAC muss das Präfix usernameprefix oder groupprefix vorangestellt werden, das in der ClientConfig-Ressource angegeben ist.

Wenn usernameprefix leer ist und username ein anderer Wert als email ist, wird das Präfix standardmäßig auf issuerurl# gesetzt. Setzen Sie usernameprefix auf -, um Nutzernamenpräfixe zu deaktivieren.

Weitere Informationen zu Nutzer- und Gruppenpräfixen finden Sie unter Mit OIDC authentifizieren.

Hinweis: Der Kubernetes API-Server behandelt derzeit einen umgekehrten Schrägstrich als Escape-Zeichen. Wenn der Name des Nutzers oder der Gruppe \\ enthält, wird er vom API-Server beim Parsen des ID-Tokens als einzelnes \ gelesen. Daher sollte die für diesen Nutzer oder diese Gruppe angewendete Rollenbindung nur einen umgekehrten Schrägstrich enthalten, da andernfalls der Fehler Unauthorized angezeigt werden kann.

Ressource ClientConfig:
```
oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"
```
ID-Token:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}
```
Die folgenden RBAC-Bindungen gewähren dieser Gruppe und diesem Nutzer die Clusterrolle pod-reader. Beachten Sie den einzelnen Schrägstrich im Namensfeld statt des doppelten Schrägstrichs:

ClusterRoleBinding gruppieren:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Nutzer-ClusterRoleBinding:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Prüfen Sie die Serverlogs der Kubernetes API.

Wenn das auf dem Kubernetes API-Server konfigurierte OIDC-Plug-in nicht korrekt gestartet wird, gibt der API-Server bei Erhalt des ID-Tokens den Fehler Unauthorized zurück. Prüfen Sie mit dem folgenden Befehl, ob Probleme mit dem OIDC-Plug-in auf dem API-Server aufgetreten sind:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Ersetzen Sie dabei Folgendes:
- USER_CLUSTER_NAME: Der Name des Nutzerclusters, für den Sie die Logs aufrufen möchten.
- ADMIN_CLUSTER_KUBECONFIG: Die kubeconfig-Datei des Administratorclusters.

Dieses Problem tritt auf, wenn die an gkectl create-login-config übergebene Datei „kubeconfig“ für einen Nutzercluster nicht übergeben wird oder die Ressource ClientConfig bei der Clustererstellung nicht gefunden wurde.

Error getting clientconfig using KUBECONFIG

Prüfen Sie zur Behebung dieses Problems, ob Sie die richtige kubeconfig-Datei für Ihren Nutzercluster haben. Prüfen Sie dann, ob sich die Ressource ClientConfig im Cluster befindet:

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Dieses Problem tritt auf, wenn Sie versuchen, Anmeldekonfigurationsdaten zu schreiben, die einen Clusternamen enthalten, der bereits in der Zieldatei vorhanden ist. Jede Anmeldekonfigurationsdatei muss eindeutige Clusternamen enthalten.

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

Verwenden Sie zum Beheben dieses Problems das Flag --output, um eine neue Zieldatei anzugeben.

Wenn Sie --output nicht angeben, werden die Konfigurationsdaten für die Anmeldung in eine Datei mit dem Namen kubectl-anthos-config.yaml im aktuellen Verzeichnis geschrieben.

Fehlerbehebung bei OIDC

Wenn die OIDC-Authentifizierung für Google Distributed Cloud nicht funktioniert, wurde die OIDC-Spezifikation in der ClientConfig-Ressource in der Regel nicht ordnungsgemäß konfiguriert. Die Ressource ClientConfig bietet eine Anleitung zum Prüfen der Logs und der OIDC-Spezifikation, um die Ursache eines OIDC-Problems zu ermitteln.

In der Anleitung zur Fehlerbehebung bei Identitätsanbietern für GKE Identity Service erfahren Sie, wie Sie Identitätslogs aktivieren und prüfen und die Verbindung testen. Wenn Sie bestätigt haben, dass GKE Identity Service wie erwartet funktioniert, oder ein Problem festgestellt haben, lesen Sie die folgenden Informationen zur OIDC-Fehlerbehebung.

OIDC-Spezifikation im Cluster prüfen

Die OIDC-Informationen für Ihren Cluster werden im ClientConfig-Objekt im Namespace kube-public angegeben.

Verwenden Sie kubectl get, um die OIDC-Ressource für Ihren Nutzercluster zu drucken:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Prüfen Sie die Feldwerte, um sicherzustellen, dass die Spezifikation für Ihren OIDC-Anbieter korrekt konfiguriert ist.
Wenn Sie ein Konfigurationsproblem in der Spezifikation feststellen, konfigurieren Sie OIDC neu.
Wenn Sie das Problem nicht selbst diagnostizieren und lösen können, wenden Sie sich an den Support Google Cloud .

DerGoogle Cloud -Support benötigt die GKE Identity Service-Logs und die OIDC-Spezifikation, um OIDC-Probleme zu diagnostizieren und zu beheben.

Prüfen, ob die OIDC-Authentifizierung aktiviert ist

Bevor Sie die OIDC-Authentifizierung testen, prüfen Sie, ob sie in Ihrem Cluster aktiviert ist.

Prüfen Sie die GKE Identity Service-Logs:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
Die folgende Beispielausgabe zeigt, dass die OIDC-Authentifizierung korrekt aktiviert ist:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Wenn die OIDC-Authentifizierung nicht richtig aktiviert ist, werden Fehler ähnlich dem folgenden Beispiel angezeigt:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Prüfen Sie die gemeldeten Fehler und versuchen Sie, sie zu beheben.

OIDC-Authentifizierung testen

Wenn Sie die OIDC-Funktion verwenden möchten, verwenden Sie eine Workstation mit aktivierter Benutzeroberfläche und aktiviertem Browser. Diese Schritte können nicht über eine textbasierte SSH-Sitzung ausgeführt werden. So testen Sie, ob OIDC in Ihrem Cluster richtig funktioniert:

Laden Sie die Google Cloud CLI herunter.
Führen Sie den folgenden gcloud anthos create-login-config-Befehl aus, um die Anmeldekonfigurationsdatei zu generieren:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Führen Sie den folgenden Befehl aus, um den Nutzer zu authentifizieren:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Ersetzen Sie dabei Folgendes:
- CLUSTER_NAME durch den Namen des Nutzerclusters, mit dem eine Verbindung hergestellt werden soll.
- AUTH_KUBECONFIG durch die neue zu erstellende kubeconfig-Datei, die die Anmeldedaten für den Zugriff auf Ihren Cluster enthält. Weitere Informationen finden Sie unter Beim Cluster authentifizieren.
Im Standardwebbrowser Ihrer lokalen Workstation sollte eine Seite mit einer Einwilligung zur Anmeldung geöffnet werden. Geben Sie in dieser Anmeldeaufforderung gültige Authentifizierungsinformationen für einen Nutzer an.

Nachdem Sie den vorherigen Anmeldeschritt erfolgreich abgeschlossen haben, wird im aktuellen Verzeichnis eine kubeconfig-Datei generiert.
Wenn Sie die neue kubeconfig-Datei mit Ihren Anmeldedaten testen möchten, listen Sie die Pods in Ihrem Nutzercluster auf:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Ersetzen Sie AUTH_KUBECONFIG durch den Pfad zur neuen kubeconfig-Datei, die im vorherigen Schritt generiert wurde.

Die folgende Beispielnachricht wird möglicherweise zurückgegeben, welche angibt, dass Sie sich erfolgreich authentifizieren können, dem Konto jedoch keine rollenbasierten Zugriffssteuerungen (Role-Based Access Controls, RBACs) zugewiesen sind:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

OIDC-Authentifizierungs-Logs prüfen

Wenn Sie sich nicht mit OIDC authentifizieren können, bieten die GKE Identity Service-Logs die relevantesten und nützlichsten Informationen zum Beheben des Problems.

Verwenden Sie kubectl logs, um die Logs von GKE Identity Service zu drucken:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Prüfen Sie die Logs auf Fehler, die Ihnen bei der Diagnose von OIDC-Problemen helfen können.

Die Ressource ClientConfig enthält etwa möglicherweise im Feld issuerURL einen Tippfehler, z. B. htps://accounts.google.com (mit einem fehlenden t in https). Die GKE Identity Service-Logs enthalten dann einen Eintrag wie diesen:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Wenn Sie in den Logs ein Konfigurationsproblem ermitteln, konfigurieren Sie OIDC neu und beheben Sie die Konfigurationsprobleme.
Wenn Sie das Problem nicht selbst diagnostizieren und lösen können, wenden Sie sich an den Support Google Cloud .

DerGoogle Cloud -Support benötigt die GKE Identity Service-Logs und die OIDC-Spezifikation, um OIDC-Probleme zu diagnostizieren und zu beheben.

Häufige OIDC-Probleme

Wenn Probleme mit der OIDC-Authentifizierung auftreten, sehen Sie sich die folgenden häufigen Probleme an. Folgen Sie der Anleitung zur Behebung des Problems.

Für den Dienst „ais“ sind keine Endpunkte verfügbar

Beim Speichern der ClientConfig-Ressource wird die folgende Fehlermeldung zurückgegeben:

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

Dieser Fehler wird durch den fehlerhaften Endpunkt von GKE Identity Service verursacht. Der GKE Identity Service-Pod kann den Validierungs-Webhook nicht bereitstellen.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Pod des GKE Identity Service fehlerhaft ist:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Die folgende Beispielausgabe bedeutet, dass Ihr GKE Identity Service-Pod abstürzt:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Sehen Sie sich die Pod-Ereignisse an, um zu erfahren, warum ein Problem mit dem Pod vorliegt:

kubectl describe pod -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

In der folgenden Beispielausgabe wird ein Berechtigungsfehler beim Abrufen des Bildes angezeigt:

Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
  Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
  Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"

Wenn die Pod-Ereignisse ein Problem melden, fahren Sie mit der Fehlerbehebung in den betroffenen Bereichen fort. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Support Google Cloud .

Fehler beim Lesen der Antwortbytes vom Server

In den GKE Identity Service-Logs werden möglicherweise die folgenden Fehler angezeigt:

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

Diese Netzwerkfehler können in den Logs auf eine der folgenden Arten angezeigt werden:

Treten nur selten im Log auf:Diese seltenen Fehler sind wahrscheinlich nicht das Hauptproblem. Es könnte sich um vorübergehende Netzwerkprobleme handeln.

Das OIDC-Plug-in für GKE Identity Service hat einen Daemon-Prozess, der die OIDC-Discovery-URL alle 5 Sekunden synchronisiert. Wenn die Netzwerkverbindung instabil ist, schlägt diese ausgehende Anfrage möglicherweise fehl. Gelegentliche Fehler wirken sich nicht auf die OIDC-Authentifizierung aus. Die vorhandenen im Cache gespeicherten Daten können wiederverwendet werden.

Wenn Sie weitere Fehler in den Logs finden, fahren Sie mit den zusätzlichen Schritten zur Fehlerbehebung fort.
Sie werden kontinuierlich im Log angezeigt oder GKE Identity Service erreicht den bekannten Endpunkt nie erfolgreich: Diese konstanten Probleme weisen auf ein Konnektivitätsproblem zwischen GKE Identity Service und Ihrem OIDC-Identitätsanbieter hin.

Die folgenden Schritte zur Fehlerbehebung können Ihnen dabei helfen, diese Verbindungsprobleme zu diagnostizieren:
1. Achten Sie darauf, dass die ausgehenden Anfragen von GKE Identity Service nicht von einer Firewall blockiert werden.
2. Prüfen Sie, ob der Identitätsanbieterserver ordnungsgemäß ausgeführt wird.
3. Prüfen Sie, ob die OIDC-Aussteller-URL in der ClientConfig-Ressource richtig konfiguriert ist.
4. Wenn Sie das Proxy-Feld in der ClientConfig-Ressource aktiviert haben, prüfen Sie den Status oder das Log Ihres ausgehenden Proxyservers.
5. Testen Sie die Verbindung zwischen Ihrem GKE Identity Service-Pod und dem OIDC-Identitätsanbieterserver.

Sie müssen auf dem Server angemeldet sein (nicht autorisiert)

Wenn Sie versuchen, sich mit der OIDC-Authentifizierung anzumelden, erhalten Sie möglicherweise die folgende Fehlermeldung:

  You must be logged in to the server (Unauthorized)

Bei diesem Fehler handelt es sich um ein allgemeines Problem mit der Kubernetes-Authentifizierung, das keine zusätzlichen Informationen liefert. Dieser Fehler weist jedoch auf ein Konfigurationsproblem hin.

Lesen Sie die vorherigen Abschnitte OIDC-Spezifikation im Cluster prüfen und ClientConfig-Ressource konfigurieren, um das Problem zu ermitteln.

Webhook-Anfrage für Authenticator konnte nicht gesendet werden

Im GKE Identity Service-Log wird möglicherweise der folgende Fehler angezeigt:

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

Dieser Fehler gibt an, dass der API-Server keine Verbindung zum GKE Identity Service-Pod herstellen kann.

Führen Sie den folgenden curl-Befehl aus, um zu prüfen, ob der GKE Identity Service-Endpunkt extern erreichbar ist:
```
curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
  https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
Ersetzen Sie APISERVER_HOST durch die Adresse Ihres API-Servers.

Die erwartete Antwort ist ein HTTP 400-Statuscode. Wenn es bei der Anfrage zu einer Zeitüberschreitung kommt, starten Sie den GKE Identity Service-Pod neu. Wenn der Fehler weiterhin auftritt, liegt dies daran, dass der HTTP-Server von GKE Identity Service nicht starten kann. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich bitte an den Support. Google Cloud

Anmelde-URL nicht gefunden

Das folgende Problem tritt auf, wenn die Google Cloud Console den Identitätsanbieter nicht erreichen kann. Ein Anmeldeversuch wird auf eine Seite mit einem URL not found-Fehler weitergeleitet.

Versuchen Sie Folgendes, um dieses Problem zu beheben: Versuchen Sie nach jedem Schritt noch einmal, sich anzumelden:

Wenn der Identitätsanbieter nicht über das öffentliche Internet erreichbar ist, aktivieren Sie den OIDC-HTTP-Proxy, um sich über die Google Cloud Console anzumelden. Bearbeiten Sie die benutzerdefinierte ClientConfig-Ressource und legen Sie useHTTPProxy auf true fest:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Wenn der HTTP-Proxy aktiviert ist und es weiterhin zu diesem Fehler kommt, ist möglicherweise ein Problem beim Start des Proxys aufgetreten. So rufen Sie die Logs des Proxys auf:
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Selbst wenn Ihr Identitätsanbieter eine bekannte Zertifizierungsstelle hat, müssen Sie für den erfolgreichen Start des HTTP-Proxys einen Wert für oidc.caPath in Ihrer benutzerdefinierten ClientConfig-Ressource angeben.
Wenn der Autorisierungsserver um Ihre Einwilligung bittet undSie die Parameter extraparam prompt=consent nicht hinzugefügt haben, bearbeiten Sie die benutzerdefinierte Ressource ClientConfig und fügen Sie prompt=consent zu den Parametern extraparams hinzu:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Wenn die Konfigurationseinstellungen für den Speicherdienst geändert werden, müssen Sie sich möglicherweise explizit von vorhandenen Sitzungen abmelden. Rufen Sie in der Google Cloud Console die Seite mit den Clusterdetails auf und wählen Sie Abmelden aus.

Fehlerbehebung bei LDAP

Wenn Probleme mit der LDAP-Authentifizierung auftreten, prüfen Sie, ob Sie Ihre Umgebung gemäß einem der entsprechenden Konfigurationsdokumente eingerichtet haben:

Außerdem müssen Sie das LDAP-Dienstkonto-Secret ausfüllen und die ClientConfig-Ressource so konfigurieren, dass die LDAP-Authentifizierung aktiviert wird.

In der Anleitung zur Fehlerbehebung bei Identitätsanbietern für GKE Identity Service erfahren Sie, wie Sie Identitätslogs aktivieren und prüfen und die Verbindung testen. Nachdem Sie bestätigt haben, dass GKE Identity Service wie erwartet funktioniert, oder ein Problem festgestellt haben, lesen Sie die folgenden Informationen zur LDAP-Fehlerbehebung.

Prüfen, ob die LDAP-Authentifizierung aktiviert ist

Bevor Sie die LDAP-Authentifizierung testen, prüfen Sie, ob sie in Ihrem Cluster aktiviert ist.

Prüfen Sie die GKE Identity Service-Logs:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
Die folgende Beispielausgabe zeigt, dass die LDAP-Authentifizierung korrekt aktiviert ist:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Wenn die LDAP-Authentifizierung nicht richtig aktiviert ist, werden Fehler ähnlich dem folgenden Beispiel angezeigt:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Prüfen Sie die gemeldeten Fehler und versuchen Sie, sie zu beheben.

LDAP-Authentifizierung testen

Wenn Sie die LDAP-Funktion verwenden möchten, verwenden Sie eine Workstation mit aktivierter Benutzeroberfläche und aktiviertem Browser. Diese Schritte können nicht über eine textbasierte SSH-Sitzung ausgeführt werden. So testen Sie, ob die LDAP-Authentifizierung in Ihrem Cluster ordnungsgemäß funktioniert:

Laden Sie die Google Cloud CLI herunter.
Führen Sie den folgenden gcloud anthos create-login-config-Befehl aus, um die Anmeldekonfigurationsdatei zu generieren:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.
Führen Sie den folgenden Befehl aus, um den Nutzer zu authentifizieren:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Ersetzen Sie dabei Folgendes:
- CLUSTER_NAME durch den Namen des Nutzerclusters, mit dem eine Verbindung hergestellt werden soll.
- AUTH_KUBECONFIG durch die neue zu erstellende kubeconfig-Datei, die die Anmeldedaten für den Zugriff auf Ihren Cluster enthält. Weitere Informationen finden Sie unter Beim Cluster authentifizieren.
Im Standardwebbrowser Ihrer lokalen Workstation sollte eine Seite mit einer Einwilligung zur Anmeldung geöffnet werden. Geben Sie in dieser Anmeldeaufforderung gültige Authentifizierungsinformationen für einen Nutzer an.

Nachdem Sie den vorherigen Anmeldeschritt erfolgreich abgeschlossen haben, wird im aktuellen Verzeichnis eine kubeconfig-Datei generiert.
Wenn Sie die neue kubeconfig-Datei mit Ihren Anmeldedaten testen möchten, listen Sie die Pods in Ihrem Nutzercluster auf:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Ersetzen Sie AUTH_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Nutzerclusters, die im vorherigen Schritt generiert wurde.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Häufige LDAP-Probleme

Wenn Probleme mit der LDAP-Authentifizierung auftreten, sehen Sie sich die folgenden häufigen Probleme an. Folgen Sie der Anleitung zur Behebung des Problems.

Nutzer können sich nicht authentifizieren, wenn ihr CN Kommas enthält

Wenn Sie LDAP verwenden, können Probleme auftreten, bei denen sich Nutzer nicht authentifizieren können, weil ihr CN ein Komma enthält, z. B. CN="a,b". Wenn Sie das Debugging-Log für GKE Identity Service aktivieren, wird die folgende Fehlermeldung angezeigt:

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

Dieses Problem tritt auf, weil das LDAP-Plug-in von GKE Identity Service das Komma doppelt maskiert. Dieses Problem tritt nur in den Versionen Google Distributed Cloud 1.13 und niedriger auf.

Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:

Aktualisieren Sie Ihren Cluster auf Google Distributed Cloud 1.13 oder höher.
Wählen Sie anstelle des CN ein anderes identifierAttribute aus, z. B. sAMAccountName.
Entfernen Sie die Kommas aus dem CN in Ihrem LDAP-Verzeichnis.

Authentifizierungsfehler mit der Google Cloud CLI 1.4.2

Wenn Sie die Google Cloud CLI anthos-auth 1.4.2 verwenden, wird beim Ausführen des Befehls gcloud anthos auth login möglicherweise die folgende Fehlermeldung angezeigt:

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

Im GKE Identity Service-Log wird außerdem der folgende Fehler angezeigt:

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

Prüfen Sie, ob Sie die Google Cloud CLI anthos-auth Version 1.4.2 verwenden:
```
gcloud anthos auth version
```
In der folgenden Beispielausgabe ist zu sehen, dass die Version 1.4.2 lautet:
```
Current Version: v1.4.2
```
Wenn Sie die Google Cloud CLI anthos-auth Version 1.4.2 verwenden, führen Sie ein Upgrade auf Version 1.4.3 oder höher durch.

Allgemeine Probleme

In diesem Abschnitt werden häufige Authentifizierungsprobleme und deren Behebung beschrieben.

Kein Zugriff mehr auf die Administrator-Workstation aufgrund eines Fehlers beim SSH-Schlüssel `permission denied`

Der folgende Fehler tritt auf, wenn Sie versuchen, eine Verbindung zu Ihrer Administrator-Workstation herzustellen und eine "Permission denied"-Meldung wie im folgenden Beispiel erhalten:

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

Dieser Fehler tritt auf, wenn Sie beim Herstellen einer SSH-Verbindung zur Administrator-Workstation einen falschen privaten Schlüssel oder keinen Schlüssel verwenden.

Suchen Sie den richtigen SSH-Schlüssel und verwenden Sie ihn, um das Problem zu beheben. Wenn Sie den richtigen SSH-Schlüssel nicht finden, generieren Sie mit den folgenden Schritten ein neues SSH-Schlüsselpaar für die Administrator-Workstation:

Erstellen Sie eine temporäre Rettungs-VM. Diese Rettungs-VM muss sich mit demselben Netzwerk und Datenspeicher verbinden wie die aktuelle VM der Administrator-Workstation.
Schalten Sie die VM der Administrator-Workstation und die Rettungs-VM aus.
Hängen Sie das Datenlaufwerk der Administrator-Workstation-VM an die Rettungs-VM an. Das Datenlaufwerk hat in der Regel eine Größe von 512 MB, sofern Sie in der Konfigurationsdatei der Administrator-Workstation eine andere Laufwerkgröße angegeben haben, die sich vom Bootlaufwerk unterscheidet.
Schalten Sie die Rettungs-VM ein.
Stellen Sie eine SSH-Verbindung zur Rettungs-VM her:
Erstellen Sie auf Ihrem lokalen Computer ein neues SSH-Schlüsselpaar.
Kopieren Sie den neuen öffentlichen SSH-Schlüssel mit dem Befehl ssh-copy-id auf Ihren lokalen Computer und dann auf die Rettungs-VM:
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
Ersetzen Sie dabei Folgendes:
- NEW_SSH_KEY durch den Namen des neuen SSH-Schlüssels ersetzen, den Sie im vorherigen Schritt erstellt haben.
- RESCUE_VM durch die IP-Adresse oder den FQDN Ihrer Rettungs-VM.
Stellen Sie das Datenlaufwerk auf der Rettungs-VM bereit:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Ersetzen Sie DEVICE durch die eindeutige Kennung Ihres eigenen Laufwerks, z. B. /dev/sdb1.
Kopieren Sie auf der Rettungs-VM den neuen öffentlichen SSH-Schlüssel aus der VM Ihrer Administrator-Workstation in die Datei authorized_keys auf dem bereitgestellten Datenlaufwerk.

Rufen Sie den Inhalt der Datei authorized_keys auf der Rettungs-VM auf. Diese enthält den neuen öffentlichen SSH-Schlüssel, der in einem vorherigen Schritt mit dem Befehl ssh-copy-id kopiert wurde:
```
ls ~/.ssh/authorized_keys
```
Kopieren Sie den letzten Eintrag für den öffentlichen SSH-Schlüssel aus der Datei authorized_keys und schließen Sie die Datei.
Bearbeiten Sie die authorized_keys-Datei auf dem bereitgestellten Datenlaufwerk von Ihrer Administrator-Workstation-VM:
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
Fügen Sie den Inhalt des öffentlichen SSH-Schlüssels aus der authorized_keys-Datei Ihrer Rettungs-VM ein.
Speichern und schließen Sie die Datei authorized_keys auf dem bereitgestellten Datenlaufwerk von Ihrer VM mit der Administrator-Workstation.
Prüfen Sie, ob die Dateien in /mnt/ext-disk/.ssh/ die richtigen Berechtigungen haben:
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
Beenden Sie die SSH-Verbindung zur Rettungs-VM.
Fahren Sie die Rettungs-VM herunter.
Trennen Sie das Datenlaufwerk von der Rettungs-VM und hängen Sie es wieder an die VM der Administrator-Workstation an.
Schalten Sie die Administrator-Workstation ein.
Nachdem die VM erfolgreich ausgeführt wird, stellen Sie über SSH und das neue SSH-Schlüsselpaar eine Verbindung zur Administrator-Workstation her.
```
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
```
Ersetzen Sie dabei Folgendes:
- NEW_SSH_KEY durch den Namen des neuen SSH-Schlüssels ersetzen, den Sie in einem vorherigen Schritt erstellt und in die VM der Administrator-Workstation kopiert haben.
- RESCUE_VM durch die IP-Adresse oder den FQDN der VM der Administrator-Workstation.
Prüfen Sie, ob Sie eine Verbindung über SSH herstellen können.
Löschen Sie die Rettungs-VM.

Nächste Schritte