Ce document permet de résoudre les problèmes d'authentification dans GKE sur une solution Bare Metal. Nous fournissons des informations et des conseils généraux de dépannage, ainsi que des informations spécifiques à OpenID Connect (OIDC) et au protocole LDAP (Lightweight Directory Access Protocol).
L'authentification OIDC et LDAP utilise GKE Identity Service. Avant de pouvoir utiliser GKE Identity Service avec GKE sur Bare Metal, vous devez configurer un fournisseur d'identité. Si vous n'avez pas configuré de fournisseur d'identité pour GKE Identity Service, suivez les instructions de l'un des fournisseurs suivants les plus courants:
Consultez le guide de dépannage du fournisseur d'identité GKE Identity Service pour découvrir comment activer et examiner les journaux d'identité, et tester la connectivité.
Si vous avez besoin d'une aide supplémentaire, contactez l'assistance Google.
Dépannage d'ordre général
Les conseils de dépannage suivants peuvent vous aider à résoudre les problèmes généraux d'authentification et d'autorisation liés à GKE sur Bare Metal. Si ces problèmes ne s'appliquent pas, ou si vous rencontrez des problèmes avec OIDC ou LDAP, passez à la section sur le dépannage de GKE Identity Service.
Maintenir gcloud anthos auth
à jour
Vous pouvez éviter de nombreux problèmes courants en vérifiant que les composants de votre installation gcloud anthos auth
sont à jour.
Vous devez vérifier deux éléments. La commande gcloud anthos auth
dispose d'une logique dans le composant principal de la Google Cloud CLI et d'un composant anthos-auth
empaqueté séparément.
Pour mettre à jour la Google Cloud CLI:
gcloud components update
Pour mettre à jour le composant
anthos-auth
:gcloud components install anthos-auth
Configuration de fournisseur non valide
Si la configuration de votre fournisseur d'identité n'est pas valide, un message d'erreur en provenance de votre fournisseur d'identité s'affiche lorsque vous cliquez sur CONNEXION. Suivez les instructions propres au fournisseur pour configurer correctement le fournisseur ou votre cluster.
Autorisations non valides
Si vous avez terminé le processus d'authentification, mais que vous ne voyez toujours pas les détails du cluster, assurez-vous que vous avez accordé les autorisations RBAC correctes au compte que vous avez utilisé avec OIDC. Il peut s'agir d'un compte différent de celui que vous utilisez pour accéder à la console Google Cloud.
Jeton d'actualisation manquant
Le problème suivant se produit lorsque le serveur d'autorisation demande votre autorisation, mais que le paramètre d'authentification requis n'a pas été fourni.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
Pour résoudre ce problème, dans votre ressource ClientConfig
, ajoutez prompt=consent
au champ authentication.oidc.extraParams
. Ensuite, générez à nouveau le fichier d'authentification du client.
Jeton d'actualisation expiré
Le problème suivant se produit lorsque le jeton d'actualisation du fichier kubeconfig a expiré:
Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
certificate signed by unknown authority
Pour résoudre ce problème, exécutez à nouveau la commande gcloud anthos auth login
.
La commande gcloud anthos auth login échoue avec proxyconnect tcp
.
Ce problème se produit en cas d'erreur dans les configurations des variable d'environnement https_proxy
ou HTTPS_PROXY
. Si https://
est spécifié dans les variables d'environnement, les bibliothèques clientes HTTP en langage Go peuvent échouer si le proxy est configuré pour gérer les connexions HTTPS à l'aide d'autres protocoles, tels que Sock5.
L'exemple de message d'erreur suivant peut s'afficher:
proxyconnect tcp: tls: first record does not look like a TLS handshake
Pour résoudre ce problème, modifiez les variables d'environnement https_proxy
et HTTPS_PROXY
pour omettre l'élément https:// prefix
. Sous Windows, modifiez les variables d'environnement système. Par exemple, remplacez la valeur https://webproxy.example.com:8000
de la variable d'environnement https_proxy
par webproxy.example.com:8000
.
L'accès au cluster échoue lorsque vous utilisez un fichier kubeconfig généré par gcloud anthos auth login
Ce problème se produit lorsque le serveur d'API Kubernetes ne peut pas autoriser l'utilisateur. Cela peut se produire si les RBAC appropriés sont manquants ou incorrects, ou si la configuration OIDC du cluster comporte une erreur. L'exemple d'erreur suivant peut s'afficher:
Unauthorized
Pour résoudre ce problème, procédez comme suit :
Dans le fichier kubeconfig généré par
gcloud anthos auth login
, copiez la valeur deid-token
.kind: Config ... users: - name: ... user: auth-provider: config: id-token: xxxxyyyy
Installez jwt-cli et exécutez la commande suivante:
jwt ID_TOKEN
Vérifiez la configuration OIDC.
La ressource
ClientConfig
comporte les champsgroup
etusername
. Ces champs permettent de définir les options--oidc-group-claim
et--oidc-username-claim
dans le serveur d'API Kubernetes. Lorsque le serveur d'API reçoit le jeton, il le transfère à GKE Identity Service, qui renvoie lesgroup-claim
etusername-claim
extraits au serveur d'API. Le serveur d'API utilise cette réponse pour vérifier que le groupe ou l'utilisateur correspondant dispose des autorisations appropriées.Vérifiez que les revendications définies pour
group
etuser
dans la ressourceClientConfig
sont présentes dans le jeton d'ID.Vérifiez les autorisations RBAC appliquées.
Vérifiez qu'il existe un contrôle RBAC avec les autorisations appropriées pour l'utilisateur spécifié par
username-claim
ou pour l'un des groupes listésgroup-claim
à l'étape précédente. Le nom de l'utilisateur ou du groupe dans le contrôle RBAC doit être précédé du préfixeusernameprefix
ougroupprefix
spécifié dans la ressourceClientConfig
.Si
usernameprefix
est vide et queusername
est une valeur autre queemail
, le préfixe estissuerurl#
par défaut. Pour désactiver les préfixes de nom d'utilisateur, définissezusernameprefix
sur-
.Pour en savoir plus sur les préfixes d'utilisateur et de groupe, consultez la page S'authentifier avec OIDC.
Ressource
ClientConfig
:oidc: ... username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:"
Jeton d'ID
{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\cluster-developer", "group": [ "Domain Users", "EXAMPLE\developers" ], ... }
Les liaisons RBAC suivantes accordent à ce groupe et cet utilisateur le rôle
pod-reader
dans le cluster. Notez la barre oblique dans le champ de nom à la place d'une double barre:Regrouper des objets ClusterRoleBinding:
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
User 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
Vérifiez les journaux du serveur d'API Kubernetes.
Si le plug-in OIDC configuré dans le serveur d'API Kubernetes ne démarre pas correctement, le serveur d'API renvoie une erreur
Unauthorized
lorsqu'il reçoit le jeton d'ID. Pour déterminer si le plug-in OIDC a rencontré des problèmes sur le serveur d'API, exécutez la commande suivante :kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Remplacez les éléments suivants :
USER_CLUSTER_NAME
: nom du cluster d'utilisateur pour lequel afficher les journaux.ADMIN_CLUSTER_KUBECONFIG
: fichier kubeconfig du cluster d'administrateur
Résoudre les problèmes liés à OIDC
Lorsque l'authentification OIDC ne fonctionne pas pour GKE sur Bare Metal, cela signifie généralement que la spécification OIDC dans la ressource ClientConfig
a été mal configurée.
La ressource ClientConfig
fournit des instructions pour examiner les journaux et la spécification OIDC afin d'identifier la cause d'un problème OIDC.
Consultez le guide de dépannage du fournisseur d'identité GKE Identity Service pour découvrir comment activer et examiner les journaux d'identité, et tester la connectivité. Après avoir vérifié que GKE Identity Service fonctionne comme prévu ou identifié un problème, consultez les informations de dépannage OIDC suivantes.
Vérifier la spécification OIDC dans votre cluster
Les informations OIDC pour votre cluster sont spécifiées dans la ressource ClientConfig
de l'espace de noms kube-public
.
Utilisez
kubectl get
pour imprimer la ressource OIDC pour votre cluster d'utilisateur:kubectl --kubeconfig KUBECONFIG -n kube-public get \ clientconfig.authentication.gke.io default -o yaml
Remplacez
KUBECONFIG
par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.Vérifiez les valeurs des champs pour vérifier que la spécification est correctement configurée pour votre fournisseur OIDC.
Si vous identifiez un problème de configuration dans la spécification, reconfigurez OIDC.
Si vous ne parvenez pas à diagnostiquer et à résoudre le problème vous-même, contactez l'assistance Google Cloud.
L'assistance Google Cloud a besoin des journaux de GKE Identity Service et de la spécification OIDC pour diagnostiquer et résoudre les problèmes liés à OIDC.
Vérifier que l'authentification OIDC est activée
Avant de tester l'authentification OIDC, vérifiez qu'elle est activée dans votre cluster.
Examinez les journaux GKE Identity Service:
kubectl logs -l k8s-app=ais -n anthos-identity-service
L'exemple de résultat suivant montre que l'authentification OIDC est correctement activée:
... I1011 22:14:21.684580 33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started. ...
Si l'authentification OIDC n'est pas activée correctement, des erreurs semblables à l'exemple suivant s'affichent:
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
Examinez les erreurs spécifiques signalées et essayez de les corriger.
Tester l'authentification OIDC
Pour utiliser la fonctionnalité OIDC, utilisez une station de travail sur laquelle l'interface utilisateur et le navigateur sont activés. Vous ne pouvez pas effectuer ces étapes à partir d'une session SSH textuelle. Pour tester le bon fonctionnement d'OIDC dans votre cluster, procédez comme suit:
- Téléchargez la Google Cloud CLI.
Pour générer le fichier de configuration de connexion, exécutez la commande
gcloud anthos create-login-config
suivante:gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIG
Remplacez
KUBECONFIG
par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.Pour authentifier l'utilisateur, exécutez la commande suivante:
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG
Remplacez les éléments suivants :
- CLUSTER_NAME par le nom du cluster d'utilisateur auquel vous souhaitez vous connecter.
- AUTH_KUBECONFIG par le nouveau fichier kubeconfig à créer. Ce fichier inclut les identifiants d'accès au cluster. Pour en savoir plus, consultez la section S'authentifier sur le cluster.
Une page d'autorisation de connexion doit s'afficher dans le navigateur Web par défaut de votre poste de travail local. Fournissez des informations d'authentification valides à l'utilisateur dans cette invite de connexion.
Une fois l'étape de connexion précédente terminée, un fichier kubeconfig est généré dans votre répertoire actuel.
Pour tester le nouveau fichier kubeconfig contenant vos identifiants, répertoriez les pods de votre cluster d'utilisateur:
kubectl get pods --kubeconfig AUTH_KUBECONFIG
Remplacez AUTH_KUBECONFIG par le chemin d'accès au nouveau fichier kubeconfig généré à l'étape précédente.
L'exemple de message suivant peut s'afficher, indiquant que vous pouvez vous authentifier, mais aucun contrôle des accès basé sur les rôles (RBAC) n'est attribué au compte:
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
Examiner les journaux d'authentification OIDC
Si vous ne parvenez pas à vous authentifier avec OIDC, les journaux de GKE Identity Service fournissent les informations les plus pertinentes et les plus utiles pour déboguer le problème.
Utilisez
kubectl logs
pour imprimer les journaux de GKE Identity Service:kubectl --kubeconfig KUBECONFIG \ -n anthos-identity-service logs \ deployment/ais --all-containers=true
Remplacez
KUBECONFIG
par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.Recherchez dans les journaux les erreurs susceptibles de vous aider à diagnostiquer les problèmes liés à OIDC.
Par exemple, la ressource
ClientConfig
peut comporter une faute de frappe dans le champissuerURL
, telle quehtps://accounts.google.com
(sanst
danshttps
). Les journaux GKE Identity Service contiennent une entrée semblable à l'exemple suivant:OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
Si vous identifiez un problème de configuration dans les journaux, reconfigurez OIDC et corrigez-les.
Si vous ne parvenez pas à diagnostiquer et à résoudre le problème vous-même, contactez l'assistance Google Cloud. L'assistance Google Cloud a besoin des journaux GKE Identity Service et de la spécification OIDC pour diagnostiquer et résoudre les problèmes liés à OIDC.
Problèmes courants liés à OIDC
Si vous rencontrez des problèmes avec l'authentification OIDC, consultez les problèmes courants suivants. Suivez les conseils pour résoudre le problème.
Aucun point de terminaison disponible pour le service "ais"
Lorsque vous enregistrez la ressource ClientConfig
, le message d'erreur suivant s'affiche:
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"
Cette erreur est causée par le point de terminaison GKE Identity Service non opérationnel. Le pod du service GKE Identity Service ne peut pas diffuser le webhook de validation.
Pour vérifier que le pod GKE Identity Service n'est pas opérationnel, exécutez la commande suivante:
kubectl get pods -n anthos-identity-service \ --kubeconfig KUBECONFIG
Remplacez
KUBECONFIG
par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.L'exemple de résultat suivant signifie que votre pod GKE Identity Service plante:
NAME READY STATUS RESTARTS AGE ais-5949d879cd-flv9w 0/1 ImagePullBackOff 0 7m14s
Pour comprendre pourquoi le pod a un problème, examinez les événements du pod:
kubectl describe pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG
Remplacez
KUBECONFIG
par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.L'exemple de sortie suivant signale une erreur d'autorisation lors de l'extraction de l'image:
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"
Si les événements de pod signalent un problème, poursuivez le dépannage dans les zones concernées. Si vous avez besoin d'une aide supplémentaire, contactez l'assistance Google Cloud.
Échec de la lecture des octets de réponse du serveur
Les erreurs suivantes peuvent s'afficher dans les journaux de GKE Identity Service:
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.
Ces erreurs réseau peuvent apparaître dans les journaux de l'une des manières suivantes:
Affichage faible dans le journal:les erreurs secondaires ne sont probablement pas le problème principal et peuvent correspondre à des problèmes de réseau intermittents.
Le plug-in OIDC pour GKE Identity Service dispose d'un processus daemon pour synchroniser régulièrement l'URL de découverte OIDC toutes les 5 secondes. Si la connexion réseau est instable, cette requête de sortie peut échouer. Les échecs occasionnels n'affectent pas l'authentification OIDC. Les données mises en cache existantes peuvent être réutilisées.
Si vous rencontrez des erreurs supplémentaires dans les journaux, suivez les étapes de dépannage supplémentaires.
Apparaissent constamment dans le journal, ou le service GKE Identity Service n'atteint jamais le point de terminaison bien connu:ces problèmes constants indiquent un problème de connectivité entre GKE Identity Service et votre fournisseur d'identité OIDC.
Les étapes de dépannage suivantes peuvent vous aider à diagnostiquer ces problèmes de connectivité:
- Assurez-vous qu'un pare-feu ne bloque pas les requêtes sortantes provenant de GKE Identity Service.
- Vérifiez que le serveur du fournisseur d'identité fonctionne correctement.
- Vérifiez que l'URL de l'émetteur OIDC dans la ressource
ClientConfig
est correctement configurée. - Si vous avez activé le champ "proxy" dans la ressource
ClientConfig
, vérifiez l'état ou le journal de votre serveur proxy de sortie. - Testez la connectivité entre votre pod GKE Identity Service et le serveur du fournisseur d'identité OIDC.
Vous devez être connecté au serveur (non autorisé)
Lorsque vous essayez de vous connecter à l'aide de l'authentification OIDC, le message d'erreur suivant peut s'afficher:
You must be logged in to the server (Unauthorized)
Il s'agit d'un problème d'authentification général de Kubernetes qui ne fournit aucune information supplémentaire. Toutefois, cette erreur indique un problème de configuration.
Pour déterminer le problème, consultez les sections précédentes pour Vérifier la spécification OIDC dans votre cluster et Configurer la ressource ClientConfig
.
Échec de la demande d'authentification de webhook
Dans les journaux de GKE Identity Service, l'erreur suivante peut s'afficher:
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
Cette erreur indique que le serveur d'API ne peut pas établir la connexion avec le pod du service d'identité GKE.
Pour vérifier si le point de terminaison GKE Identity Service est accessible depuis l'extérieur, exécutez la commande
curl
suivante: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 '{}'
Remplacez
APISERVER_HOST
par l'adresse de votre serveur d'API.La réponse attendue est un code d'état
HTTP 400
. Si la requête a expiré, redémarrez le pod GKE Identity Service. Si l'erreur persiste, cela signifie que le serveur HTTP de GKE Identity Service ne parvient pas à démarrer. Pour obtenir une aide supplémentaire, contactez l'assistance Google Cloud.
Résoudre les problèmes liés à LDAP
Si vous rencontrez des problèmes avec l'authentification LDAP, assurez-vous d'avoir configuré votre environnement en suivant l'un des documents de configuration appropriés:
Vous devez également vous assurer que vous avez renseigné le code secret du compte de service LDAP et configuré la ressource ClientConfig
pour activer l'authentification LDAP.
Consultez le guide de dépannage du fournisseur d'identité GKE Identity Service pour découvrir comment activer et examiner les journaux d'identité, et tester la connectivité. Après avoir vérifié que GKE Identity Service fonctionne comme prévu ou identifié un problème, consultez les informations de dépannage LDAP suivantes.
Vérifier que l'authentification LDAP est activée
Avant de tester l'authentification LDAP, vérifiez qu'elle est activée dans votre cluster.
Examinez les journaux GKE Identity Service:
kubectl logs -l k8s-app=ais -n anthos-identity-service
L'exemple de résultat suivant montre que l'authentification LDAP est correctement activée:
... I1012 00:14:11.282107 34 plugin_list.h:139] LDAP[0] started. ...
Si l'authentification LDAP n'est pas activée correctement, des erreurs semblables à l'exemple suivant s'affichent:
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
Examinez les erreurs spécifiques signalées et essayez de les corriger.
Tester l'authentification LDAP
Pour utiliser la fonctionnalité LDAP, utilisez un poste de travail sur lequel l'interface utilisateur et le navigateur sont activés. Vous ne pouvez pas effectuer ces étapes à partir d'une session SSH textuelle. Pour tester le bon fonctionnement de l'authentification LDAP dans votre cluster, procédez comme suit:
- Téléchargez la Google Cloud CLI.
Pour générer le fichier de configuration de connexion, exécutez la commande gcloud anthos create-login-config suivante:
gcloud anthos create-login-config \ --output user-login-config.yaml \ --kubeconfig KUBECONFIG
Remplacez
KUBECONFIG
par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.Pour authentifier l'utilisateur, exécutez la commande suivante:
gcloud anthos auth login --cluster CLUSTER_NAME \ --login-config user-login-config.yaml \ --kubeconfig AUTH_KUBECONFIG
Remplacez les éléments suivants :
CLUSTER_NAME
par le nom du cluster d'utilisateur auquel vous souhaitez vous connecter.AUTH_KUBECONFIG
par le nouveau fichier kubeconfig à créer. Ce fichier inclut les identifiants d'accès au cluster. Pour en savoir plus, consultez la section S'authentifier sur le cluster.
Une page d'autorisation de connexion doit s'afficher dans le navigateur Web par défaut de votre poste de travail local. Fournissez des informations d'authentification valides à l'utilisateur dans cette invite de connexion.
Une fois l'étape de connexion précédente terminée, un fichier kubeconfig est généré dans votre répertoire actuel.
Pour tester le nouveau fichier kubeconfig contenant vos identifiants, répertoriez les pods de votre cluster d'utilisateur:
kubectl get pods --kubeconfig AUTH_KUBECONFIG
Remplacez AUTH_KUBECONFIG par le chemin d'accès au cluster d'utilisateur kubeconfig généré à l'étape précédente.
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
Problèmes LDAP courants
Si vous rencontrez des problèmes avec l'authentification LDAP, consultez les problèmes courants suivants. Suivez les conseils pour résoudre le problème.
Les utilisateurs ne peuvent pas s'authentifier avec des virgules dans leur CN
Lorsque vous utilisez LDAP, vous pouvez rencontrer des problèmes pour que les utilisateurs ne puissent pas s'authentifier si leur CN contient une virgule, comme CN="a,b"
. Si vous activez le journal de débogage pour GKE Identity Service, le message d'erreur suivant est signalé:
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.
Ce problème est dû au fait que le plug-in GKE Identity Service échappe deux fois la virgule. Ce problème ne se produit que dans les versions 1.13 et antérieures de GKE sur Bare Metal.
Pour résoudre ce problème, effectuez l'une des opérations suivantes:
- Mettez à niveau votre cluster vers GKE sur Bare Metal 1.13 ou version ultérieure.
- Choisissez un autre
identifierAttribute
, commesAMAccountName
, au lieu d'utiliser le CN. - Supprimez les virgules du CN dans votre annuaire LDAP.
Échec de l'authentification auprès de Google Cloud CLI 1.4.2
Avec Google Cloud CLI anthos-auth
1.4.2, le message d'erreur suivant peut s'afficher lorsque vous exécutez la commande gcloud anthos auth login
:
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
Dans le journal GKE Identity Service, vous voyez également l'erreur suivante:
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.
Pour résoudre cette erreur, procédez comme suit:
Vérifiez si vous utilisez la version 1.4.2 de la Google Cloud CLI
anthos-auth
:gcloud anthos auth version
L'exemple de résultat suivant montre que la version est 1.4.2:
Current Version: v1.4.2
Si vous exécutez la version 1.4.2 de la Google Cloud CLI
anthos-auth
, passez à la version 1.4.3 ou ultérieure.
Étapes suivantes
Si vous avez besoin d'une aide supplémentaire, contactez l'assistance Google.