Configurer des clusters pour GKE Identity Service avec OIDC

Ce document est destiné aux administrateurs de cluster ou aux opérateurs d'application qui souhaitent configurer GKE Identity Service sur des clusters individuels, ce qui permet aux développeurs et à d'autres utilisateurs de se connecter aux clusters à l'aide de leurs informations d'identité existantes issues d'un fournisseur OpenID Connect (OIDC). Dans ce guide, nous partons du principe que vous avez lu la Présentation de GKE Identity Service.

Pour savoir comment configurer GKE Identity Service pour un cluster avec un fournisseur LDAP, consultez la page Configurer GKE Identity Service avec LDAP.
Pour savoir comment configurer GKE Identity Service au niveau du parc pour les types de clusters compatibles, avec votre configuration d'authentification gérée par Google Cloud, consultez la page Configurer GKE Identity Service pour un parc.

Les instructions de ce document partent du principe que GKE Identity Service a déjà été enregistré auprès de votre fournisseur d'identité en tant qu'application cliente.

Vue d'ensemble de la configuration

La configuration de GKE Identity Service pour un cluster individuel implique les utilisateurs et étapes suivants :

L'administrateur de plate-forme enregistre GKE Identity Service en tant qu'application cliente auprès de son fournisseur d'identité de prédilection, et obtient en retour un ID client et un secret. Pour ce faire, suivez les instructions de la page Configurer des fournisseurs pour GKE Identity Service.
L'administrateur de cluster configure les clusters pour qu'ils utilisent le service, en suivant les instructions de cette page.
L'administrateur de cluster configure l'accès des utilisateurs et configure éventuellement le contrôle des accès basé sur les rôles Kubernetes (RBAC) pour les utilisateurs des clusters. Pour ce faire, suivez les instructions de la page Configurer l'accès des utilisateurs à GKE Identity Service.

Prérequis

Votre cluster doit être un cluster GKE sur site (VMware ou Bare Metal), sur AWS, ou sur Azure. La configuration OIDC par cluster n'est pas compatible avec les clusters associés ou les clusters GKE.
Pour vous authentifier via la console Google Cloud, chaque cluster que vous souhaitez configurer pour l'authentification OIDC doit être enregistré dans le parc de votre projet.

Avant de commencer

Assurez-vous que l'administrateur de votre plate-forme vous a fourni toutes les informations nécessaires de la page Enregistrer GKE Identity Service auprès de votre fournisseur avant de commencer la configuration, y compris l'ID client et le secret pour GKE Identity Service.
Assurez-vous que les outils de ligne de commande suivants sont installés :
- La dernière version de Google Cloud CLI, qui inclut gcloud, l'outil de ligne de commande qui permet d'interagir avec Google Cloud. Si vous devez installer Google Cloud CLI, consultez le guide d'installation.
- kubectl pour exécuter des commandes sur les clusters Kubernetes. Si vous devez installer kubectl, suivez ces instructions.
Si vous utilisez Cloud Shell comme environnement shell pour interagir avec Google Cloud, ces outils sont installés pour vous.
Assurez-vous d'avoir initialisé gcloud CLI à utiliser avec le projet dans lequel les clusters sont enregistrés.
Si vous devez vous connecter au plan de contrôle d'un cluster GKE sur AWS ou sur Azure situé en dehors de votre VPC actuel via un hôte bastion, assurez-vous, avant de procéder à cette configuration, d'avoir créé l'hôte bastion et d'avoir ouvert un tunnel SSH sur le port 8118. Ajoutez ensuite HTTPS_PROXY=http://localhost:8118 en préfixe des commandes kubectl lorsque vous suivrez ce guide. Si vous avez utilisé un port différent pour ouvrir le tunnel SSH, remplacez 8118 par le port sélectionné.

Configurer les clusters

Pour configurer vos clusters afin qu'ils utilisent le fournisseur choisi, GKE Identity Service a besoin que vous spécifiez des informations sur le fournisseur d'identité, les informations de jeton JWT qu'il fournit pour l'identification de l'utilisateur, et les autres informations fournies lors de l'enregistrement de GKE Identity Service en tant qu'application cliente.

