Version 1.8. Cette version est compatible conformément à la politique de compatibilité avec les versions d'Anthos, en fournissant les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant les clusters Anthos sur Bare Metal. Pour en savoir plus, consultez les notes de version 1.8. Pour obtenir la liste complète des releases mineures et des correctifs par ordre chronologique, reportez-vous aux notes de version combinées.

Versions disponibles : 1.9  |   1.8  |   1.7

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 pour des clusters Anthos sur Bare Metal, la spécification OIDC dans le fichier de configuration du cluster a généralement été mal configurée. 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.

  1. Utilisez kubectl logs pour imprimer les journaux Anthos Identity Service :

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
    deployment/ais --all-containers=true
    
  2. 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.
    
  3. Si vous avez identifié un problème de configuration dans les journaux, passez à la section Reconfigurer OIDC.

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

  1. 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
    
  2. Examinez les valeurs du champ pour confirmer que la spécification est correctement configurée pour votre fournisseur OIDC.

  3. Si vous avez identifié un problème de configuration dans la spécification, passez à la section Reconfigurer OIDC.

  4. 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 CRD ClientConfig permettent de configurer OIDC pour Cloud Console et pour 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 Obligatoire Description Format
nom Oui Nom de la configuration OIDC à créer. Chaîne
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==

Chaîne
clientID Oui ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID. Chaîne
clientSecret Non Secret partagé entre l'application cliente OIDC et le fournisseur OIDC. Chaîne
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é. Chaîne
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. Chaîne
issuerURI Oui 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 Oui L'URL de redirection que kubectl utilise pour l'autorisation. Chaîne d'URL
scopes Oui 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 Non 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. Chaîne
userPrefix Non Préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Chaîne
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