Configurer la passerelle Connect avec des identités tierces

Ce guide s'adresse aux administrateurs de plate-forme qui doivent configurer la passerelle Connect dans un projet contenant des utilisateurs qui ne disposent pas d'identités Google et n'appartiennent pas à Google Workspace. Dans ce guide, ces identités sont appelées "identités tierces". Avant de lire ce guide, vous devez vous familiariser avec les concepts exposés dans la présentation de la passerelle Connect. Pour autoriser des comptes Google individuels, consultez Configurer la passerelle Connect. Pour obtenir de l'aide concernant Google Groupes, consultez Configurer la passerelle Connect avec Google Groupes

La configuration de ce guide permet aux utilisateurs de se connecter aux clusters de parc à l'aide de Google Cloud CLI, de la passerelle Connect et de la console Google Cloud.

Types de cluster compatibles

Vous pouvez configurer le contrôle des accès avec des identités tierces via la passerelle Connect pour les types de clusters enregistrés suivants:

• Clusters GKE
• Google Distributed Cloud (logiciel uniquement) sur VMware et bare metal à partir d'Anthos (GKE Enterprise) 1.13
• GKE sur AWS et GKE sur Azure à partir de Kubernetes 1.25.
• Clusters associés à partir d'Anthos (GKE Enterprise) 1.16 et versions ultérieures.

Si vous devez mettre à niveau des clusters sur site pour utiliser cette fonctionnalité, consultez Mettre à niveau des clusters GKE Enterprise pour VMWare et Mettre à niveau des clusters GKE Enterprise sur Bare Metal.

Si vous avez un cas d'utilisation pour des environnements de clusters GKE autres que ceux listés ci-dessus, veuillez contacter le service client Cloud ou l'équipe de passerelle Connect.

Fonctionnement

Comme décrit dans la présentation, il est possible que les utilisateurs utilisent des fournisseurs d'identité autres que Google Workspace ou Cloud Identity. Grâce à la fédération d'identité de personnel, les utilisateurs peuvent utiliser leurs fournisseurs d'identité tiers, tels qu'Okta ou Azure Active Directory, pour accéder à leurs clusters via la passerelle Connect. Contrairement aux comptes Google, les utilisateurs tiers sont représentés par un compte principal IAM (Identity and Access Management) qui suit le format suivant :

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

• WORKFORCE_POOL_ID est le nom du pool de travailleurs qui contient le fournisseur d'identité tiers concerné.

• SUBJECT_VALUE est le mappage de l'identité tierce avec un sujet Google.

Pour les groupes tiers, l'identité principale IAM suit le format suivant :

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

Le schéma suivant illustre un flux typique pour un utilisateur tiers qui s'authentifie et exécute des commandes sur un cluster sur lequel ce service est activé. Pour que ce flux aboutisse, une stratégie de contrôle des accès basé sur les rôles (RBAC) doit être appliquée au cluster pour l'utilisateur ou pour un groupe.

Pour les utilisateurs individuels, une stratégie RBAC qui utilise le nom principal IAM complet de l'utilisateur doit exister sur le cluster.

Si vous utilisez la fonctionnalité de groupe, une stratégie RBAC qui utilise le nom principal IAM complet doit exister sur le cluster pour un groupe qui :

1. Contient l'utilisateur [e-mail] comme membre.

2. Est inclus dans un mappage pour un fournisseur d'identité au sein d'un pool de personnel au sein de l'organisation Google Cloud d'Alice.

Remarque : GKE Identity Service doit être configuré pour que les fonctionnalités des groupes tiers fonctionnent sur les clusters de membres de parc en dehors de Google Cloud.

1. L'utilisateur [e-mail] se connecte à gcloud avec son identité tierce, à l'aide de la connexion basée sur un navigateur tiers. Pour utiliser le cluster à partir de la ligne de commande, l'utilisateur obtient la passerelle du cluster kubeconfig, comme décrit dans la section Utiliser la passerelle Connect.
2. L'utilisateur envoie une requête en exécutant une commande kubectl ou en ouvrant les pages Charges de travail ou Navigateur d'objets de Google Kubernetes Engine dans la console Google Cloud.
3. La requête est reçue par la passerelle Connect, qui gère l'authentification tierce à l'aide de la fédération d'identité des employés.
4. La passerelle Connect effectue une vérification des autorisations avec IAM.
5. Le service Connect transmet la requête à l'agent Connect exécuté sur le cluster. La requête est accompagnée des informations d'identification de l'utilisateur à utiliser pour l'authentification et les autorisations sur le cluster.
6. L'agent Connect transmet la requête au serveur d'API Kubernetes.
7. Le serveur d'API Kubernetes transfère la requête à GKE Identity Service, qui la valide.
8. GKE Identity Service renvoie les informations sur l'utilisateur et le groupe tiers au serveur d'API Kubernetes. Le serveur d'API Kubernetes peut ensuite utiliser ces informations pour autoriser la requête en fonction des stratégies RBAC configurées du cluster.