Par exemple, si votre fournisseur crée des jetons d'identité avec les champs suivants (entre autres), où iss correspond à l'URI du fournisseur d'identité, sub identifie l'utilisateur et groupList répertorie les groupes de sécurité auquel l'utilisateur appartient :

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

...votre configuration contiendra les champs correspondants suivants :

issuerURI: 'https://server.example.com'
userClaim: 'sub'
groupsClaim: 'groupList'
...

C'est l'administrateur de votre plate-forme, ou la personne qui gère l'identité dans votre organisation, qui doit vous fournir la plupart des informations nécessaires à la création de la configuration.

GKE Identity Service utilise un type de ressource personnalisée Kubernetes (CRD) appelé ClientConfig pour la configuration du cluster, avec des champs pour toutes les informations dont GKE Identity Service a besoin pour interagir avec le fournisseur d'identité. Chaque cluster GKE dispose d'une ressource ClientConfig nommée default dans l'espace de noms kube-public que vous mettez à jour avec vos détails de configuration, en suivant les instructions ci-dessous.

Vous trouverez des exemples de configurations spécifiques pour les fournisseurs courants dans la section Configurations spécifiques aux fournisseurs.

kubectl

Pour modifier votre ClientConfig par défaut, assurez-vous de pouvoir vous connecter à votre cluster via kubectl, puis exécutez la commande suivante :

kubectl --kubeconfig=KUBECONFIG_PATH edit ClientConfigs default -n kube-public

Remplacez KUBECONFIG_PATH par le chemin d'accès au fichier kubeconfig de votre cluster, par exemple $HOME/.kube/config.

Un éditeur de texte charge la ressource ClientConfig de votre cluster. Ajoutez l'objet spec.authentication.oidc comme indiqué ci-dessous. Ne modifiez aucune donnée par défaut déjà écrite.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      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
      enableAccessToken: ENABLE_ACCESS_TOKEN
    proxy: PROXY_URL

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Le tableau suivant décrit les champs de l'objet oidc ClientConfig. La plupart des champs sont facultatifs. Les champs que vous devez ajouter dépendent de votre fournisseur d'identité et des options de configuration choisies par l'administrateur de votre plate-forme lors de la configuration du fournisseur pour GKE Identity Service.

