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 des utilisateurs 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 ClientConfig n'est pas présent 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 reçoit le jeton d'identité d'un utilisateur, il le transfère au service d'identité GKE, 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 apprendre à 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 contrôles RBAC pour les groupes ne fonctionnent pas pour les fournisseurs OIDC

  1. Vérifier 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 champ id-token du fichier kubeconfig. 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 les 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 être groups dans la section oidc.

    Après avoir modifié la configuration dans la section oidc, veillez à réexécuter les instructions indiquées dans Configurer l'accès utilisateur 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 les étapes de cette section pour résoudre les problèmes liés à 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. Appliquer un correctif à votre cluster existant avec 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.

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

Vérifier le journal du conteneur du service d'identité GKE

Examinez le contenu des journaux du conteneur GKE Identity Service pour détecter les erreurs ou les avertissements.

  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 au fichier kubeconfig de votre cluster d'utilisateur.

Redémarrer le pod GKE Identity Service

Si les journaux du conteneur signalent 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 au 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 de boîte de réception 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 au fichier kubeconfig de votre cluster d'utilisateur.

  2. Pour vérifier si vous pouvez récupérer l'URL de découverte, exécutez la commande dans le pod podbox 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 de l'émetteur de votre fournisseur d'identité.
    • KUBECONFIG: chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.

    Une réponse positive est un résultat JSON avec les points de terminaison détaillés du 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 Anthos sur VMware

LDAP n'est actuellement compatible qu'avec les clusters d'utilisateur Anthos sur VMware.