Configurer des fournisseurs OIDC pour l'authentification auprès des clusters

Ce document est destiné aux administrateurs de plate-forme ou à toute personne chargée de gérer la configuration des identités dans votre organisation. Il explique comment configurer le fournisseur d'identité OpenID Connect (OIDC) de votre choix pour l'authentification auprès des clusters Kubernetes qui ne sont pas sur Google Cloud.

Enregistrer une application cliente auprès de votre fournisseur

Lors du flux d'authentification pour les utilisateurs, le cluster utilise un ID client et un secret pour se connecter à votre fournisseur d'identité. Vous pouvez obtenir un ID client et un code secret auprès de votre fournisseur d'identité en configurant une application cliente pour Kubernetes. La procédure de configuration d'une application cliente dépend de votre fournisseur. Vous trouverez dans la section suivante des informations spécifiques sur l'enregistrement des fournisseurs les plus couramment utilisés.

Pour les URL de redirection, spécifiez les valeurs suivantes :

  • https://console.cloud.google.com/kubernetes/oidc est l'URL de redirection de la console Google Cloud .
  • http://localhost:PORT/callback est l'URL de redirection de gcloud CLI. Vous pouvez spécifier n'importe quel numéro de port supérieur à 1024.
  • APISERVER_URL:11001/finish-login est l'URL de redirection si vous choisissez de vous authentifier à l'aide de l'accès au nom de domaine complet. Remplacez APISERVER_URL par le nom de domaine complet du serveur d'API Kubernetes du cluster. Par exemple, si la valeur de APISERVER_URL est https://apiserver.company.com, la valeur de redirect_uri doit être https://apiserver.company.com:11001/finish-login.

Enregistrez l'ID client et le secret que vous obtenez à l'étape d'enregistrement. Partagez ces informations avec les administrateurs de cluster qui doivent configurer leurs clusters.

Informations de configuration du fournisseur d'identité

Cette section explique comment enregistrer une application cliente auprès de Microsoft Active Directory Federation Services (AD FS) ou de Microsoft Entra ID.

Microsoft AD FS

Utilisez un ensemble d'assistants de gestion AD FS pour configurer votre serveur AD FS et votre base de données utilisateur AD.

  1. Ouvrez le volet de gestion AD FS.

  2. Sélectionnez Groupes d'applications > Actions > Ajouter un groupe d'applications.

  3. Sélectionnez Application de serveur. Saisissez le nom et la description de votre choix. Cliquez sur Suivant.

  4. Saisissez vos deux URL de redirection, comme indiqué ci-dessus. Vous recevez un ID client. AD FS identifie le cluster à l'aide de cet ID client. Notez l'identifiant client pour pouvoir l'utiliser ultérieurement.

  5. Sélectionnez Générer une clé secrète partagée. Le mécanisme d'authentification Kubernetes utilise ce secret pour s'authentifier auprès du serveur AD FS. Enregistrez la clé secrète pour plus tard.

Configurer des groupes de sécurité (facultatif)

  1. Dans la gestion AD FS, sélectionnez Approbations par un tiers de confiance > Ajouter une approbation par un tiers de confiance.

  2. Sélectionnez Prise en charge des revendications, puis cliquez sur Démarrer.

  3. Sélectionnez Saisir manuellement les données concernant le tiers de confiance.

  4. Saisissez un nom à afficher.

  5. Ignorez les deux étapes suivantes.

  6. Saisissez un identifiant d'approbation par un tiers de confiance. Suggestion : token-groups-claim.

  7. Pour Stratégie de contrôle d'accès, sélectionnez Autoriser tout le monde. Cela signifie que tous les utilisateurs partagent leurs informations de groupe de sécurité avec gcloud CLI et la consoleGoogle Cloud .

  8. Cliquez sur Terminer.