Champ	Obligatoire	Description	Format
nom	Oui	Nom que vous souhaitez utiliser pour identifier cette configuration, généralement le nom du fournisseur d'identité. Le nom d'une configuration doit commencer par une lettre suivie de 1 à 39 lettres minuscules, chiffres ou traits d'union, et ne peut pas se terminer par un trait d'union.	Chaîne
certificateAuthorityData	Non	Si fournie par votre administrateur de plate-forme, une chaîne de certificat encodée au format PEM pour le fournisseur d'identité. Incluez la chaîne obtenue dans `certificateAuthorityData` en tant que ligne unique.	Chaîne
clientID	Oui	L'ID client renvoyé lors de l'enregistrement de GKE Identity Service auprès de votre fournisseur OIDC.	Chaîne
clientSecret	Non	Secret partagé entre l'application cliente OIDC et le fournisseur OIDC.	Chaîne
deployCloudConsoleProxy	Non	Indique si un proxy est déployé et permet à la console Google Cloud de se connecter à un fournisseur d'identité sur site qui n'est pas accessible publiquement sur Internet. Par défaut, cette valeur est définie sur `false`.	Booléen
extraParams	Non	Paramètres de clé=valeur supplémentaires à envoyer au fournisseur d'identité, spécifiés sous forme de liste séparée par des virgules (par exemple, "prompt=consent,access_type=offline").	Liste d'éléments séparés par une virgule
groupsClaim	Non	La revendication JWT (nom du champ) que votre fournisseur utilise pour renvoyer les groupes de sécurité d'un compte.	Chaîne
groupPrefix	Non	Le préfixe que vous souhaitez ajouter aux noms de groupe de sécurité pour éviter les conflits avec les noms existants dans vos règles de contrôle d'accès si vous avez des configurations pour plusieurs fournisseurs d'identité (généralement le nom du fournisseur).	Chaîne
issuerURI	Oui	L'URI vers lequel les requêtes d'autorisation sont envoyées à votre fournisseur d'identité. L'URI doit utiliser le protocole HTTPS.	Chaîne d'URL
kubectlRedirectURI	Oui	Le port et l'URL de redirection utilisés par gcloud CLI et spécifiés par l'administrateur de la plate-forme à l'enregistrement, généralement au format "http://localhost:PORT/callback".	Chaîne d'URL
scopes	Oui	Niveaux d'accès supplémentaires à envoyer au fournisseur OpenID. Par exemple, 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	La revendication JWT (nom du champ) utilisée par votre fournisseur pour identifier un compte utilisateur. Si vous ne spécifiez pas de valeur ici, GKE Identity Service utilise "sub", qui est la revendication d'ID utilisateur utilisée par de nombreux fournisseurs. Vous pouvez choisir d'autres revendications, telles que l'adresse e-mail our le nom, selon le fournisseur OpenID. Les revendications autres que l'adresse e-mail sont précédées de l'URL de l'émetteur pour éviter les conflits de noms.	Chaîne
userPrefix	Non	Le préfixe que vous souhaitez ajouter aux revendications de l'utilisateur pour éviter les conflits avec les noms existants, si vous ne souhaitez pas utiliser le préfixe par défaut.	Chaîne
enableAccessToken	Non	Si cette option est activée, GKE Identity Service peut utiliser le point de terminaison userinfo du fournisseur d'identité pour obtenir des informations sur les groupes lorsqu'un utilisateur se connecte à partir de la ligne de commande. Cela vous permet d'utiliser des groupes de sécurité pour l'autorisation si vous avez un fournisseur (comme Okta) qui fournit des revendications de groupe à partir de ce point de terminaison. Si ce champ n'est pas défini, la valeur correspond à `false`.	Booléen
proxy	Non	Adresse du serveur proxy à utiliser pour se connecter au fournisseur d'identité, le cas échéant. Vous devrez peut-être définir cette option si, par exemple, votre cluster se trouve sur un réseau privé et doit se connecter à un fournisseur d'identité public. Exemple : `http://user:password@10.10.10.10:8888`.	Chaîne

Une fois la ClientConfig terminée, enregistrez le fichier. Cela va entraîner la mise à jour de la ressource ClientConfig sur votre cluster. Si vous avez commis des erreurs de syntaxe, vous êtes invité à modifier la configuration pour les corriger.

Configurations spécifiques aux fournisseurs

Cette section fournit des conseils de configuration pour certains des fournisseurs OIDC les plus couramment utilisés, y compris des exemples de configurations que vous pouvez copier et modifier avec vos propres détails.

Azure AD

Il s'agit de la configuration par défaut pour configurer GKE Identity Service avec Azure AD. Cette configuration permet à GKE Identity Service d'obtenir des informations sur les utilisateurs et les appartenances aux groupes à partir d'Azure AD, et vous permet de configurer le contrôle des accès basé sur les rôles Kubernetes (RBAC) en fonction des groupes. Toutefois, l'utilisation de cette configuration vous limite à la récupération d'environ 200 groupes par utilisateur.

Si vous devez récupérer plus de 200 groupes par utilisateur, consultez les instructions pour Azure AD (Configuration avancée).

...
spec:
  authentication:
  - name: oidc-azuread
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent, access_type=offline
      issuerURI: https://login.microsoftonline.com/TENANT_ID/v2.0
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: openid,email,offline_access
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Remplacez les éléments suivants :

CLIENT_ID : l'ID client renvoyé lors de l'enregistrement de GKE Identity Service auprès de votre fournisseur.
CLIENT_SECRET : le secret partagé entre l'application cliente OIDC et le fournisseur OIDC.
TENANT : le type de compte Azure AD à authentifier. Les valeurs acceptées sont l'ID de locataire ou le nom du locataire pour les comptes appartenant à un locataire spécifique. Le nom du locataire est également appelé domaine principal. Pour savoir comment trouver ces valeurs, consultez la section Rechercher l'ID de locataire Microsoft Azure AD et le nom de domaine principal.
PORT : le numéro de port choisi pour l'URL de redirection utilisée par gcloud CLI, spécifié par l'administrateur de votre plate-forme lors de l'enregistrement.

