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 lorsque vous utilisez des fournisseurs d'identité tiers pour vous authentifier auprès des clusters membres du parc.

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 (l'authentification tierce n'est pas configurée 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-la 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 au cluster, 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, consultez 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

  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, suivez la procédure décrite dans la présente section pour dépanner ces problèmes et déterminer s'il y a un problème avec la configuration de votre fournisseur d'identité.

Activer le journal de débogage

Pour résoudre les problèmes d'identité dans votre cluster, activez les journaux de débogage pour les pods dans le déploiement ais.

  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.

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

Vérifier le journal du conteneur

Recherchez les erreurs ou les avertissements dans les journaux de conteneurs.

  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

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

  1. Pour redémarrer le pod, 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 semble fonctionner correctement, testez la connectivité au fournisseur d'identité distant.

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

    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.