Configurer des clusters membres du parc pour l'authentification SAML

Ce document explique comment les administrateurs de cluster ou les opérateurs d'application peuvent configurer des clusters Kubernetes pour prendre en charge l'authentification à partir d'un fournisseur Security Assertion Markup Language (SAML) tiers. Pour en savoir plus, consultez À propos de l'authentification à l'aide d'identités tierces.

Limites

Vous devez utiliser un type de cluster compatible avec SAML.

Avant de commencer

  1. Install the Google Cloud CLI.

  2. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

  3. Pour initialiser la gcloud CLI, exécutez la commande suivante :

    gcloud init
  4. Après avoir initialisé la gcloud CLI, mettez-la à jour et installez les composants requis :

    gcloud components update
    gcloud components install kubectl
  5. Assurez-vous que l'administrateur de votre plate-forme vous a fourni toutes les informations nécessaires sur le fournisseur. Pour en savoir plus, consultez Partager les informations du fournisseur.

Configurer le cluster

Pour configurer un cluster pour l'authentification à l'aide de SAML, vous configurez une ressource personnalisée Kubernetes nommée ClientConfig avec des informations sur le fournisseur d'identité et les paramètres dont le fournisseur a besoin pour renvoyer des informations utilisateur.

Pour modifier le ClientConfig default, assurez-vous de pouvoir vous connecter à votre cluster kubectl, puis exécutez la commande suivante :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

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.saml comme indiqué dans l'exemple suivant. 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
    saml:
      attributeMapping:
        ATTRIBUTE_KEY_1: ATTRIBUTE_CEL_EXPRESSION_1
        ATTRIBUTE_KEY_2: ATTRIBUTE_CEL_EXPRESSION_2
      groupsAttribute: GROUPS_ATTRIBUTE
      groupPrefix: GROUP_PREFIX
      idpEntityID: ENTITY_ID
      idpSingleSignOnURI: SIGN_ON_URI
      idpCertificateDataList: IDP_CA_CERT
      userAttribute: USER_ATTRIBUTE
      userPrefix: USER_PREFIX
    certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
    preferredAuthentication: PREFERRED_AUTHENTICATION
    server: <>
# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Vous pouvez ajouter plusieurs configurations de fournisseurs d'identité OIDC, LDAP et SAML au même fichier ClientConfig. Le cluster tente de s'authentifier avec chaque configuration dans l'ordre dans lequel elles sont définies, et s'arrête après la première authentification réussie. L'exemple ClientConfig suivant définit plusieurs fournisseurs d'identité dans un ordre spécifique :

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

Champs SAML ClientConfig

Le tableau suivant décrit les champs de l'objet saml ClientConfig. Les champs que vous devez ajouter dépendent des jetons de votre fournisseur d'identité et de la façon dont l'administrateur de votre plate-forme a configuré le fournisseur.

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