Azure AD (Configuration avancée)

Cette configuration facultative pour Azure AD permet à GKE Identity Service de récupérer des informations sur les utilisateurs et les groupes sans limitation du nombre de groupes par utilisateur, à l'aide de l'API Microsoft Graph.

Pour en savoir plus sur les plates-formes compatibles avec cette configuration, consultez la section Configuration avancée pour Azure AD.

Si vous devez récupérer moins de 200 groupes par utilisateur, nous vous recommandons d'utiliser la configuration par défaut à l'aide d'une ancre oidc dans votre ClientConfig. Pour en savoir plus, consultez les instructions pour Azure AD.

Tous les champs de l'exemple de configuration suivant sont requis.

...
spec:
  authentication:
  - name: NAME
    proxy: PROXY_URL
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_ID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Remplacez les éléments suivants :

NAME : nom que vous souhaitez utiliser pour identifier cette configuration, généralement le nom du fournisseur d'identité. Le nom d'une configuration doit commencer par une lettre suivie de 1 à 39 lettres minuscules, chiffres ou traits d'union, et ne peut pas se terminer par un trait d'union.
PROXY_URL : adresse du serveur proxy à utiliser pour se connecter au fournisseur d'identité, le cas échéant. Vous devrez peut-être définir cette option si, par exemple, votre cluster se trouve sur un réseau privé et doit se connecter à un fournisseur d'identité public. Exemple : http://user:password@10.10.10.10:8888.
CLIENT_ID : l'ID client renvoyé lors de l'enregistrement de GKE Identity Service auprès de votre fournisseur.
CLIENT_SECRET : le secret partagé entre l'application cliente OIDC et le fournisseur OIDC.
TENANT : le type de compte Azure AD à authentifier. Les valeurs acceptées sont l'ID de locataire ou le nom du locataire pour les comptes appartenant à un locataire spécifique. Le nom du locataire est également appelé domaine principal. Pour savoir comment trouver ces valeurs, consultez la section Rechercher l'ID de locataire Microsoft Azure AD et le nom de domaine principal.
PORT : le numéro de port choisi pour l'URL de redirection utilisée par gcloud CLI, spécifié par l'administrateur de votre plate-forme lors de l'enregistrement.
GROUP_FORMAT : format dans lequel vous souhaitez récupérer les informations de groupe. Ce champ peut prendre des valeurs correspondant aux valeurs ID ou NAME des groupes d'utilisateurs. Notez que ce paramètre n'est actuellement disponible que pour les clusters dans les déploiements Google Distributed Cloud sur Bare Metal.
USER_CLAIM (facultatif) : revendication de jeton JWT (nom de champ) que votre fournisseur utilise pour identifier un compte. Si vous ne spécifiez pas de valeur ici, GKE Identity Service utilise une valeur dans l'ordre "email", "preferred_username" ou "sub" pour récupérer les informations sur l'utilisateur. Cet attribut peut être utilisé à partir de la version 1.28 de GKE Enterprise.

Okta

Vous trouverez ci-dessous la procédure à suivre pour configurer l'authentification en utilisant à la fois les utilisateurs et les groupes avec Okta comme fournisseur d'identité. Cette configuration permet à Anthos Identity Service de récupérer les revendications des utilisateurs et des groupes à l'aide d'un jeton d'accès et du point de terminaison userinfo d'Okta.

...
spec:
  authentication:
  - name: okta
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      enableAccessToken: true
      extraParams: prompt=consent
      groupsClaim: groups
      issuerURI: https://OKTA_ISSUER_URI/
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: offline_access,email,profile,groups
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Limites d'accès relatives aux groupes

Pour les utilisateurs d'Okta, Anthos Identity Service peut récupérer des informations de groupes pour les utilisateurs dont les noms de groupe, s'ils sont concaténés, ne dépassent pas 170 000 caractères. Cela correspond à une adhésion d'environ 650 groupes en fonction de la longueur maximale de groupe d'Okta. Si l'utilisateur est membre d'un trop grand nombre de groupes, l'appel d'authentification échoue.

Étape suivante

Une fois la configuration appliquée, découvrez comment configurer l'accès des utilisateurs aux clusters.