Mapper des attributs LDAP à des noms de revendication

  1. Dans la gestion AD FS, sélectionnez Approbations par des tiers de confiance > Éditer la stratégie d'émission de revendication.

  2. Sélectionnez Envoyer les attributs LDAP en tant que revendications, puis cliquez sur Suivant.

  3. Dans Nom de la règle de revendication, saisissez groups.

  4. Dans Liste des attributs, sélectionnez Active Directory.

  5. Dans la table, pour Attribut LDAP, sélectionnez :

    • AD FS version 5.0 ou ultérieure : Groupes de jetons qualifiés par nom de domaine
    • Versions d'AD FS antérieures à la version 5.0 : Groupes de jetons - Noms qualifiés
  6. Dans Type de revendication sortante, sélectionnez :

    • AD FS version 5.0 et ultérieure : Groupe
    • Versions d'AD FS antérieures à la version 5.0 : groupes
  7. Cliquez sur Finish (Terminer), puis sur Apply (Appliquer).

Enregistrer l'application cliente Kubernetes auprès d'AD FS

Ouvrez une fenêtre PowerShell en mode Administrateur, puis entrez la commande suivante :

Grant-AD FSApplicationPermission `
  -ClientRoleIdentifier "[CLIENT_ID]" `
 -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
  -ScopeName "allatclaims", "openid"

Remplacez les éléments suivants :

  • [CLIENT_ID] est l'ID client que vous avez obtenu précédemment.

  • [SERVER_ROLE_IDENTIFIER] est l'identifiant de revendication que vous avez saisi précédemment. Rappelez-vous que l'identifiant suggéré était token-groups-claim.

Microsoft Entra ID

Pour enregistrer un client OAuth avec Microsoft Entra ID, procédez comme suit :

  1. Si vous ne l'avez pas déjà fait, configurez un locataire Microsoft Entra.

  2. Enregistrez une application dans Microsoft Entra ID.

  3. Dans le centre d'administration Microsoft Entra, ouvrez la page Enregistrements d'applications et sélectionnez votre application. La page de présentation de l'application s'ouvre.

  4. Créez un code secret du client :

    1. Dans le menu de navigation, cliquez sur Certificats et secrets.
    2. Cliquez sur l'onglet Codes secrets du client.
    3. Cliquez sur Nouvelle clé secrète client. Attribuez un nom à votre secret, puis cliquez sur Ajouter.
    4. Enregistrez la valeur du secret dans un emplacement sécurisé. Vous ne pourrez pas le récupérer après la fermeture ou l'actualisation de la page.

    Pour en savoir plus, consultez Ajouter et gérer des identifiants d'application dans Microsoft Entra ID.

  5. Ajoutez des URI de redirection :

    1. Dans le menu de navigation, cliquez sur Authentification.
    2. Dans la section Configurations de la plate-forme, cliquez sur Ajouter une plate-forme. Le volet Configurer les plates-formes s'ouvre.
    3. Cliquez sur Web.
    4. Dans le champ URI de redirection, saisissez http://localhost:PORT/callback pour le flux de connexion de gcloud CLI. Choisissez un PORT supérieur à 1 024.
    5. Cliquez sur Configurer.
    6. Cliquez sur Ajouter un URI pour ajouter un autre URI.
    7. Saisissez https://console.cloud.google.com/kubernetes/oidc pour le flux de connexion à la consoleGoogle Cloud .
    8. Enregistrez votre configuration.

    Pour en savoir plus, consultez Ajouter un URI de redirection à votre application.

Votre inscription client est terminée. Vous devez disposer des informations suivantes pour pouvoir les communiquer à votre administrateur de cluster :

  • URI d'émetteur : https://login.microsoftonline.com/TENANT_ID/v2.0. L'ID de locataire est affiché en tant que Directory (tenant) ID sur la page de présentation de l'application dans le centre d'administration Microsoft Entra.

  • ID client : l'ID client est affiché en tant que Application (client) ID sur la page de vue d'ensemble de l'application dans le Centre d'administration Microsoft Entra.

  • Code secret du client : valeur du code secret du client que vous avez créé lorsque vous avez enregistré l'application cliente. Si vous n'avez pas accès à cette valeur, générez un nouveau secret.

Configuration avancée pour Microsoft Entra ID

