Configurer des clusters pour GKE Identity Service avec SAML

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 Security Assertion Markup Language (SAML). Dans ce guide, nous partons du principe que vous avez lu la présentation de GKE Identity Service. 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.

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.
Assurez-vous que les outils de ligne de commande suivants sont installés :
- Utilisez la version 466.0.0 ou ultérieure 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.

Configurer le cluster

GKE Identity Service utilise un type de ressource personnalisée (CRD) Kubernetes spécial pour configurer vos clusters appelés , avec des champs pour les informations sur le fournisseur d'identité et les paramètres nécessaires pour renvoyer des informations utilisateur.

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 saml comme indiqué dans l'extrait.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
   saml:
     idpEntityID: ENTITY_ID
     idpSingleSignOnURI: SIGN_ON_URI
     idpCertificateDataList: IDP_CA_CERT
     userAttribute: USER_ATTRIBUTE
     groupsAttribute: {'<var name="user attribute">GROUPS_ATTRIBUTE</var>'}}
     userPrefix: USER_PREFIX
     groupPrefix: GROUP_PREFIX
     attributeMapping:
       ATTRIBUTE_KEY_1 : ATTRIBUTE_CEL_EXPRESSION_1
       ATTRIBUTE_KEY_2 : ATTRIBUTE_CEL_EXPRESSION_2
  certificateAuthorityData: CERTIFICATE_STRING
  preferredAuthentication: PREFERRED_AUTHENTICATION
  server: <>

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

Le tableau suivant décrit les champs de l'objet saml ClientConfig. 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	Requis	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
idpEntityID	Oui	ID d'entité SAML du fournisseur SAML, spécifié au format URI. Exemple : `https://www.idp.com/saml`.	Chaîne d'URL
idpSingleSignOnURI	oui	Point de terminaison SSO du fournisseur SAML, spécifié au format URI. Exemple : `https://www.idp.com/saml/sso`.	Chaîne d'URL
idpCertificateDataList	Oui	Correspond aux certificats du fournisseur d'identité utilisés pour valider la réponse SAML. Ces certificats doivent être encodés en base64 standard et au format PEM. Seuls deux certificats maximum sont acceptés pour faciliter la rotation des certificats du fournisseur d'identité.	Chaîne
userAttribute	Non	Nom de l'attribut de la réponse SAML qui contient le nom d'utilisateur.	Chaîne
groupsAttribute	Non	Nom de l'attribut de la réponse SAML qui contient les informations sur le groupe de l'utilisateur.	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
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
attributeMapping	Non	Mappage d'attributs utilisateur supplémentaires.	Chaîne
certificateAuthorityData	Non	Si elle est fournie par l'administrateur de votre plate-forme, il s'agit d'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
preferredAuthentication	Non	Nom de la méthode d'authentification préférée configurée dans le cluster.	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.

Étape suivante

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