Utiliser des fournisseurs d'identité externes pour s'authentifier auprès de GKE

Cette page vous explique comment configurer l'authentification sur les clusters Google Kubernetes Engine (GKE) à partir de fournisseurs d'identité (IdP) externes.

Cette page s'adresse aux administrateurs et opérateurs de plate-forme, ainsi qu'aux administrateurs d'identité et de compte qui utilisent un IdP externe compatible avec OpenID Connect (OIDC) ou SAML (Security Assertion Markup Language) 2.0.

Avant de lire cette page, assurez-vous de maîtriser les concepts d'authentification et OpenID suivants :

Méthodes d'authentification IdP externes dans GKE

Recommandé : fédération des identités des employés

La fédération d'identité de personnel est une fonctionnalité IAM qui vous permet de vous authentifier auprès de Google Cloud à partir de n'importe quel fournisseur d'identité externe compatible avec OIDC ou SAML 2.0. La fédération des identités des employés ne nécessite aucune installation dans le cluster, fonctionne avec les clusters Autopilot et les clusters Standard, et est intégrée à Google Cloud. Pour en savoir plus, consultez la documentation IAM sur la fédération des identités des employés.

Non recommandé : Identity Service pour GKE

Dans les clusters GKE Standard uniquement, GKE est également compatible avec Identity Service pour GKE. Identity Service pour GKE est limité aux IdP OIDC et installe des composants supplémentaires dans votre cluster. GKE recommande vivement d'utiliser la fédération d'identité des employés plutôt qu'Identity Service pour GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Remarques

Les systèmes headless ne sont pas compatibles avec la fédération d'identité des employés ni avec Identity Service pour GKE. Un processus d'authentification basé sur navigateur vous demande votre autorisation et vous invite à autoriser votre compte utilisateur.

Utiliser la fédération d'identité du personnel dans GKE

Pour utiliser la fédération d'identité du personnel dans vos clusters GKE, procédez comme suit :

  1. Configurez la fédération d'identité de personnel pour votre organisation et votre fournisseur d'identité externe. Pour obtenir des instructions, consultez Configurer la fédération d'identité de personnel.
  2. Configurez l'accès depuis votre fournisseur d'identité externe à la console de fédération d'identité des employés Google Cloud . Pour en savoir plus, consultez Configurer l'accès utilisateur à la console (fédération).

  3. Configurez l'accès des utilisateurs à l'aide de l'un des mécanismes d'autorisation suivants :

  4. Demandez à vos utilisateurs d'accéder aux clusters en procédant comme suit :

    1. Connectez-vous à la gcloud CLI avec l'identité fédérée.
    2. Configurez kubectl pour qu'il s'authentifie auprès d'un cluster spécifique en exécutant gcloud container clusters get-credentials.

Configurer l'accès des utilisateurs aux clusters à l'aide de RBAC

Google Cloud utilise des identifiants principaux pour identifier les utilisateurs dans vos pools d'identités de personnel. Vous pouvez faire référence à ces identifiants de compte principal dans vos stratégies RBAC Kubernetes ou dans les stratégies IAM. Vous pouvez accorder des autorisations à des utilisateurs individuels ou à des groupes d'utilisateurs, comme dans les exemples suivants :

Identité Identifiant principal
Utilisateur unique 
principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

Remplacez les éléments suivants :

  • WORKFORCE_IDENTITY_POOL : nom du pool d'identités de personnel.
  • SUBJECT_ATTRIBUTE_VALUE : valeur d'un attribut dans l'assertion du sujet du jeton d'identité. Par exemple, il peut s'agir de la valeur du champ NameID dans une assertion SAML 2.0.

Exemple :

principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com
Tous les utilisateurs d'un groupe 
principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME

Remplacez les éléments suivants :

  • WORKFORCE_IDENTITY_POOL : nom du pool d'identités de personnel.
  • GROUP_NAME : nom d'un groupe dont l'utilisateur authentifié est membre. L'assertion de votre jeton IdP doit comporter un mappage d'attributs vers l'attribut Google Cloud google.groups.