Avant de commencer

• Assurez-vous que les outils de ligne de commande suivants sont installés :

  • Dernière version de Google Cloud CLI, l'outil de ligne de commande pour interagir avec Google Cloud.
  • L'outil de ligne de commande Kubernetes, kubectl, pour interagir avec vos clusters.

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

• Ce guide suppose que votre projet comporte roles/owner. Si vous n'êtes pas propriétaire du projet, vous pouvez avoir besoin d'autorisations supplémentaires pour effectuer certaines des étapes de configuration.

• Pour les clusters en dehors de Google Cloud, le service GKE Identity doit appeler les API Google à partir de votre cluster pour terminer l'authentification. Vérifiez si votre règle de réseau nécessite que le trafic sortant passe par un proxy.

Configurer des mappages d'attributs d'identité tiers à l'aide de Workforce Identity

Assurez-vous qu'un pool d'employés et un fournisseur d'identité sont configurés pour votre organisation Google Cloud en suivant les instructions correspondant à votre fournisseur d'identité :

• Azure AD
• Okta
• Autres produits OIDC ou SAML 2.0

Remarques : Il existe une limite du mappage d'attributs de 4 kilo-octets, qui inclut des groupes, pour chaque fournisseur d'identité.

Activer les API

Pour ajouter la passerelle à votre projet, activez l'API Connect Gateway et les API de dépendance requises. Si vos utilisateurs souhaitent uniquement s'authentifier auprès de clusters à l'aide de la console Google Cloud, vous n'avez pas besoin d'activer connectgateway.googleapis.com, mais vous devez activer les API restantes.

gcloud services enable --project=PROJECT_ID  \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

Remarque : Si vous n'êtes pas propriétaire du projet, vous devez disposer de l'autorisation serviceusage.services.enable avant de pouvoir activer les API pour votre projet.

Configurer GKE Identity Service

La fonctionnalité de prise en charge des identités tierces de la passerelle Connect utilise GKE Identity Service pour obtenir de Google des informations d'appartenance à des groupes. Pour en savoir plus sur GKE Identity Service, consultez Présentation de GKE Identity Service.

Si vous utilisez des clusters GKE avec la passerelle, vous n'avez pas besoin de configurer GKE Identity Service pour utiliser la prise en charge d'identités tierces. Suivez plutôt les instructions de la section Configurer Google Groupes pour RBAC, puis passez à la section Accorder des rôles IAM pour accorder l'accès aux clusters via la passerelle.

Si vous utilisez des clusters GKE associés avec la passerelle, GKE Identity Service n'est pas nécessaire pour la prise en charge des identités tierces. Suivez les instructions correspondant au type de cluster choisi pour configurer la prise en charge des identités tierces :

• Se connecter à votre cluster associé à EKS
• Se connecter à votre cluster associé à AKS
• Se connecter à d'autres types de clusters

Vérifier que GKE Identity Service est installé

GKE Identity Service est installé par défaut sur les clusters GKE à partir de la version 1.7 (bien que la compatibilité avec les identités tierces nécessite la version 1.13 ou ultérieure). Vous pouvez vérifier qu'il est correctement installé sur votre cluster en exécutant la commande suivante :

kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service

Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster.

Configurer la prise en charge des identités tierces pour les groupes

Si votre cluster ou votre parc est déjà configuré pour la compatibilité avec Google Groupes, vous n'avez pas besoin de suivre d'autres étapes. Vous pouvez passer à la section Attribuer des rôles IAM à des utilisateurs et groupes tiers.

Si vous utilisez Google Distributed Cloud sur VMware ou sur un serveur Bare Metal, la façon dont vous configurez GKE Identity Service détermine la façon dont vous devez configurer la fonctionnalité de groupes tiers.

Si vous utilisez GKE Identity Service pour la première fois, vous pouvez choisir de configurer la prise en charge des groupes tiers à l'aide des API Fleet (recommandé) ou de kubectl.

Si vous n'êtes pas un nouvel utilisateur de GKE Identity Service, gardez à l'esprit les points suivants :

• Si vous avez déjà configuré GKE Identity Service pour un autre fournisseur d'identité au niveau de votre parc, la fonctionnalité de groupes tiers est activée par défaut. Pour en savoir plus et obtenir des informations sur toute configuration supplémentaire requise, consultez la section Parc ci-dessous.

• Si vous avez déjà configuré GKE Identity Service pour un autre fournisseur d'identité dans une configuration par cluster, consultez la section Kubectl ci-dessous pour savoir comment mettre à jour votre configuration pour la fonctionnalité de groupes tiers.

