Résoudre les problèmes d'accès des utilisateurs

Ce document fournit des conseils de dépannage pour les problèmes d'accès utilisateur dans GKE Identity Service.

gcloud anthos create-login-config ne parvient pas à obtenir clientconfig

Ce problème se produit dans l'un des cas suivants:

• Le fichier kubeconfig transmis à gcloud anthos create-login-config est incorrect.
• La ressource personnalisée ClientConfig n'est pas présente dans le cluster (GKE Identity Service n'est pas installé sur le cluster).

Message d'erreur

  failed to get clientconfig default in namespace kube-public
  

Solution

Pour résoudre ce problème, procédez comme suit :

1. Assurez-vous de disposer du fichier kubeconfig approprié pour votre cluster.

2. Pour vérifier si la ressource personnalisée ClientConfig se trouve dans le cluster, exécutez la commande suivante:

   kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public
   

   Si la ressource ClientConfig n'est pas présente dans le cluster, installez et configurez GKE Identity Service sur le cluster. Pour en savoir plus sur les options de configuration des clusters, consultez la page Options de configuration pour les clusters.

Échec de gcloud anthos create-login-config en raison d'un nom de cluster en double

Ce problème se produit si vous tentez de créer une configuration de connexion pour un cluster dans un fichier contenant déjà une configuration de connexion pour ce cluster.

Message d'erreur

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.
  

Solution

Pour résoudre ce problème, utilisez l'option --output pour spécifier un nouveau fichier de destination.

Si vous ne fournissez pas --output, ces données de configuration de connexion sont écrites dans un fichier nommé kubectl-anthos-config.yaml dans le répertoire actuel.

La commande gcloud anthos auth login renvoie une erreur proxyconnect tcp

Ce problème se produit en cas d'erreur dans les configurations des variables 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.

Message d'erreur

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

Solution

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 pour l'une des raisons suivantes:

• La configuration utilisée comporte une erreur pour se connecter avec la commande gcloud anthos auth login.
• Les règles RBAC nécessaires sont incorrectes ou manquantes pour l'utilisateur.

Message d'erreur

  Unauthorized
  

Solution

Pour résoudre ce problème, procédez comme suit :

1. Vérifiez la configuration utilisée pour vous connecter.

   Configuration OIDC

   La section authentication.oidc du fichier de configuration du cluster d'utilisateur contient des champs group et username permettant de définir les options --oidc-group-claim et --oidc-username-claim sur le serveur d'API Kubernetes. Lorsque le serveur d'API est présenté avec le jeton d'identité d'un utilisateur, il transfère le jeton à GKE Identity Service, qui renvoie les éléments group-claim et username-claim extraits au serveur d'API. Le serveur d'API utilise la 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 et user dans la section authentication.oidc du fichier de configuration de cluster sont présentes dans le jeton d'ID.

2. Vérifiez les stratégies RBAC appliquées.

   Pour savoir comment configurer les stratégies RBAC appropriées pour GKE Identity Service, consultez la page Configurer le contrôle des accès basé sur les rôles (RBAC).

Les autorisations RBAC pour les groupes ne fonctionnent pas pour les fournisseurs OIDC

Remarque : Les instructions de dépannage suivantes ne s'appliquent que si votre fournisseur est configuré dans la section oidc de la ressource personnalisée ClientConfig et que le champ enableAccessToken est défini sur false.

1. Vérifiez si le jeton d'ID contient les informations relatives au groupe.

   Une fois que vous avez exécuté la commande gcloud anthos auth login pour lancer le flux d'authentification OIDC, le jeton d'ID est stocké dans le fichier kubeconfig, dans le champ id-token. Utilisez jwt.io pour décoder le jeton d'ID et vérifier s'il contient les informations relatives au groupe de l'utilisateur comme prévu.