Exemple :

principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

Pour chaque identifiant de compte principal compatible avec la fédération d'identité du personnel, consultez Représenter les utilisateurs de pools de personnel dans les stratégies IAM.

L'exemple suivant montre comment accorder un accès en lecture seule à l'ensemble du cluster sur les secrets à toutes les entités du pool de personnel full-time-employees qui possèdent l'attribut access_level="sensitive" dans leur jeton IdP.

  1. Enregistrez le fichier manifeste ClusterRole suivant sous le nom secret-viewer-cluster-role.yaml :

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

    Tout compte principal auquel vous associez ce ClusterRole peut afficher les secrets.

  2. Enregistrez le fichier manifeste ClusterRoleBinding suivant sous le nom secret-viewer-cluster-role-binding.yaml :

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  users-view-secrets
subjects:
- kind: Group
  name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/attribute.access_level/sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

    Cet objet ClusterRoleBinding accorde le ClusterRole secret-viewer à tout utilisateur disposant de l'attribut access_level="sensitive".

  3. Déployez ClusterRole et ClusterRoleBinding :

    kubectl apply -f secret-viewer-cluster-role.yaml
kubectl apply -f secret-viewer-cluster-role-binding.yaml

Se connecter au cluster et s'authentifier auprès de celui-ci

  1. Demandez à l'utilisateur de se connecter à l'aide de la CLI Google Cloud CLI pour Google Cloud.

  2. L'utilisateur peut configurer kubectl pour s'authentifier auprès du cluster à l'aide des éléments suivants :

    gcloud container clusters get-credentials

Migrer des clusters Identity Service pour GKE vers la fédération d'identité des employés

Si vous utilisez Identity Service pour GKE dans des clusters GKE existants, migrez vers Workforce Identity Federation. Ces méthodes utilisent différentes syntaxes pour faire référence aux mêmes principaux, comme indiqué dans le tableau suivant :

Syntaxe d'Identity Service pour GKE Syntaxe de la fédération d'identité de personnel
amal@example.com principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com
sre-group principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre-group

Pour migrer un cluster afin qu'il utilise la fédération d'identité des employés, procédez comme suit :

  1. Configurez la fédération d'identité de personnel pour votre organisation et votre fournisseur d'identité externe. Pour obtenir des instructions, consultez Configurer la fédération d'identité de personnel.

  2. Mettez à jour les fichiers manifestes de tous les RoleBindings et ClusterRoleBindings de vos clusters pour utiliser la syntaxe des identifiants de la fédération des identités des employés. Utilisez l'une des options suivantes :

    • Mises à jour programmatiques : installez et exécutez l'utilitaire gke-identity-service-migrator. Pour obtenir des instructions, consultez le fichier README du dépôt GoogleCloudPlatform/gke-utilities.

      Cet utilitaire recherche les liaisons RBAC existantes qui utilisent la syntaxe Identity Service pour GKE et crée des fichiers manifestes qui utilisent les identifiants principaux de fédération d'identité des employés correspondants.

    • Mises à jour manuelles : pour chaque liaison qui fait référence à un utilisateur ou à un groupe authentifié, créez une copie distincte du fichier manifeste de l'objet qui utilise la syntaxe de l'identifiant de la fédération d'identité Workforce.

  3. Appliquez les fichiers manifestes mis à jour pour les RoleBindings et les ClusterRoleBindings à votre cluster.

  4. Vérifiez que les utilisateurs peuvent accéder aux mêmes ressources lorsqu'ils s'authentifient à l'aide de la fédération des identités des employés.

  5. Supprimez les liaisons RBAC obsolètes de votre cluster.

  6. Désactivez Identity Service pour GKE.

Utiliser Identity Service pour GKE

Pour configurer et utiliser Identity Service pour GKE sur votre cluster en mode Standard GKE, les administrateurs de cluster effectuent les opérations suivantes :

  1. Activez Identity Service pour GKE sur un cluster.
  2. Configurez Identity Service pour GKE.
  3. Créez une règle RBAC pour votre cluster.