Parc

Vous pouvez utiliser la console Google Cloud ou la ligne de commande pour configurer l'accès aux groupes tiers à l'aide des API Fleet Feature.

Console

Si vous n'avez pas encore configuré GKE Identity Service pour un parc, suivez les instructions de la page Configurer des clusters pour GKE Identity Service.

Sélectionner des clusters et mettre à jour la configuration

1. Dans la console Google Cloud, accédez à la page Gestionnaire de fonctionnalités.

   Accéder au gestionnaire de fonctionnalités

2. Cliquez sur Détails dans le panneau Identity Service. Les détails du cluster de votre projet s'affichent.

3. Cliquez sur Mettre à jour le service de gestion des identités pour ouvrir le volet de configuration.

4. Sélectionnez les clusters que vous souhaitez configurer. Vous pouvez choisir des clusters individuels ou spécifier que tous les clusters doivent être configurés avec la même configuration d'identité.

5. Dans la section Configurer les fournisseurs d'identité, vous pouvez choisir de conserver, d'ajouter, de mettre à jour ou de supprimer un fournisseur d'identité.

6. Cliquez sur Continuer pour passer à l'étape de configuration suivante. Si vous avez sélectionné au moins un cluster éligible pour cette configuration, la section Authentification Google s'affiche.

7. Sélectionnez Activer pour activer l'authentification Google pour les clusters sélectionnés. Si vous devez accéder au fournisseur d'identité Google via un proxy, saisissez les informations de proxy.

8. Cliquez sur Mettre à jour la configuration. La configuration d'identité est alors appliquée aux clusters sélectionnés.

gcloud

Si vous n'avez pas encore configuré GKE Identity Service pour un parc, suivez les instructions de la page Configurer des clusters pour GKE Identity Service. Spécifiez uniquement la configuration suivante dans votre fichier auth-config.yaml :

spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

Configurer l'accès aux groupes tiers à l'aide d'un proxy

Si vous devez accéder au fournisseur d'identité Google via un proxy, utilisez un champ proxy dans votre fichier auth-config.yaml. 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. Vous devez ajouter cette configuration même si vous avez déjà configuré GKE Identity Service pour un autre fournisseur.

Pour configurer le proxy, voici comment mettre à jour la section authentication du fichier de configuration auth-config.yaml existant.

  spec:
    authentication:
    - name: authentication-method
      google:
        disable: false
      proxy: PROXY_URL

Où :

• disable (facultatif) indique si vous souhaitez activer ou désactiver la fonctionnalité de groupes tiers pour les clusters. Cette valeur est définie par défaut sur false. Si vous souhaitez désactiver cette fonctionnalité, vous pouvez définir cette valeur sur true.

• PROXY_URL (facultatif) est l'adresse du serveur proxy permettant de se connecter au fournisseur d'identité Google. Par exemple : http://user:password@10.10.10.10:8888

Appliquer la configuration

Pour appliquer la configuration à un cluster, exécutez la commande suivante :

gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

Où :

CLUSTER_NAME est le nom d'appartenance unique de votre cluster au sein du parc.

Une fois appliquée, cette configuration est gérée par le contrôleur GKE Identity Service. Toutes les modifications locales apportées à la configuration du client GKE Identity Service seront appliquées par le contrôleur à la configuration spécifiée.

Kubectl

Pour configurer votre cluster afin qu'il utilise GKE Identity Service avec la fonctionnalité de groupes tiers, vous devez mettre à jour l'élément ClientConfig GKE Identity Service du cluster. Il s'agit d'un type de ressource personnalisée (CRD) de Kubernetes utilisé pour la configuration du cluster. Chaque cluster GKE Enterprise 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.

Pour modifier la configuration, utilisez la commande suivante.

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

S'il existe plusieurs contextes dans le fichier kubeconfig, le contexte actuel est utilisé. Vous devrez peut-être réinitialiser le contexte actuel sur le cluster approprié avant d'exécuter la commande.

Voici un exemple montrant comment mettre à jour ClientConfig avec une nouvelle méthode d'authentification ayant une configuration de type google afin d'activer la fonctionnalité de groupes tiers. Si le champ internalServer est vide, assurez-vous qu'il est défini sur https://kubernetes.default.svc, comme indiqué ci-dessous.

spec:
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL
  internalServer: https://kubernetes.default.svc

Où :

CLUSTER_IDENTIFIER (obligatoire) désigne les détails d'appartenance de votre cluster. Vous pouvez récupérer les informations d'appartenance de votre cluster à l'aide de la commande suivante :

kubectl --kubeconfig CLUSTER_KUBECONFIG get memberships membership -o yaml

Où :

