Résoudre les problèmes d'identité et d'autorisation

Ce document fournit des conseils de dépannage pour les problèmes d'identité et d'autorisation.

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.

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

Mettez à jour gcloud :

gcloud components update

Mettez à jour 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. Notez qu'il peut s'agir d'un compte différent de celui que vous utilisez pour accéder à la console Cloud Console.

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, ajoutez prompt=consent au champ authentication.oidc.extraParams dans votre fichier de configuration de cluster. Ensuite, générez à nouveau le fichier d'authentification du client.

Jeton d'actualisation expiré

Ce problème 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 login.

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

Ce problème se produit lorsque le fichier kubeconfig transmis à gkectl create-login-config n'est pas destiné à un cluster d'utilisateur ou que la ressource personnalisée 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 l'objet ClientConfig se trouve dans le cluster:

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

Échec de gkectl create-login-config en raison du 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.

La commande gcloud anthos auth login échoue avec 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 possible:

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 autorisations RBAC appropriées sont manquantes ou incorrectes, ou en cas d'erreur dans la configuration OIDC du cluster.

Unauthorized

Pour remédier à ce problème :

  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.

    Le paramètre authentication.oidc du fichier de configuration du cluster d'utilisateur comporte les champs group et username, qui permettent de définir les options --oidc-group-claim et --oidc-username-claim dans le serveur d'API Kubernetes. Lorsque le serveur d'API est présenté avec le jeton, il le transmet à Anthos 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.

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

    Vérifiez qu'un contrôle RBAC dispose des autorisations appropriées pour l'utilisateur spécifié par username-claim ou pour l'un des groupes group-claim répertoriés à l'étape précédente. Le nom de l'utilisateur ou du groupe défini dans le contrôle RBAC doit être précédé du préfixe usernameprefix ou groupprefix spécifié dans le fichier de configuration du cluster d'utilisateur.

    Notez que 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 noms 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.

    Notez que le serveur d'API Kubernetes traite actuellement une barre oblique inverse comme un caractère d'échappement. Par conséquent, si le nom de l'utilisateur ou du groupe contient \\, le serveur d'API le lit comme une seule \ lors de l'analyse du jeton d'ID. Par conséquent, la liaison de rôle RBAC appliquée à cet utilisateur ou à ce groupe ne doit contenir qu'une seule barre oblique inverse. Dans le cas contraire, une erreur Unauthorized peut s'afficher.

    Fichier de configuration du cluster

    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 de l'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 --kubeconfig ADMIN_CLUSTER_KUBECONFIG logs statefulset/kube-apiserver -n USER_CLUSTER_NAME