Version 1.14. This version is no longer supported. For information about how to upgrade to version 1.15, see Upgrading Anthos on bare metal in the 1.15 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

Authentifizierungsprobleme von GKE on Bare Metal beheben

In diesem Dokument erfahren Sie, wie Sie Authentifizierungsprobleme in GKE on Bare Metal beheben. Sie finden dort allgemeine Informationen und Anleitungen zur Fehlerbehebung sowie spezifische Informationen zu OpenID Connect (OIDC) und LDAP (Lightweight Directory Access Protocol).

Bei der OIDC- und LDAP-Authentifizierung wird der GKE Identity Service verwendet. Bevor Sie den GKE Identity Service mit GKE on Bare Metal verwenden können, müssen Sie einen Identitätsanbieter konfigurieren. Wenn Sie noch keinen Identitätsanbieter für den GKE Identity Service konfiguriert haben, folgen Sie der Anleitung für einen der folgenden gebräuchlicheren Anbieter:

Informationen zum Aktivieren und Überprüfen von Identitätslogs sowie zum Testen der Verbindung finden Sie in der Fehlerbehebungsanleitung für GKE-Identitätsanbieter.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google-Support.

Allgemeine Fehlerbehebung

Die folgenden Tipps zur Fehlerbehebung können bei allgemeinen Authentifizierungs- und Autorisierungsproblemen bei GKE on Bare Metal hilfreich sein. Wenn diese Probleme nicht auftreten 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äufig auftretende Probleme vermeiden, indem Sie prüfen, ob die Komponenten Ihrer gcloud anthos auth-Installation aktuell sind.

Zwei Teile müssen verifiziert werden. Der Befehl gcloud anthos auth enthält die Logik in der Kernkomponente der Google Cloud CLI und eine separat gepackte anthos-auth-Komponente.

So aktualisieren Sie die Google Cloud CLI:
```
gcloud components update
```
So aktualisieren Sie die Komponente anthos-auth:
```
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 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. Dabei handelt es sich möglicherweise um ein anderes Konto als das, 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 Ressource ClientConfig prompt=consent in das Feld authentication.oidc.extraParams ein, um dieses Problem zu beheben. Erstellen Sie dann die Clientauthentifizierungsdatei noch einmal.

Aktualisierungstoken abgelaufen

Das folgende Problem tritt auf, wenn das Aktualisierungstoken in der kubeconfig-Datei 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 in den Konfigurationen der Umgebungsvariablen https_proxy oder HTTPS_PROXY ein Fehler auftritt. 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.

Die folgende Beispielfehlermeldung kann 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 passieren, wenn die entsprechenden RBACs fehlen oder falsch sind oder in der OIDC-Konfiguration für den Cluster ein Fehler vorliegt. Der folgende Beispielfehler könnte angezeigt werden:

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 Ressource ClientConfig hat 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 angezeigt wird, leitet er das Token an den GKE Identity Service weiter, der die extrahierten group-claim und username-claim zurück an den API-Server zurückgibt. Anhand der Antwort prüft der API-Server, ob die entsprechende Gruppe oder der entsprechende Nutzer die richtigen Berechtigungen hat.

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

Prüfen Sie, ob eine RBAC mit den richtigen Berechtigungen für den durch username-claim angegebenen Nutzer oder für eine der im vorherigen Schritt aufgeführten group-claim-Gruppen vorhanden ist. Dem Namen des Nutzers oder der Gruppe in der RBAC sollte das in der Ressource ClientConfig angegebene usernameprefix oder groupprefix vorangestellt werden.

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

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

Hinweis: Der Kubernetes API-Server behandelt einen umgekehrten Schrägstrich als Escape-Zeichen. Wenn der Name des Nutzers oder der Gruppe \\ enthält, liest der API-Server dies beim Parsen des ID-Tokens als einzelne \. Daher sollte die RBAC-Rollenbindung, die für diesen Nutzer oder diese Gruppe angewendet wird, nur einen einzelnen umgekehrten Schrägstrich enthalten. Andernfalls wird möglicherweise der Fehler Unauthorized angezeigt.

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 richtig gestartet wird, gibt der API-Server einen Unauthorized-Fehler zurück, wenn das ID-Token angezeigt wird. 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 Folgendes:
- USER_CLUSTER_NAME: Der Name Ihres Nutzerclusters, dessen Logs angezeigt werden sollen.
- ADMIN_CLUSTER_KUBECONFIG: Die kubeconfig-Datei des Administratorclusters.

Fehlerbehebung bei OIDC

Wenn die OIDC-Authentifizierung für GKE on Bare Metal nicht funktioniert, wurde in der Regel die OIDC-Spezifikation in der Ressource ClientConfig nicht richtig konfiguriert. Die Ressource ClientConfig enthält Anweisungen zum Überprüfen von Logs und der OIDC-Spezifikation, um die Ursache eines OIDC-Problems zu ermitteln.

Informationen zum Aktivieren und Überprüfen von Identitätslogs sowie zum Testen der Verbindung finden Sie in der Fehlerbehebungsanleitung für GKE-Identitätsanbieter. Wenn Sie bestätigt haben, dass der GKE Identity Service wie erwartet funktioniert, oder wenn Sie ein Problem festgestellt haben, prüfen Sie die folgenden Informationen zur OIDC-Fehlerbehebung.

OIDC-Spezifikation im Cluster prüfen

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

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

Der Google 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

Prüfen Sie vor dem Testen der OIDC-Authentifizierung, ob die OIDC-Authentifizierung in Ihrem Cluster aktiviert ist.

Sehen Sie sich die GKE Identity Service-Logs an:
```
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 korrekt aktiviert ist, werden Fehler wie im folgenden Beispiel angezeigt:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Überprüfen Sie die spezifischen gemeldeten Fehler und versuchen Sie, sie zu beheben.