CLUSTER_KUBECONFIG représente le chemin d'accès au fichier kubeconfig pour le cluster. Dans la réponse, reportez-vous au champ spec.owner.id pour récupérer les informations d'appartenance du cluster.

Voici un exemple de réponse affichant les détails d'appartenance d'un cluster :

id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

qui correspond au format suivant : //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP

Accorder des rôles IAM à des utilisateurs et des groupes tiers

Les identités tierces ont besoin des rôles Google Cloud supplémentaires suivants pour interagir avec les clusters connectés via la passerelle :

• roles/gkehub.gatewayAdmin. Ce rôle permet aux utilisateurs d'accéder à l'API de passerelle Connect.
  • Si les utilisateurs n'ont besoin que d'un accès en lecture seule aux clusters connectés, roles/gkehub.gatewayReader peut être utilisé à la place.
  • Si les utilisateurs ont besoin d'un accès en lecture/écriture aux clusters connectés, roles/gkehub.gatewayEditor peut être utilisé à la place.
• roles/gkehub.viewer. Ce rôle permet aux utilisateurs d'afficher les appartenances aux clusters enregistrées.

Voici comment ajouter les rôles nécessaires à des identités individuelles et à des groupes mappés :

Identités uniques

Pour attribuer les rôles nécessaires à une même identité pour le projet PROJECT_ID, exécutez la commande suivante :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

Où :

• PROJECT_ID est l'ID du projet.
• GATEWAY_ROLE correspond aux roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou gkehub.gatewayEditor.
• WORKFORCE_POOL_ID : est l'ID du pool d'identités des employés.
• SUBJECT_VALUE : est l'identité de l'utilisateur.

Groupes

Pour attribuer les rôles nécessaires à toutes les identités d'un groupe spécifique pour le projet PROJECT_ID, exécutez la commande suivante :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

Où :

• PROJECT_ID est l'ID du projet.
• GATEWAY_ROLE correspond aux roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou gkehub.gatewayEditor.
• WORKFORCE_POOL_ID : est l'ID du pool d'employés.
• GROUP_ID : groupe de la revendication google.groups mappée

Pour en savoir plus sur les personnalisations, comme la spécification d'attributs de service, lorsque vous appliquez la règle RBAC, reportez-vous à la configuration de votre fournisseur d'identité listée dans Configurer des mappages tiers à l'aide de Workforce Identity.

Pour en savoir plus sur l'attribution d'autorisations et de rôles IAM, consultez la page Accorder, modifier et révoquer les accès à des ressources.

Configurer des stratégies de contrôle des accès basé sur les rôles (RBAC)

Enfin, le serveur d'API Kubernetes de chaque cluster doit pouvoir autoriser les commandes kubectl arrivant de la passerelle en provenance des utilisateurs et groupes tiers spécifiés. Pour chaque cluster, vous devez ajouter une règle d'autorisation RBAC spécifiant les autorisations de l'objet sur le cluster.

Remarque : Le chemin d'accès à la ressource d'un utilisateur tiers n'inclut pas le nom du fournisseur d'identité. Pour éviter les autorisations inattendues, assurez-vous de ne pas utiliser les mêmes noms d'utilisateur ou de groupe dans différents fournisseurs d'identité pour un même pool d'employés.

Les sujets des règles RBAC doivent utiliser le même format que les liaisons IAM, avec des utilisateurs tiers commençant par principal://iam.googleapis.com/ et des groupes tiers commençant par principalSet://iam.googleapis.com/. Si GKE Identity Service n'est pas configuré pour le cluster, vous aurez besoin de stratégies d'emprunt d'identité en plus des rôles/rôles de cluster pour un utilisateur tiers. Dans ce cas, suivez ces étapes de configuration RBAC et ajoutez le compte principal tiers commençant par principal://iam.googleapis.com/ en tant qu'utilisateur.

L'exemple suivant montre comment accorder aux membres d'un groupe tiers des autorisations cluster-admin sur un cluster où le service d'identité GKE est configuré. Vous pouvez ensuite enregistrer le fichier de stratégie sous le nom /tmp/admin-permission.yaml et l'appliquer au cluster associé au contexte actuel.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

Pour en savoir plus sur la spécification des autorisations RBAC, consultez la section Utiliser l'autorisation RBAC.

Remarque : Bien que nos exemples montrent comment appliquer les mises à jour des règles directement avec kubectl, pour une utilisation réelle, nous vous recommandons vivement d'utiliser Policy Controller pour créer et gérer des stratégies avec Config Sync pour synchroniser ces règles et autres configurations entre vos clusters

.

Étape suivante

• Découvrez comment utiliser la passerelle Connect pour vous connecter aux clusters depuis la ligne de commande.
• Découvrez un exemple d'utilisation de la passerelle Connect pendant votre automatisation DevOps dans notre tutoriel Intégration avec Cloud Build.