N'envisagez d'utiliser cette configuration avancée que lorsque vous souhaitez configurer des clusters avec des règles d'autorisation basées sur des groupes Microsoft Entra ID, où les utilisateurs des clusters appartiennent à plus de 200 groupes Microsoft Entra ID. La configuration avancée pour Microsoft Entra ID est compatible avec les plates-formes suivantes :

  • Google Distributed Cloud sur site (VMware et Bare Metal) : à partir de la version 1.14
  • GKE sur AWS : à partir de la version 1.14 (version de Kubernetes 1.25 ou ultérieure)
  • GKE sur Azure : à partir de la version 1.14 (version 1.25 ou ultérieure de Kubernetes)

Avant de commencer, assurez-vous que chaque utilisateur dispose d'une adresse e-mail associée configurée comme identifiant dans Microsoft Entra ID. Cette adresse e-mail est utilisée pour valider l'identité de l'utilisateur et authentifier la requête.

Vous devez vous assurer que le client que vous avez enregistré dans la section précédente dispose des autorisations déléguées pour obtenir des informations sur les utilisateurs et les groupes à partir de l 'API Microsoft Graph. Ces autorisations permettent au mécanisme d'authentification Kubernetes d'accéder aux points de terminaison de l'API Microsoft Graph à partir desquels les informations de groupe sont extraites. Sans cette étape, le cluster ne peut pas obtenir d'informations sur les groupes de l'utilisateur, ce qui empêche les règles d'autorisation RBAC basées sur des groupes de fonctionner comme prévu.

Vous devez disposer des autorisations d'administrateur global ou d'administrateur de l'organisation pour effectuer cette étape de configuration.

  1. Connectez-vous au centre d'administration Microsoft Entra.
  2. Sélectionnez le locataire Microsoft Entra contenant votre application cliente.
  3. Sélectionnez Enregistrements d'applications, puis sélectionnez votre application cliente.
  4. Sélectionnez Autorisations de l'API – Ajouter une autorisation – Microsoft Graph – Autorisations déléguées.
  5. Dans l'onglet Groupe, cochez Group.Read.All. Dans l'onglet Utilisateur, cochez User.Read.All.
  6. Cliquez sur Ajouter des autorisations pour terminer le processus.
  7. Accordez l'autorisation au nom de tous les utilisateurs en cliquant sur Grant admin consent for… (Accorder l'autorisation de l'administrateur pour…). Pour en savoir plus, consultez En savoir plus sur les autorisations des API et le consentement administrateur.

Partager les détails du fournisseur d'identité

Partagez les informations suivantes sur le fournisseur avec votre administrateur de cluster pour la configuration du cluster :

  • L'URI d'émetteur du fournisseur.
  • Le code secret du client.
  • L'ID client.
  • L'URI de redirection et le port que vous avez spécifiés pour gcloud CLI.
  • Le champ du nom d'utilisateur (revendication) que votre fournisseur utilise pour identifier les utilisateurs dans ses jetons (la valeur par défaut supposée lors de la configuration des clusters est sub).
  • Le champ du nom du groupe (revendication) que votre fournisseur utilise pour renvoyer les groupes de sécurité, le cas échéant.
  • Tous les champs d'application ou paramètres supplémentaires spécifiques à votre fournisseur, comme décrit dans la section précédente. Par exemple, si votre serveur d'autorisation vous demande votre autorisation pour l'authentification avec Microsoft Entra ID et Okta, l'administrateur du cluster doit spécifier prompt=consent en tant que paramètre. Si vous avez configuré AD FS pour fournir des informations de groupe de sécurité, le paramètre supplémentaire approprié est resource=token-groups-claim (ou bien l'identifiant d'approbation de partie de confiance de votre choix).
  • (Facultatif) Si votre fournisseur n'utilise pas de certificat signé par une autorité de certification publique (par exemple, si vous utilisez des certificats autosignés), vous aurez besoin d'un certificat (ou d'une chaîne de certificats) du fournisseur d'identité. Le certificat (ou la chaîne de certificats) doit contenir au moins le certificat racine (les chaînes partielles sont acceptées, à condition qu'elles soient contiguës jusqu'au certificat racine). Lorsque vous fournissez cette valeur dans ClientConfig, elle doit être mise en forme en tant que chaîne encodée en base64. Pour créer la chaîne, concaténez tous les certificats encodés au format PEM en une seule chaîne, puis encodez-la en base64.

Pour en savoir plus sur les paramètres de configuration des clusters, consultez Configurer des clusters.

Étapes suivantes