OIDC-Authentifizierung testen

Wenn Sie das OIDC-Feature verwenden möchten, verwenden Sie eine Workstation mit aktivierter UI und Browser. Sie können diese Schritte nicht in einer textbasierten SSH-Sitzung ausführen. Führen Sie die folgenden Schritte aus, um zu testen, ob OIDC 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 Konfigurationsdatei für die Anmeldung zu generieren:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres 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 Folgendes:
- CLUSTER_NAME durch den Namen des Nutzerclusters, zu dem eine Verbindung hergestellt werden soll.
- AUTH_KUBECONFIG durch die neu zu erstellende kubeconfig-Datei, die die Anmeldedaten für den Zugriff auf den Cluster enthält. Weitere Informationen finden Sie unter Beim Cluster authentifizieren.
Im Standardwebbrowser Ihrer lokalen Workstation sollte eine Seite für die Einwilligung zur Anmeldung angezeigt werden. Geben Sie in dieser Aufforderung zur Anmeldung gültige Authentifizierungsinformationen für einen Nutzer an.

Nachdem Sie den vorherigen Anmeldeschritt erfolgreich abgeschlossen haben, wird in Ihrem aktuellen Verzeichnis eine kubeconfig-Datei generiert.
Listen Sie die Pods in Ihrem Nutzercluster auf, um die neue kubeconfig-Datei zu testen, die Ihre Anmeldedaten enthält:
```
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 kann zurückgegeben werden, die zeigt, dass Sie sich erfolgreich authentifizieren können, aber dem Konto keine rollenbasierten Zugriffssteuerung (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-Authentifizierungslogs prüfen

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

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

Beispiel: Die Ressource ClientConfig enthält möglicherweise einen Tippfehler im Feld issuerURL, z. B. htps://accounts.google.com (t in https fehlt). Die GKE Identity Service-Logs enthalten einen Eintrag wie im folgenden Beispiel:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Wenn Sie in den Logs ein Konfigurationsproblem feststellen, konfigurieren Sie OIDC neu und beheben Sie die Konfigurationsprobleme.
Wenn Sie das Problem nicht selbst diagnostizieren und beheben können, wenden Sie sich an den Google Cloud-Support. Der Google 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 bei der OIDC-Authentifizierung Probleme auftreten, prüfen Sie die folgenden häufigen Probleme. Folgen Sie der Anleitung, um das Problem zu beheben.

Keine Endpunkte für Dienst „ais“ verfügbar

Wenn Sie die Ressource ClientConfig speichern, 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 GKE Identity Service-Endpunkt 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 GKE Identity Service-Pod fehlerhaft ist:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres 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 die Ursache für ein Problem zu verstehen:

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

Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres Nutzerclusters.

Die folgende Beispielausgabe meldet einen Berechtigungsfehler beim Abrufen des Images:

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 Google Cloud-Support.

Antwortbyte konnten nicht vom Server gelesen werden

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 Protokollen auf eine der folgenden Arten angezeigt werden:

Spärlich im Log angezeigt: Ersatzfehler sind wahrscheinlich nicht das Hauptproblem und können zeitweise Netzwerkprobleme sein.

Das OIDC-Plug-in von GKE Identity Service hat einen Daemon-Prozess, um die OIDC-Erkennungs-URL regelmäßig alle 5 Sekunden zu synchronisieren. 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 in den Logs keine Fehler enthalten sind, fahren Sie mit weiteren Schritten zur Fehlerbehebung fort.
werden ständig im Log angezeigt oder der GKE Identity Service erreicht den bekannten Endpunkt nie erfolgreich: Diese konstanten Probleme weisen auf ein Verbindungsproblem zwischen GKE Identity Service und Ihrem OIDC-Identitätsanbieter hin.

Mit den folgenden Schritten zur Fehlerbehebung können Sie diese Verbindungsprobleme diagnostizieren:
1. Achten Sie darauf, dass die ausgehenden Anfragen von GKE Identity Service nicht durch eine Firewall blockiert werden.
2. Prüfen Sie, ob der Server des Identitätsanbieters ordnungsgemäß ausgeführt wird.
3. Prüfen Sie, ob die OIDC-Aussteller-URL in der Ressource ClientConfig korrekt konfiguriert ist.
4. Wenn Sie das Proxyfeld in der Ressource ClientConfig aktiviert haben, prüfen Sie den Status oder das Log Ihres Proxyservers für ausgehenden Traffic.
5. Testen Sie die Verbindung zwischen Ihrem GKE Identity Service-Pod und dem OIDC-Identitätsanbieterserver.

Sie müssen beim 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)

Dieser Fehler ist ein allgemeines Kubernetes-Authentifizierungsproblem, das keine zusätzlichen Informationen liefert. Dieser Fehler weist jedoch auf ein Konfigurationsproblem hin.

Informationen zum Ermitteln des Problems finden Sie in den vorherigen Abschnitten unter OIDC-Spezifikation im Cluster prüfen und ClientConfig-Ressource konfigurieren.

Anfrage für Webhook-Authenticator konnte nicht gestellt werden

In den GKE Identity Service-Logs 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 weist darauf hin, 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 von außerhalb erreicht werden kann:
```
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 der Statuscode HTTP 400. Wenn das Zeitlimit für die Anfrage überschritten wurde, starten Sie den GKE Identity Service-Pod neu. Wenn der Fehler weiterhin auftritt, kann der HTTP-Server des GKE Identity Service nicht gestartet werden. Weitere Unterstützung erhalten Sie vom Google Cloud-Support.

