Résoudre les problèmes d'authentification dans Google Distributed Cloud

Ce document permet de résoudre les problèmes d'authentification dans Google Distributed Cloud. Des informations et des conseils généraux de dépannage sont fournis, ainsi que des informations spécifiques sur OpenID Connect (OIDC) et le protocole LDAP (Lightweight Directory Access Protocol).

L'authentification OIDC et LDAP utilise GKE Identity Service. Avant de pouvoir utiliser GKE Identity Service avec Google Distributed Cloud, vous devez configurer un fournisseur d'identité. Si vous n'avez pas configuré de fournisseur d'identité pour GKE Identity Service, suivez les instructions correspondant à l'un des fournisseurs les plus courants suivants:

Consultez le guide de dépannage du fournisseur d'identité pour le service d'identité GKE pour savoir comment activer et examiner les journaux d'identité et tester la connectivité.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

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 avec Google Distributed Cloud. 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.

Maintenez 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.

Deux éléments doivent être vérifiés. La commande gcloud anthos auth possède une logique dans le composant principal de la Google Cloud CLI et un composant anthos-auth empaqueté séparément.

  1. Pour mettre à jour la Google Cloud CLI:

    gcloud components update

  2. 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.

Configuration non valide

Si la console Google Cloud ne peut pas lire la configuration OIDC de votre cluster, le bouton CONNEXION est désactivé. Pour résoudre les problèmes de configuration OIDC de votre cluster, consultez la section Résoudre les problèmes liés à OIDC ci-dessous dans ce document.

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 :

  1. Dans le fichier kubeconfig généré par gcloud anthos auth login, copiez la valeur de id-token.

    kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

  2. Installez jwt-cli et exécutez la commande suivante:

    jwt ID_TOKEN

  3. Vérifiez la configuration OIDC.

    La ressource ClientConfig comporte les champs group et username. Ces champs permettent 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, il le transfère à GKE Identity Service, qui renvoie les éléments group-claim et username-claim extraits au serveur d'API. Cette réponse permet au serveur d'API de 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 ressource ClientConfig sont présentes dans le jeton d'ID.

  4. Vérifiez les autorisations RBAC appliquées.

    Vérifiez qu'il existe un RBAC avec les autorisations appropriées pour l'utilisateur spécifié par username-claim ou pour l'un des groupes listés group-claim à l'étape précédente. Le nom de l'utilisateur ou du groupe dans le RBAC doit être précédé du préfixe usernameprefix ou groupprefix spécifié dans la ressource ClientConfig.

    Si usernameprefix est vide et que username est une valeur autre que email, le préfixe est défini par défaut sur issuerurl#. Pour désactiver les préfixes de nom d'utilisateur, définissez usernameprefix 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

  5. 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 est présenté avec 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

gkectl create-login-config ne parvient pas à obtenir clientconfig

Ce problème se produit lorsque le fichier kubeconfig transmis à gkectl create-login-config ne correspond pas à un cluster d'utilisateur ou lorsque la ressource ClientConfig n'est pas apparue lors de la création du cluster.

Error getting clientconfig using KUBECONFIG

Pour résoudre ce problème, assurez-vous que vous disposez du fichier kubeconfig approprié pour votre cluster d'utilisateur. Vérifiez ensuite si la ressource ClientConfig se trouve dans le cluster:

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

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

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

Ce problème se produit si vous tentez d'écrire des données de configuration de connexion contenant un nom de cluster qui existe déjà dans le fichier de destination. Chaque fichier de configuration de connexion doit contenir des noms de cluster uniques.

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

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.

Résoudre les problèmes liés à OIDC

Lorsque l'authentification OIDC ne fonctionne pas pour Google Distributed Cloud, 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 pour vous aider à identifier la cause d'un problème OIDC.