Une fois que les administrateurs de cluster ont configuré Identity Service pour GKE, les développeurs peuvent se connecter et s'authentifier auprès du cluster.

Objets Kubernetes créés par Identity Service pour GKE

Le tableau suivant décrit les objets Kubernetes créés lorsque vous activez Identity Service pour GKE sur un cluster :

Objets Kubernetes
anthos-identity-service Namespace
Utilisé pour les déploiements Identity Service pour GKE.
kube-public Namespace
Utilisé pour le fichier de configuration client default.
gke-oidc-envoy LoadBalancer
Point de terminaison des requêtes OIDC. Externe par défaut. S'il est créé dans un cluster sans point de terminaison d'adresse IP externe, le point de terminaison est interne au cloud privé virtuel du cluster.
Créé dans l'espace de noms anthos-identity-service.
gke-oidc-service ClusterIP
Permet de communiquer entre le déploiement gke-oidc-envoy et le déploiement gke-oidc-service.
Créé dans l'espace de noms anthos-identity-service.
gke-oidc-envoy Deployment
Exécute un proxy exposé à la ressource LoadBalancer gke-oidc-envoy. Il communique avec gke-oidc-service pour valider les jetons d'identité. Sert de proxy pour le serveur d'API Kubernetes et emprunte l'identité des utilisateurs lors de la transmission de requêtes au serveur d'API.
Créé dans l'espace de noms anthos-identity-service.
gke-oidc-service Deployment
Valide les jetons d'identité et fournit un webhook d'admission de validation pour les ressources ClientConfig.
Créé dans l'espace de noms anthos-identity-service.
gke-oidc-operator Deployment
Rapproche la configuration du client et la ressource LoadBalancer gke-oidc-envoy.
Créé dans l'espace de noms anthos-identity-service.
gke-oidc-certs Secret
Contient l'autorité de certification de cluster et les certificats TLS pour l'équilibreur de charge.
Créé dans l'espace de noms anthos-identity-service
default ClientConfig CRD
Contient des paramètres OIDC tels que la méthode d'authentification préférée, la configuration du fournisseur d'identité et les mappages des revendications des utilisateurs et des groupes. Utilisé pour la validation des jetons d'identité. Permet aux administrateurs de cluster de configurer les paramètres OIDC avant de les distribuer aux développeurs.
Créé dans l'espace de noms kube-public

Activer Identity Service pour GKE sur un cluster

Par défaut, Identity and Access Management (IAM) est configuré en tant que fournisseur d'identité pour l'authentification sur les clusters. Si vous souhaitez utiliser OIDC avec des fournisseurs d'identité tiers, vous pouvez activer Identity Service pour GKE sur des clusters nouveaux ou existants à l'aide de Google Cloud CLI.

Activer Identity Service pour GKE sur un nouveau cluster

Pour créer un cluster avec Identity Service pour GKE activé, exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Remplacez CLUSTER_NAME par le nom de votre nouveau cluster.

Activer Identity Service pour GKE sur un cluster existant

Pour activer Identity Service pour GKE sur un cluster existant, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Remplacez CLUSTER_NAME par le nom de votre cluster.

Configurer Identity Service pour GKE

