In diesem Dokument erfahren Sie, wie Sie Authentifizierungsprobleme in Google Distributed Cloud Virtual for Bare Metal beheben können. Sie erhalten allgemeine Informationen zur Fehlerbehebung und eine Anleitung sowie spezifische Informationen für OpenID Connect (OIDC) und Lightweight Directory Access Protocol (LDAP).
Für die OIDC- und LDAP-Authentifizierung wird der GKE Identity Service verwendet. Bevor Sie den GKE Identity Service mit Google Distributed Cloud Virtual for 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 Anbieter:
In der Anleitung zur Fehlerbehebung für Identitätsanbieter für GKE-Identitätsanbieter 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 Authentifizierungs- und Autorisierungsproblemen bei Google Distributed Cloud Virtual for Bare Metal helfen. 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äufige Probleme vermeiden, wenn Sie prüfen, ob die Komponenten Ihrer gcloud anthos auth
-Installation auf dem neuesten Stand sind.
Es gibt zwei Angaben, die überprüft werden müssen. Der Befehl gcloud anthos auth
enthält die Logik in der Kernkomponente der Google Cloud CLI und eine separat verpackte 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 Konfiguration
Wenn die Google Cloud Console die OIDC-Konfiguration nicht aus Ihrem Cluster lesen kann, ist die Schaltfläche ANMELDEN deaktiviert. Informationen zur Fehlerbehebung in der OIDC-Clusterkonfiguration finden Sie im folgenden Abschnitt zur Fehlerbehebung bei OIDC in diesem Dokument.
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. Dies ist möglicherweise 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 Ihrer ClientConfig
-Ressource 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 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.
Die folgende Fehlermeldung könnte beispielsweise 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 vonid-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
enthält die Feldergroup
undusername
. Mit diesen Feldern werden die Flags--oidc-group-claim
und--oidc-username-claim
im Kubernetes API-Server festgelegt. Wenn dem API-Server das Token angezeigt wird, leitet er das Token an den GKE Identity Service weiter, der die extrahiertengroup-claim
undusername-claim
zurück an den API-Server zurückgibt. Der API-Server prüft anhand der Antwort, ob die entsprechende Gruppe oder der entsprechende Nutzer die richtigen Berechtigungen hat.Prüfen Sie, ob die für
group
unduser
in der RessourceClientConfig
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 in
username-claim
angegebenen Nutzer oder für eine der Gruppen vorhanden ist, die im vorherigen Schritt untergroup-claim
aufgeführt sind. Dem Namen des Nutzers oder der Gruppe in der RBAC sollte das Präfixusernameprefix
odergroupprefix
vorangestellt werden, das in der RessourceClientConfig
angegeben wurde.Wenn
usernameprefix
leer ist undusername
ein anderer Wert alsemail
ist, wird das Präfix standardmäßig aufissuerurl#
gesetzt. Wenn Sie Nutzernamenpräfixe deaktivieren möchten, setzen Sieusernameprefix
auf-
.Weitere Informationen zu Nutzer- und Gruppenpräfixen finden Sie unter Mit OIDC authentifizieren.
ClientConfig
-Ressource: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 den Fehler
Unauthorized
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, für den Logs angezeigt werden sollen.ADMIN_CLUSTER_KUBECONFIG
: Die kubeconfig-Datei des Administratorclusters.
Fehlerbehebung bei OIDC
Wenn die OIDC-Authentifizierung für Google Distributed Cloud Virtual for Bare Metal nicht funktioniert, wurde die OIDC-Spezifikation in der ClientConfig
-Ressource normalerweise falsch konfiguriert.
Die Ressource ClientConfig
bietet eine Anleitung zum Überprüfen von Logs und der OIDC-Spezifikation, um die Ursache eines OIDC-Problems zu ermitteln.
In der Anleitung zur Fehlerbehebung für Identitätsanbieter für GKE-Identitätsanbieter erfahren Sie, wie Sie Identitätslogs aktivieren und prüfen und die Verbindung testen. 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 OIDC-Fehlerbehebung.
OIDC-Spezifikation in Ihrem 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 anhand der Feldwerte, ob die Spezifikation richtig 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-Dienstlogs 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 Logs des GKE Identity Service 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
Verwenden Sie zur Verwendung des OIDC-Features eine Workstation mit aktivierter UI und aktiviertem Browser. Sie können diese Schritte nicht über eine textbasierte 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 Anmeldekonfigurationsdatei 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 Ihren Cluster enthält. Weitere Informationen finden Sie unter Beim Cluster authentifizieren.
Im Standardwebbrowser Ihrer lokalen Workstation sollte eine Seite für die Zustimmung 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 Ihrer neuen kubeconfig-Datei, die im vorherigen Schritt erstellt wurde.
Die folgende Beispielmeldung 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-Authentifizierungsprotokolle überprüfen
Wenn Sie sich bei OIDC nicht authentifizieren können, liefern die Logs des GKE Identity-Dienstes 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 FeldissuerURL
, z. B.htps://accounts.google.com
(t
inhttps
fehlt). Die Logs des GKE Identity Service enthalten einen Eintrag wie den folgenden: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 Sie Probleme mit der OIDC-Authentifizierung haben, lesen 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 einen fehlerhaften Endpunkt des 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 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
Anhand der Pod-Ereignisse können Sie nachvollziehen, warum der Pod ein Problem hat:
kubectl describe pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG
Ersetzen Sie
KUBECONFIG
durch den Pfad zur kubeconfig-Datei Ihres Nutzerclusters.In der folgenden Beispielausgabe wird beim Abrufen des Images ein Berechtigungsfehler gemeldet:
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.
Fehler beim Lesen der Antwortbyte 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 Protokollen auf eine der folgenden Arten angezeigt werden:
Wenige Einträge im Log:Fremde Fehler 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 Anfrage möglicherweise fehl. Gelegentliche Fehler wirken sich nicht auf die OIDC-Authentifizierung aus. Die im Cache gespeicherten Daten können wiederverwendet werden.
Wenn in den Logs neue 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.
Die folgenden Schritte zur Fehlerbehebung können Ihnen bei der Diagnose dieser Verbindungsprobleme helfen:
- Achten Sie darauf, dass die ausgehenden Anfragen des GKE Identity Service nicht von einer Firewall blockiert werden.
- Prüfen Sie, ob der Server des Identitätsanbieters ordnungsgemäß ausgeführt wird.
- Prüfen Sie, ob die OIDC-Aussteller-URL in der Ressource
ClientConfig
korrekt konfiguriert ist. - Wenn Sie das Proxyfeld in der Ressource
ClientConfig
aktiviert haben, prüfen Sie den Status oder das Log des Proxyservers für ausgehenden Traffic. - Testen Sie die Verbindung zwischen Ihrem GKE Identity Service-Pod und dem Server des OIDC-Identitätsanbieters.
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 Authentifizierungsproblem von Kubernetes, 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 gesendet 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.
Prüfen Sie mit dem folgenden
curl
-Befehl, ob der GKE Identity Service-Endpunkt von außen 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 der Statuscode
HTTP 400
. Wenn es bei der Anfrage zu einer Zeitüberschreitung gekommen ist, 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.
Anmelde-URL nicht gefunden
Das folgende Problem tritt auf, wenn die Google Cloud Console den Identitätsanbieter nicht erreichen kann. Bei einem Anmeldeversuch wird der Fehler URL not found
angezeigt.
Mithilfe der folgenden Schritte zur Fehlerbehebung können Sie das Problem beheben. Versuchen Sie nach jedem Schritt, sich wieder anzumelden:
Wenn der Identitätsanbieter nicht über das öffentliche Internet erreichbar ist, aktivieren Sie den OIDC-HTTP-Proxy für die Anmeldung über die Google Cloud Console. Bearbeiten Sie die benutzerdefinierte Ressource
ClientConfig
und legen SieuseHTTPProxy
auftrue
fest:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
Ersetzen Sie
USER_CLUSTER_KUBECONFIG
durch den Pfad zur kubeconfig-Datei Ihres Nutzerclusters.Wenn der HTTP-Proxy aktiviert ist und dieser Fehler weiterhin auftritt, liegt möglicherweise ein Problem mit dem Start des Proxys vor. Rufen Sie die Proxy-Logs auf:
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
Ersetzen Sie
USER_CLUSTER_KUBECONFIG
durch den Pfad zur kubeconfig-Datei Ihres Nutzerclusters.Auch wenn Ihr Identitätsanbieter eine bekannte Zertifizierungsstelle hat, müssen Sie in Ihrer benutzerdefinierten Ressource
ClientConfig
einen Wert füroidc.caPath
angeben, damit der HTTP-Proxy erfolgreich gestartet wird.Wenn der Autorisierungsserver zur Einwilligung auffordert und Sie die
extraparam
-Parameterprompt=consent
nicht eingefügt haben, bearbeiten Sie die benutzerdefinierte RessourceClientConfig
und fügen Sie denextraparams
-Parameternprompt=consent
hinzu:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
Ersetzen Sie
USER_CLUSTER_KUBECONFIG
durch den Pfad zur kubeconfig-Datei Ihres 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.
LDAP-Fehlerbehebung
Wenn Sie Probleme mit der LDAP-Authentifizierung haben, prüfen Sie, ob Sie Ihre Umgebung eingerichtet haben. Folgen Sie dazu eines der entsprechenden Konfigurationsdokumente:
Außerdem müssen Sie das LDAP-Dienstkonto-Secret ausfüllen und die Ressource ClientConfig
so konfiguriert haben, dass die LDAP-Authentifizierung aktiviert wird.
In der Anleitung zur Fehlerbehebung für Identitätsanbieter für GKE-Identitätsanbieter erfahren Sie, wie Sie Identitätslogs aktivieren und prüfen und die Verbindung testen. 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.
Prü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 Logs des GKE Identity Service 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, auf der die UI und der Browser aktiviert sind. Sie können diese Schritte nicht über eine textbasierte 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 folgenden Befehl gcloud anthos create-login-config aus, um die Anmeldekonfigurationsdatei 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 neue 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 für die Zustimmung 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, lesen 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, können Probleme auftreten, wenn sich Nutzer nicht authentifizieren können, wenn ihr CN ein Komma wie CN="a,b"
enthält. 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 Versionen Google Distributed Cloud Virtual for Bare Metal 1.13 und niedriger auf.
Führen Sie einen der folgenden Schritte aus, um das Problem zu beheben:
- Führen Sie ein Upgrade Ihres Clusters auf Google Distributed Cloud Virtual for Bare Metal 1.13 oder höher durch.
- Wählen Sie eine andere
identifierAttribute
wiesAMAccountName
aus, anstatt die CN zu verwenden. - Entfernen Sie die Kommas aus dem CN in Ihrem LDAP-Verzeichnis.
Authentifizierungsfehler mit der 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.
So beheben Sie diesen Fehler:
Prüfen Sie, ob Sie die
anthos-auth
-Version 1.4.2 der Google Cloud CLI verwenden:gcloud anthos auth version
Die folgende Beispielausgabe 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.