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 :
Dans le fichier kubeconfig généré par
gcloud anthos auth login
, copiez la valeur deid-token
.kind: Config … users: — name: … user: auth-provider: config: id-token: xxxxyyyy
Installez jwt-cli et exécutez la commande suivante:
jwt ID_TOKEN
Vérifiez la configuration OIDC.
Le paramètre
authentication.oidc
du fichier de configuration du cluster d'utilisateur comporte les champsgroup
etusername
, 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émentsgroup-claim
etusername-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
etuser
dans la sectionauthentication.oidc
du fichier de configuration de cluster sont présentes dans le jeton d'ID.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 groupesgroup-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éfixeusernameprefix
ougroupprefix
spécifié dans le fichier de configuration du cluster d'utilisateur.Notez que si
usernameprefix
est vide et queusername
est une valeur autre queemail
, le préfixe est défini par défaut surissuerurl#
. Pour désactiver les préfixes de noms d'utilisateur, définissezusernameprefix
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 erreurUnauthorized
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
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