Vous pouvez configurer le paramètre Identity Service pour GKE en téléchargeant et en modifiant le fichier ClientConfig default.

  1. Téléchargez l'objet ClientConfig default :

    kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml

  2. Mettez à jour la section spec.authentication avec les paramètres de votre choix :

    apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  name: cluster-name
  server: https://192.168.0.1:6443
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_ID
      certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
      extraParams: EXTRA_PARAMS
      issuerURI:  ISSUER_URI
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      kubectlRedirectURI: KUBECTL_REDIRECT_URL
      scopes: SCOPES
      userClaim: USER
      groupsClaim: GROUPS
      userPrefix: USER_PREFIX
      groupPrefix: GROUP_PREFIX

    Remplacez les éléments suivants :

    • CLIENT_ID : ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OIDC.
    • OIDC_PROVIDER_CERTIFICATE : (facultatif) certificat PEM pour le fournisseur OIDC. Ce champ peut être utile si votre fournisseur OIDC utilise des certificats autosignés. Identity Service pour GKE inclut un ensemble de racines publiques par défaut.
    • EXTRA_PARAMS : paramètres de clé-valeur supplémentaires à envoyer au fournisseur OIDC.
      • Pour autoriser des groupes, utilisez resource=token-groups-claim.
      • Pour authentifier Microsoft Azure et Okta, utilisez prompt=consent.
      • Pour Cloud Identity, utilisez prompt=consent,access_type=offline.
    • ISSUER_URI : URL permettant d'envoyer des requêtes d'autorisation OIDC, telles que https://example.com/adfs. Le serveur d'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. L'URI doit utiliser le protocole HTTPS. Pour Cloud Identity, utilisez https://accounts.google.com.
    • KUBECTL_REDIRECT_URL : URL de redirection que kubectl oidc login utilise pour l'autorisation. Il s'agit généralement du format http://localhost:PORT/callback, où PORT est un port supérieur au port 1024 qui sera disponible sur les postes de travail des développeurs, par exemple http://localhost:10000/callback. Vous devez enregistrer l'URL auprès de votre fournisseur OIDC en tant qu'URL de redirection autorisée pour l'application cliente. Si vous utilisez Google Identity comme fournisseur OIDC, consultez la page Définir un URI de redirection pour obtenir des instructions.
    • SCOPES : Niveaux d'accès supplémentaires à envoyer au fournisseur OIDC.
      • Microsoft Azure et Okta nécessitent le niveau d'accès offline_access.
      • Pour Cloud Identity, utilisez openid, email pour obtenir les jetons d'ID contenant l'adresse e-mail dans la revendication email.
    • USER : revendication de l'utilisateur à partir du jeton d'identité.
    • GROUPS : revendication de groupe à partir du jeton d'identité.
    • USER_PREFIX : préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Par défaut, un préfixe d'émetteur est ajouté au champ userID donné au serveur d'API Kubernetes (sauf si la revendication utilisateur est email). L'identifiant utilisateur obtenu est ISSUER_URI#USER. Nous vous recommandons d'utiliser un préfixe, mais vous pouvez le désactiver en définissant USER_PREFIX sur -.
    • GROUP_PREFIX : préfixe ajouté aux revendications de groupe pour éviter les conflits avec les noms existants. Par exemple, si vous avez deux groupes nommés foobar, ajoutez un préfixe gid-. Le groupe ainsi obtenu est gid-foobar.

  3. Appliquez la configuration mise à jour :

    kubectl apply -f client-config.yaml

    Une fois cette configuration appliquée, Identity  ervice pour GKE s'exécute dans votre cluster et diffuse les requêtes derrière l'équilibreur de charge gke-oidc-envoy. L'adresse IP figurant dans le champ spec.server doit être l'adresse IP de l'équilibreur de charge. Si vous modifiez le champ spec.server, les commandes kubectl peuvent échouer.

  4. Créez une copie du fichier de configuration client-config.yaml :

    cp client-config.yaml login-config.yaml

  5. Mettez à jour le fichier de configuration login-config.yaml avec le paramètre clientSecret dans la section spec.authentication.oidc.

    clientSecret: CLIENT_SECRET

    Remplacez CLIENT_SECRET par la clé secrète partagée entre l'application cliente OIDC et le fournisseur OIDC.

  6. Distribuez le fichier login-config.yaml mis à jour à vos développeurs.

Configurer Identity Service pour GKE sur des clusters avec des stratégies strictes

Pour configurer Identity Service pour GKE afin qu'il fonctionne comme prévu sur des clusters ayant des règles de réseau strictes, procédez comme suit :

  1. Ajoutez une règle de pare-feu pour le port TCP 15000 afin de permettre à votre plan de contrôle de communiquer avec le webhook de validation ClientConfig.
  2. Si le fichier gke-oidc-envoy est créé en tant qu'équilibreur de charge interne, exposez-le sur votre VPC.
  3. Si vous avez des règles qui refusent le trafic au sein de votre cluster, ajoutez une règle de pare-feu pour le port TCP 8443 afin de permettre au déploiement gke-oidc-envoy de communiquer avec le déploiement gke-oidc-service.