Consultez le guide de dépannage du fournisseur d'identité pour le service d'identité GKE pour savoir comment activer et examiner les journaux d'identité et tester la connectivité. Une fois que vous avez vérifié que GKE Identity Service fonctionne comme prévu ou que vous avez 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.

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

  2. Examinez les valeurs des champs afin de vérifier que la spécification est correctement configurée pour votre fournisseur OIDC.

  3. Si vous identifiez un problème de configuration dans la spécification, reconfigurez OIDC.

  4. 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.

  1. 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 avec l'interface utilisateur et le navigateur activés. Vous ne pouvez pas effectuer ces étapes à partir d'une session SSH basée sur du texte. Pour vérifier qu'OIDC fonctionne correctement dans votre cluster, procédez comme suit:

  1. Téléchargez la Google Cloud CLI.

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

  3. 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, qui inclut les identifiants d'accès à votre cluster. Pour en savoir plus, consultez la section S'authentifier auprès du cluster.

  4. Vous devriez recevoir une page d'autorisation de connexion ouverte dans le navigateur Web par défaut de votre poste de travail local. Fournissez des informations d'authentification valides pour un utilisateur dans cette invite de connexion.

    Une fois l'étape de connexion précédente effectuée, un fichier kubeconfig est généré dans votre répertoire actuel.

  5. 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 et indique que vous pouvez vous authentifier, mais qu'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 GKE Identity Service fournissent les informations les plus pertinentes et les plus utiles pour déboguer le problème.

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

  2. 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 champ issuerURL, comme htps://accounts.google.com (il manque une t dans https). 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.

  3. Si vous identifiez un problème de configuration dans les journaux, reconfigurez OIDC et corrigez les problèmes de configuration.

  4. 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 instructions 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 est renvoyé:

  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 du service GKE Identity Service non opérationnel. Le pod GKE Identity Service ne peut pas diffuser le webhook de validation.

  1. 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 du 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

  2. Pour comprendre pourquoi le pod rencontre un problème, examinez les événements associés:

    kubectl describe 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.

    L'exemple de résultat 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"

  3. 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:

  • Apparaître partiellement dans le journal:les erreurs simples ne sont probablement pas le problème principal et peuvent être des problèmes réseau intermittents.

    Le plug-in OIDC de GKE Identity Service dispose d'un processus daemon qui synchronise périodiquement l'URL de découverte OIDC toutes les cinq 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 dans les journaux, passez à des étapes de dépannage supplémentaires.

  • Apparaître en permanence dans le journal, ou GKE Identity Service n'atteint jamais correctement le point de terminaison 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é:

    1. Assurez-vous qu'un pare-feu ne bloque pas les requêtes sortantes provenant de GKE Identity Service.
    2. Vérifiez que le serveur du fournisseur d'identité fonctionne correctement.
    3. Vérifiez que l'URL de l'émetteur OIDC dans la ressource ClientConfig est correctement configurée.
    4. Si vous avez activé le champ "proxy" dans la ressource ClientConfig, examinez l'état ou le journal de votre serveur proxy de sortie.
    5. 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, vous pouvez recevoir le message d'erreur suivant:

  You must be logged in to the server (Unauthorized)

Cette erreur est un problème d'authentification général 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 du webhook

Dans les journaux du service Identity Service GKE, 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 GKE Identity Service.

  1. 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 assistance supplémentaire, contactez l'assistance Google Cloud.

URL de connexion introuvable

Le problème suivant se produit lorsque la console Google Cloud ne peut pas atteindre le fournisseur d'identité. Toute tentative de connexion est redirigée vers une page comportant l'erreur URL not found.

Pour résoudre ce problème, consultez les étapes de dépannage ci-dessous. Après chaque étape, essayez de vous reconnecter:

  1. Si le fournisseur d'identité n'est pas accessible via l'Internet public, activez le proxy HTTP OIDC pour vous connecter à l'aide de la console Google Cloud. Modifiez la ressource personnalisée ClientConfig et définissez useHTTPProxy sur true:

    kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG

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

  2. Si le proxy HTTP est activé et que l'erreur persiste, il est possible qu'il rencontre un problème lors du démarrage du proxy. Affichez les journaux du proxy:

    kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

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

    Même si votre fournisseur d'identité dispose d'une autorité de certification connue, vous devez fournir une valeur pour oidc.caPath dans votre ressource personnalisée ClientConfig pour que le proxy HTTP démarre.

  3. Si le serveur d'autorisation vous demande l'autorisation et que vous n'avez pas inclus les paramètres prompt=consent extraparam, modifiez la ressource personnalisée ClientConfig et ajoutez prompt=consent aux paramètres extraparams:

    kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG

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

  4. Si les paramètres de configuration sont modifiés sur le service de stockage, vous devrez peut-être vous déconnecter explicitement des sessions existantes. Dans la console Google Cloud, accédez à la page d'informations du cluster, puis sélectionnez Se déconnecter.

Résoudre les problèmes 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 vérifier 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é pour le service d'identité GKE pour savoir comment activer et examiner les journaux d'identité et tester la connectivité. Une fois que vous avez confirmé que GKE Identity Service fonctionne comme prévu ou que vous avez 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 que l'authentification LDAP est activée dans votre cluster.

  1. 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 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 basée sur du texte. Pour tester le bon fonctionnement de l'authentification LDAP dans votre cluster, procédez comme suit:

  1. Téléchargez la Google Cloud CLI.

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

  3. 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, qui inclut les identifiants d'accès à votre cluster. Pour en savoir plus, consultez la section S'authentifier auprès du cluster.

  4. Vous devriez recevoir une page d'autorisation de connexion ouverte dans le navigateur Web par défaut de votre poste de travail local. Fournissez des informations d'authentification valides pour un utilisateur dans cette invite de connexion.

    Une fois l'étape de connexion précédente effectuée, un fichier kubeconfig est généré dans votre répertoire actuel.

  5. 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 fichier kubeconfig de votre cluster d'utilisateur, 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 instructions pour résoudre le problème.

Les utilisateurs ne peuvent pas s'authentifier avec des virgules dans leur CN