2. Si le jeton d'ID ne contient pas d'informations sur le groupe de l'utilisateur, configurez correctement le fournisseur OIDC pour qu'il renvoie les informations sur le groupe conformément à la documentation de votre fournisseur OIDC. Par exemple, si vous utilisez la configuration OIDC du fournisseur d'identité Okta, suivez la documentation du fournisseur d'identité Okta pour configurer des groupes dans le jeton d'ID.

3. Si le jeton d'ID contient des informations relative au groupe, vérifiez si la clé d'informations sur le groupe dans le jeton d'ID correspond au champ groupsClaim configuré dans la section oidc.

   Par exemple, si le jeton d'ID contient des informations relatives au groupe dans la clé groups :

   "groups" : ["group1", "group2" ...]
   

   La valeur du champ groupsClaim doit alors être groups dans la section oidc.

   Après avoir modifié la configuration dans la section oidc, veillez à exécuter à nouveau les instructions répertoriées dans les sections Configurer l'accès des utilisateurs et Accéder aux clusters.

Résoudre les problèmes liés aux fournisseurs d'identité

Si vous rencontrez des problèmes lors de l'utilisation d'OIDC ou de LDAP avec votre cluster GKE, suivez la procédure décrite dans la présente section pour dépanner GKE Identity Service et déterminer s'il y a un problème avec la configuration de votre fournisseur d'identité.

Activer le journal de débogage de GKE Identity Service

Pour résoudre les problèmes d'identité dans votre cluster, activez le journal de débogage de GKE Identity Service.

1. Appliquez le correctif à votre cluster existant à l'aide de kubectl patch :

   kubectl patch deployment ais \
     -n anthos-identity-service --type=json \
     -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
     --kubeconfig KUBECONFIG
   

   Remplacez les éléments suivants :

   • LOG_LEVEL : pour les journaux les plus détaillés, définissez cette valeur sur le niveau 3 lors du dépannage.

     Remarque : Cette valeur peut être définie sur une valeur supérieure à 9. Toutefois, à ce niveau, des informations d'identification sont susceptibles d'être affichées dans votre console.

   • KUBECONFIG : chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.

Consulter le journal du conteneur GKE Identity Service

Recherchez les erreurs ou les avertissements dans les journaux de conteneurs de GKE Identity Service.

1. Pour consulter les journaux, utilisez kubectl logs :

   kubectl logs -f -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   Remplacez KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.

Redémarrer le pod GKE Identity Service

Si les journaux de conteneur indiquent des problèmes, redémarrez le pod GKE Identity Service.

1. Pour redémarrer le pod GKE Identity Service, supprimez le pod existant. Un pod de remplacement est automatiquement créé.

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

   Remplacez KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.

Résoudre les problèmes de connectivité au fournisseur d'identité

Si le pod GKE Identity Service semble fonctionner correctement, testez la connectivité au fournisseur d'identité distant.

1. Démarrez un pod Busybox dans le même espace de noms que le pod GKE Identity Service :

   kubectl run curl --image=radial/busyboxplus:curl \
     -n anthos-identity-service -- sleep 3000 \
     --kubeconfig KUBECONFIG
   

   Remplacez KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.

2. Pour vérifier si vous pouvez récupérer l'URL de découverte, exécutez le pod Busybox et exécutez la commande curl :

   kubectl exec pod/curl -n anthos-identity-service -- \
     curl ISSUER_URL \
     --kubeconfig KUBECONFIG
   

   Remplacez les éléments suivants :

   • ISSUER_URL : URL d'émetteur de votre fournisseur d'identité.
   • KUBECONFIG : chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.

   Une réponse réussie est un résultat JSON incluant le détail des points de terminaison de fournisseur d'identité.

3. Si la commande précédente ne renvoie pas le résultat attendu, contactez l'administrateur de votre fournisseur d'identité pour obtenir de l'aide.

La connexion LDAP ne fonctionne pas pour le cluster d'administrateur Google Distributed Cloud

LDAP n'est actuellement compatible qu'avec le cluster d'utilisateur Google Distributed Cloud.