Identity Service pour GKE version 0.2.20 et ultérieure n'utilise pas le port TCP 15000. Si la version de vos composants est 0.2.20 ou ultérieure, vous n'avez pas besoin d'ajouter de règle de pare-feu pour le port 15000. Pour vérifier la version de votre composant, exécutez la commande suivante :

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Ajouter des propriétés personnalisées à l'équilibreur de charge

Après avoir configuré Identity Service pour GKE, vous pouvez ajouter des annotations et des propriétés personnalisées, telles qu'une adresse IP statique, à l'équilibreur de charge gke-oidc-envoy. Pour modifier l'objet Service gke-oidc-envoy, exécutez la commande suivante :

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Consultez la page Paramètres du service LoadBalancer pour en savoir plus sur la configuration de l'équilibrage de charge TCP/UDP pour GKE.

Créer une règle RBAC pour votre cluster

Les administrateurs peuvent utiliser le contrôle des accès basé sur les rôles (RBAC) Kubernetes afin d'accorder l'accès aux utilisateurs authentifiés du cluster. Pour configurer des règles RBAC pour un cluster, vous devez attribuer des rôles RBAC à chaque développeur. Pour accorder l'accès aux ressources d'un espace de noms particulier, créez un Role et un RoleBinding. Pour accorder l'accès aux ressources de l'ensemble d'un cluster, créez un ClusterRole et un ClusterRoleBinding.

Prenons l'exemple d'un utilisateur qui a besoin d'afficher tous les objets Secret du cluster. Les étapes suivantes permettent d'attribuer les rôles RBAC requis à cet utilisateur.

  1. Enregistrez le fichier manifeste ClusterRole suivant sous le nom secret-viewer-cluster-role.yaml. Une personne disposant de ce rôle peut obtenir, surveiller et répertorier tous les objets Secret du cluster.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

  2. Appliquez le fichier manifeste ClusterRole :

    kubectl apply -f secret-viewer-cluster-role.yaml

  3. Enregistrez le fichier manifeste ClusterRoleBinding suivant sous le nom secret-viewer-cluster-role-binding.yaml. La liaison accorde le rôle secret-viewer à un nom d'utilisateur défini dans le fichier de configuration du client.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  people-who-view-secrets
subjects:
- kind: User
  name: ISSUER_URI#USER
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

    Remplacez les éléments suivants :

    • ISSUER_URI : URI de l'émetteur depuis spec.authentication.oidc.issuerURI dans le fichier de configuration du client.
    • USER : identifiant d'utilisateur dans le jeton situé sous le nom de revendication configuré dans spec.authentication.oidc.userClaim dans le fichier de configuration du client.

  4. Appliquez le fichier manifeste ClusterRoleBinding :

    kubectl apply -f secret-viewer-cluster-role-binding.yaml

Se connecter au cluster et s'authentifier auprès de celui-ci

En tant que développeur qui reçoit le fichier de configuration OIDC de votre administrateur, vous pouvez vous authentifier auprès de vos clusters.

  1. Téléchargez le fichier login-config.yaml fourni par votre administrateur.

  2. Installez le SDK Google Cloud CLI, qui propose un composant OIDC distinct. Vous pouvez l'installer en exécutant la commande suivante :

    gcloud components install kubectl-oidc

  3. Authentifiez-vous sur votre cluster :

    kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml

    Cette commande ouvre un navigateur Web vous permettant de terminer le processus d'authentification.

  4. Une fois authentifié, vous pouvez exécuter des commandes kubectl, par exemple :

    kubectl get pods

Désactiver Identity Service pour GKE

Vous pouvez désactiver Identity Service pour GKE à l'aide de gcloud CLI. Pour désactiver Identity Service pour GKE, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

Étapes suivantes