Configurer des fournisseurs OIDC pour GKE Identity Service
Ce document explique comment configurer le fournisseur d'identité OpenID Connect (OIDC) que vous avez choisi pour GKE Identity Service. Pour en savoir plus sur GKE Identity Service, consultez la présentation.
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. Si vous êtes administrateur de cluster ou opérateur d'application, demandez à l'administrateur de votre plate-forme de suivre cette section avant de commencer à configurer vos clusters pour GKE Identity Service au niveau du parc ou à configurer des clusters pour GKE Identity Service avec OIDC.
Enregistrer GKE Identity Service auprès de votre fournisseur
La configuration de GKE Identity Service nécessite un seul ID client et un seul secret de la part de votre fournisseur d'identité. Cet ID et ce secret sont utilisés par GKE Identity Service lors de la connexion au fournisseur dans le cadre du flux d'authentification pour les utilisateurs. Pour les obtenir, vous devez enregistrer GKE Identity Service auprès de votre fournisseur en tant qu'application cliente, en suivant la procédure habituelle du fournisseur choisi. 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 Google Cloud Console.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. RemplacezAPISERVER-URL
par l'URL du nom de domaine complet du serveur de cluster. Par exemple, si la valeur deAPISERVER-URL
esthttps://cluster.company.com
, la valeur deredirect_uri
doit êtrehttps://cluster.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 GKE Identity Service. Vous devez vous assurer que vous avez effectué les opérations suivantes:
- Configurez votre service de noms de domaine (DNS) pour résoudre
APISERVER-URL
en adresses IP virtuelles du plan de contrôle. Les utilisateurs peuvent accéder au cluster à l'aide de ce nom de domaine. - Utilisez un certificat SNI (Server Name Indication) émis par l'autorité de certification (CA) de votre entreprise. Ce certificat mentionne spécifiquement
APISERVER-URL
comme domaine valide, éliminant ainsi les avertissements potentiels de certificat pour les utilisateurs. Vous pouvez fournir le certificat SNI lors de la création du cluster. Pour plus d'informations sur l'authentification à l'aide de certificats SNI, consultez la section Authentification par certificat SNI. - Si les certificats SNI ne sont pas possibles, configurez tous les appareils des utilisateurs pour qu'ils approuvent le certificat CA du cluster. Cela évite les avertissements de certificat, mais nécessite de distribuer le certificat CA de cluster à tous les utilisateurs.
Pour en savoir plus sur l'accès utilisateur à l'aide de ces certificats, consultez la section S'authentifier à l'aide de l'accès au nom de domaine complet.
Informations de configuration du fournisseur
Cette section fournit des informations supplémentaires spécifiques au fournisseur pour l'enregistrement de GKE Identity Service. Si votre fournisseur est listé ici, enregistrez GKE Identity Service auprès de votre fournisseur en tant qu'application cliente en suivant les instructions ci-dessous.
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.
Ouvrez le volet de gestion AD FS.
Sélectionnez Groupes d'applications > Actions > Ajouter un groupe d'applications.
Sélectionnez Application de serveur. Saisissez le nom et la description de votre choix. Cliquez sur Suivant.
Saisissez vos deux URL de redirection, comme indiqué ci-dessus. Vous recevez un ID client. C'est avec celui-ci que le serveur AD FS identifie GKE Identity Service. Notez l'identifiant client pour pouvoir l'utiliser ultérieurement.
Sélectionnez Générer une clé secrète partagée. GKE Identity Service s'authentifie auprès du serveur AD FS à l'aide de ce secret. Enregistrez la clé secrète pour plus tard.
Configurer des groupes de sécurité (facultatif)
Dans la gestion AD FS, sélectionnez Approbations par un tiers de confiance > Ajouter une approbation par un tiers de confiance.
Sélectionnez Prise en charge des revendications, puis cliquez sur Démarrer.
Sélectionnez Saisir manuellement les données concernant le tiers de confiance.
Saisissez un nom à afficher.
Ignorez les deux étapes suivantes.
Saisissez un identifiant d'approbation par un tiers de confiance. Suggestion :
token-groups-claim
.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 Google Cloud Console.
Cliquez sur Terminer.
Mapper des attributs LDAP à des noms de revendication
Dans la gestion AD FS, sélectionnez Approbations par des tiers de confiance > Éditer la stratégie d'émission de revendication.
Sélectionnez Envoyer les attributs LDAP en tant que revendications, puis cliquez sur Suivant.
Dans Nom de la règle de revendication, saisissez
groups
.Dans Liste des attributs, sélectionnez Active Directory.
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
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
Cliquez sur Finish (Terminer), puis sur Apply (Appliquer).
Enregistrer GKE Identity Service avec 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
.
Azure AD
Enregistrer un client OAuth avec Azure
Pour enregistrer un client OAuth avec Azure, procédez comme suit :
Si vous ne l'avez pas déjà fait, configurez un locataire sur Azure Active Directory.
Enregistrez une application avec la plate-forme Microsoft Identity.
Ouvrez la page Enregistrements d'applications sur le portail Azure et sélectionnez votre application par nom.
Créez un code secret du client.
Cliquez sur Ajouter un certificat ou un secret sous Essentials. Une liste de certificats et une liste de secrets s'affichent.
Cliquez sur Nouvelle clé secrète client. Attribuez un nom à votre secret, puis cliquez sur Ajouter.
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.
Ajoutez des URI de redirection.
Revenez à la page de l'application.
Sélectionnez Ajouter un URI de redirection sous Essentials. La page Authentification s'affiche.
Sélectionnez Ajouter une plate-forme. Le panneau Configurer les plates-formes s'affiche alors sur la droite.
Sélectionnez Web. Sous URI de redirection, saisissez
http://localhost:PORT/callback
pour le flux de connexion de gcloud CLI. Choisissez un PORT supérieur à 1 024. Cliquez sur le bouton Configurer.Cliquez sur le bouton Ajouter un URI pour ajouter un autre URI
https://console.cloud.google.com/kubernetes/oidc
pour la connexion à Google Cloud Console.Cliquez sur le bouton Enregistrer en haut de l'écran.
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 queDirectory (tenant) ID
sur la page "Application" du portail Azure.ID client : l'ID client est affiché en tant que
Application (client) ID
sur la page "Application" du portail Azure.Secret du client : vous avez reçu ce secret à la dernière étape. Vous ne pourrez pas le récupérer si vous fermez la page lors de la création du secret. Veillez à enregistrer la valeur dans un emplacement sécurisé (ou à générer un nouveau secret si vous perdez le précédent).
Configuration avancée pour Azure AD
N'utilisez cette configuration avancée que si vous souhaitez configurer des clusters avec des règles d'autorisation basées sur des groupes Azure AD où les utilisateurs des clusters appartiennent à plus de 200 groupes Azure AD. La configuration avancée d'Azure AD est compatible avec les plates-formes suivantes:
- Clusters GKE sur site (VMware et Bare Metal): à partir de GKE Enterprise 1.14
- Clusters Anthos sur AWS: à partir de GKE Enterprise 1.14 (Kubernetes version 1.25 ou ultérieure)
- Clusters Anthos sur Azure: à partir de GKE Enterprise 1.14 (version de Kubernetes 1.25 ou ultérieure)
- Clusters Anthos sur AWS (génération précédente): À partir de GKE Enterprise 1.14
Avant de commencer, assurez-vous que chaque utilisateur est associé à une adresse e-mail configurée comme identifiant dans Azure AD. GKE Identity Service utilise l'adresse e-mail de l'utilisateur pour valider son identité 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 plug-in GKE Identity Service d'accéder aux points de terminaison de l'API Microsoft Graph à partir desquels les informations de groupe sont extraites. Sans cette étape, GKE Identity Service ne peut pas recenser les groupes de l'utilisateur, et les règles d'autorisation RBAC basées sur des groupes ne fonctionneront pas comme prévu.
Vous devez disposer des autorisations d'administrateur global ou d'administrateur de l'organisation pour effectuer cette étape de configuration.
- Connectez-vous au portail Azure.
- Si vous avez accès à plusieurs locataires, définissez un filtrage par annuaire et par abonnement, dans le menu supérieur, pour sélectionner le locataire contenant l'enregistrement de votre application cliente.
- Sélectionnez Azure Active Directory – Inscriptions des applications, puis sélectionnez votre application cliente.
- Sélectionnez Autorisations de l'API – Ajouter une autorisation – Microsoft Graph – Autorisations déléguées.
- Dans l'onglet Groupe, cochez Group.Read.All. Dans l'onglet Utilisateur, cochez User.Read.All.
- Cliquez sur Ajouter des autorisations pour terminer le processus.
- Accordez l'autorisation au nom de tous les utilisateurs en cliquant sur le bouton Grant admin consent for… (Accorder l'autorisation de l'administrateur pour…). Pour en savoir plus sur l'octroi du consentement des administrateurs, consultez En savoir plus sur les autorisations des API et le consentement administrateur.
Partager les détails du fournisseur
Assurez-vous que l'administrateur du cluster dispose des informations requises suivantes 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 Azure et Okta, l'administrateur du cluster doit spécifier
prompt=consent
en tant que paramètre. Si vous avez configuré ADFS pour fournir des informations de groupe de sécurité, le paramètre supplémentaire approprié estresource=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 avez 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 minimum le certificat racine (les chaînes partielles sont acceptées, à condition que la chaîne se rapporte 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 le ou les certificats complets encodés au format PEM en une seule chaîne, puis encodez-le en base64.
Vous pouvez consulter la liste complète des paramètres de configuration GKE Identity Service sur la page Configurer les clusters.