Résoudre les problèmes liés à OIDC dans les clusters Anthos sur Bare Metal

Cette page vous explique comment identifier et résoudre les problèmes liés à OpenID Connect (OIDC) avec les clusters Anthos sur Bare Metal.

Identifier les problèmes liés à OIDC

Lorsque OIDC ne fonctionne pas avec des clusters Anthos sur Bare Metal, cela vient généralement d'un problème de configuration dans la spécification OIDC, dans le fichier de configuration du cluster. Cette section fournit des instructions pour examiner les journaux et la spécification OIDC afin d'identifier la cause d'un problème OIDC.

Examiner les journaux Anthos Identity Service

Anthos Identity Service est compatible avec OIDC dans les clusters Anthos sur Bare Metal.

Utilisez kubectl logs pour imprimer les journaux Anthos Identity Service :

kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

Recherchez dans les journaux les erreurs susceptibles de vous aider à diagnostiquer les problèmes liés à OIDC.

Si vous ne parvenez pas à vous authentifier avec OIDC, les journaux Anthos Identity Service fournissent les informations les plus pertinentes et les plus utiles pour résoudre le problème.

Par exemple, si la spécification OIDC (dans le fichier de configuration du cluster) contient une faute de frappe dans le champ issuerURL, telle que htps://accounts.google.com (un "t" manquant dans HTTPS), les journaux Anthos Identity Service contiendront une entrée de ce type :
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Si vous avez identifié un problème de configuration dans les journaux, passez à la section Reconfigurer OIDC.
Si vous ne parvenez pas à diagnostiquer et à résoudre le problème vous-même, contactez le service Cloud Customer Care.

Cloud Customer Care aura besoin des journaux Anthos Identity Service et de la spécification OIDC pour diagnostiquer et résoudre les problèmes OIDC.

Vérifier la spécification OIDC dans votre cluster

Les informations OIDC de votre cluster sont spécifiées dans l'objet clientconfig de l'espace de noms kube-public.

Utilisez kubectl get pour imprimer la ressource OIDC pour votre cluster :
```
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
clientconfig.authentication.gke.io default -o yaml
```
Remarque : La spécification clientconfig peut être légèrement différente de la spécification OIDC dans votre fichier de configuration de cluster. Par exemple, l'URL du fournisseur OIDC est spécifiée avec le champ issuerURL dans le fichier de configuration du cluster, mais l'objet clientconfig renvoie ces informations dans le champ issuerURI.
Examinez les valeurs du champ pour confirmer que la spécification est correctement configurée pour votre fournisseur OIDC.
Si vous avez identifié un problème de configuration dans la spécification, passez à la section Reconfigurer OIDC.
Si vous ne parvenez pas à diagnostiquer et à résoudre le problème vous-même, contactez le service Cloud Customer Care.

Cloud Customer Care aura besoin des journaux Anthos Identity Service et de la spécification OIDC pour diagnostiquer et résoudre les problèmes OIDC.

Reconfigurer OIDC

Si vous avez identifié des problèmes dans les journaux Anthos Identity Service ou dans l'objet clientconfig, vous pouvez reconfigurer OIDC dans votre cluster (sans recréer le cluster) pour les résoudre. Pour reconfigurer OIDC, modifiez l'objet KRM par défaut de type clientconfig dans l'espace de noms kube-public :

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

Les détails de l'objet ClientConfig CRD permettent de configurer OIDC pour la console Google Cloud et le plug-in d'authentification pour Anthos. Pour en savoir plus sur les informations OIDC incluses dans l'objet CRD ClientConfig, consultez le fichier YAML suivant et la table de descriptions de champs associée.

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

Le tableau suivant décrit les champs de l'objet CRD ClientConfig oidc.

Champ	Requis	Description	Format
nom	Yes	Nom de la configuration OIDC à créer.	String
certificateAuthorityData	Non	Certificat encodé au format PEM encodé en `base64` pour le fournisseur OIDC. Pour créer la chaîne, encodez le certificat, y compris les en-têtes, en `base64`. Incluez la chaîne obtenue dans `certificateAuthorityData` en tant que ligne unique. Exemple : `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	Yes	ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID.	String
clientSecret	Non	Secret partagé entre l'application cliente OIDC et le fournisseur OIDC.	String
extraParams	Non	Paramètres de clé-valeur supplémentaires à envoyer au fournisseur OpenID. Si vous autorisez un groupe, transmettez `resource=token-groups-claim`. Si votre serveur d'autorisation vous demande l'autorisation, pour l'authentification avec Microsoft Azure et Okta, définissez `extraParams` sur `prompt=consent`. Pour Cloud Identity, définissez `extraParams` sur `prompt=consent,access_type=offline`.	Liste d'éléments séparés par une virgule
groupsClaim	Non	Revendication JWT que le fournisseur utilise pour renvoyer vos groupes de sécurité.	String
groupPrefix	Non	Préfixe ajouté aux revendications de groupe pour éviter les conflits avec les noms existants. Par exemple, si vous avez deux groupes nommés `foobar`, ajoutez un préfixe `gid-`. Le groupe ainsi obtenu est `gid-foobar`.	String
issuerURI	Yes	URL où les requêtes d'autorisation sont envoyées à votre OpenID, telle que `https://example.com/adfs`. Le serveur de l'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. L'URI doit utiliser le protocole HTTPS.	Chaîne d'URL
kubectlRedirectURI	Yes	L'URL de redirection que `kubectl` utilise pour l'autorisation.	Chaîne d'URL
scopes	Yes	Niveaux d'accès supplémentaires à envoyer au fournisseur OpenID. Microsoft Azure et Okta nécessitent le niveau d'accès `offline_access`.	Liste d'éléments séparés par une virgule
userClaim	Yes	Revendication JWT à utiliser comme nom d'utilisateur. Vous pouvez choisir d'autres revendications, telles que l'e-mail ou le nom, en fonction du fournisseur OpenID. Toutefois, les revendications autres que l'e-mail sont précédées de l'URL de l'émetteur pour éviter les conflits de noms.	String
userPrefix	Non	Préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants.	String
proxy	Non	Serveur proxy à utiliser pour la méthode `auth`, le cas échéant. Par exemple : `http://user:password@10.10.10.10:8888.`	Chaîne