Lorsque vous utilisez LDAP, il est possible que vous rencontriez des problèmes où les utilisateurs ne peuvent 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 LDAP de GKE Identity Service échappe en double la virgule. Ce problème ne se produit que dans les versions Google Distributed Cloud 1.13 et antérieures.

Pour résoudre ce problème, effectuez l'une des opérations suivantes:

  1. Mettez à niveau votre cluster vers Google Distributed Cloud 1.13 ou une version ultérieure.
  2. Choisissez un autre identifierAttribute, tel que sAMAccountName, au lieu d'utiliser le CN.
  3. Supprimez les virgules du CN de votre annuaire LDAP.

Échec de l'authentification avec la Google Cloud CLI 1.4.2

Avec la 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, l'erreur suivante s'affiche également:

  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:

  1. 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

  2. Si vous exécutez la version 1.4.2 de la Google Cloud CLI anthos-auth, effectuez une mise à niveau vers la version 1.4.3 ou ultérieure.

Problèmes courants

Cette section décrit les problèmes d'authentification courants et explique comment les résoudre.

Perte de l'accès au poste de travail administrateur en raison d'une erreur de clé SSH permission denied

L'erreur suivante se produit lorsque vous essayez de vous connecter à votre poste de travail administrateur et que vous recevez un message "Permission denied" semblable à l'exemple suivant:

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

Cette erreur se produit en raison de l'utilisation d'une clé privée incorrecte ou de l'absence de clé lorsque vous vous connectez au poste de travail administrateur via SSH.

Pour résoudre ce problème, recherchez et utilisez la bonne clé SSH. Si vous ne trouvez pas la clé SSH appropriée, générez une nouvelle paire de clés SSH pour le poste de travail administrateur en procédant comme suit:

  1. Créez une VM de secours temporaire. Cette VM de secours doit se connecter aux mêmes réseau et Datastore que la VM actuelle du poste de travail administrateur.

  2. Éteignez la VM du poste de travail administrateur et la VM de secours.

  3. Associez le disque de données de la VM du poste de travail administrateur à la VM de secours. La taille du disque de données est généralement de 512 Mo, sauf si vous avez spécifié une taille de disque différente dans le fichier de configuration du poste de travail administrateur, qui est distinct du disque de démarrage.

  4. Allumez la VM de secours.

  5. Connectez-vous à la VM de secours à l'aide de SSH.

  6. Sur votre ordinateur local, générez une nouvelle paire de clés SSH.

  7. Sur votre ordinateur local, copiez la nouvelle clé publique SSH sur la VM de secours à l'aide de la commande ssh-copy-id:

    ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM

    Remplacez les éléments suivants :

    • NEW_SSH_KEY par le nom de la nouvelle clé SSH que vous avez créée à l'étape précédente.
    • RESCUE_VM par l'adresse IP ou le nom de domaine complet de votre VM de secours.

  8. Installez le disque de données sur la VM de secours:

    sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk

    Remplacez DEVICE par l'identifiant unique de votre propre disque, tel que /dev/sdb1.

  9. Sur la VM de secours, copiez la nouvelle clé publique SSH dans le fichier authorized_keys du disque de données installé à partir de la VM de votre poste de travail administrateur.

    Affichez le contenu du fichier authorized_keys sur la VM de secours, qui inclut la nouvelle clé publique SSH copiée à l'aide de la commande ssh-copy-id lors d'une étape précédente:

    ls ~/.ssh/authorized_keys

    Copiez la dernière entrée de clé publique SSH à partir du fichier authorized_keys, puis fermez le fichier.

  10. Modifiez le fichier authorized_keys sur le disque de données installé à partir de la VM de votre poste de travail administrateur:

    vi /mnt/ext-disk/.ssh/authorized_keys

    Collez le contenu de la clé publique SSH à partir du fichier authorized_keys de votre VM de secours.

  11. Enregistrez et fermez le fichier authorized_keys sur le disque de données installé à partir de la VM de votre poste de travail administrateur.

  12. Vérifiez que les autorisations appropriées sont appliquées aux fichiers dans /mnt/ext-disk/.ssh/:

    chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*

  13. Quittez votre connexion SSH vers la VM de secours.

  14. Arrêtez la VM de secours.

  15. Dissociez le disque de données de la VM de secours, puis réassociez le disque à la VM du poste de travail administrateur.

  16. Mettez le poste de travail d'administrateur sous tension.

  17. Une fois la VM en cours d'exécution, connectez-vous au poste de travail administrateur à l'aide de SSH et de la nouvelle paire de clés SSH.

    ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM

    Remplacez les éléments suivants :

    • NEW_SSH_KEY par le nom de la nouvelle clé SSH que vous avez créée à une étape précédente et copiée sur la VM du poste de travail administrateur.
    • RESCUE_VM par l'adresse IP ou le nom de domaine complet de la VM de votre poste de travail administrateur.

    Vérifiez que vous pouvez vous connecter à l'aide de SSH.

  18. Supprimez la VM de secours.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.