LDAP-Fehlerbehebung

Wenn Sie Probleme mit der LDAP-Authentifizierung haben, prüfen Sie, ob Sie Ihre Umgebung eingerichtet haben. Folgen Sie dazu einem der entsprechenden Konfigurationsdokumente:

Außerdem müssen Sie das LDAP-Dienstkonto-Secret ausfüllen und die Ressource ClientConfig konfiguriert haben, um die LDAP-Authentifizierung zu aktivieren.

Informationen zum Aktivieren und Überprüfen von Identitätslogs sowie zum Testen der Verbindung finden Sie in der Fehlerbehebungsanleitung für GKE-Identitätsanbieter. Nachdem Sie sich vergewissert haben, dass der GKE Identity Service wie erwartet funktioniert, oder wenn Sie ein Problem festgestellt haben, lesen Sie die folgenden Informationen zur LDAP-Fehlerbehebung.

Überprüfen, ob die LDAP-Authentifizierung aktiviert ist

Prüfen Sie vor dem Testen der LDAP-Authentifizierung, ob die LDAP-Authentifizierung in Ihrem Cluster aktiviert ist.

Sehen Sie sich die GKE Identity Service-Logs an:
```
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 korrekt aktiviert ist, werden Fehler wie im folgenden Beispiel angezeigt:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Überprüfen Sie die spezifischen gemeldeten Fehler und versuchen Sie, sie zu beheben.

LDAP-Authentifizierung testen

Verwenden Sie für die LDAP-Funktion eine Workstation mit aktivierter UI und Browser. Sie können diese Schritte nicht in einer textbasierten SSH-Sitzung ausführen. Führen Sie die folgenden Schritte aus, um zu testen, ob die LDAP-Authentifizierung in Ihrem Cluster ordnungsgemäß funktioniert:

Laden Sie die Google Cloud CLI herunter.
Führen Sie den Befehl gcloud anthos create-login-config aus, um die Konfigurationsdatei für die Anmeldung zu generieren:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres 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 Folgendes:
- CLUSTER_NAME durch den Namen des Nutzerclusters, zu dem eine Verbindung hergestellt werden soll.
- AUTH_KUBECONFIG durch die neu zu erstellende kubeconfig-Datei, die die Anmeldedaten für den Zugriff auf den Cluster enthält. Weitere Informationen finden Sie unter Beim Cluster authentifizieren.
Im Standardwebbrowser Ihrer lokalen Workstation sollte eine Seite für die Einwilligung zur Anmeldung angezeigt werden. Geben Sie in dieser Aufforderung zur Anmeldung gültige Authentifizierungsinformationen für einen Nutzer an.

Nachdem Sie den vorherigen Anmeldeschritt erfolgreich abgeschlossen haben, wird in Ihrem aktuellen Verzeichnis eine kubeconfig-Datei generiert.
Listen Sie die Pods in Ihrem Nutzercluster auf, um die neue kubeconfig-Datei zu testen, die Ihre Anmeldedaten enthält:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Ersetzen Sie AUTH_KUBECONFIG durch den Pfad zu Ihrem Nutzercluster kubeconfig, der 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 Sie Probleme mit der LDAP-Authentifizierung haben, prüfen Sie die folgenden häufigen Probleme. Folgen Sie der Anleitung, um das Problem zu beheben.

Nutzer können sich in ihrem CN nicht mit Kommas authentifizieren

Wenn Sie LDAP verwenden, kann es zu Problemen kommen, wenn sich Nutzer nicht authentifizieren können, wenn ihr CN ein Komma enthält, z. B. CN="a,b". Wenn Sie das Debugging-Log für den 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 für GKE Identity Service das Komma doppelt maskiert. Dieses Problem tritt nur in den GKE-Versionen von Bare Metal 1.13 und niedriger auf.

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

Führen Sie ein Upgrade Ihres Clusters auf GKE on Bare Metal 1.13 oder höher aus.
Wählen Sie ein anderes identifierAttribute wie sAMAccountName aus, anstatt den CN zu verwenden.
Entfernen Sie die Kommas aus dem CN in Ihrem LDAP-Verzeichnis.

Authentifizierungsfehler mit Google Cloud CLI 1.4.2

Mit der Google Cloud CLI anthos-auth 1.4.2 wird möglicherweise die folgende Fehlermeldung angezeigt, wenn Sie den Befehl gcloud anthos auth login ausführen:

  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 auch 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 die folgenden Schritte aus, um diesen Fehler zu beheben:

Prüfen Sie, ob Sie die anthos-auth-Version 1.4.2 der Google Cloud CLI verwenden:
```
gcloud anthos auth version
```
Das folgende Beispiel zeigt, dass die Version 1.4.2 ist:
```
Current Version: v1.4.2
```
Wenn Sie die anthos-auth-Version 1.4.2 der Google Cloud CLI ausführen, führen Sie ein Upgrade auf Version 1.4.3 oder höher aus.

Nächste Schritte