Configurer la passerelle Connect avec Google Groupes

Ce guide s'adresse aux administrateurs de plate-forme qui doivent configurer la passerelle Connect afin qu'elle puisse être utilisée par les comptes utilisateur de leur projet, en exploitant Google Groupes pour l'autorisation. Avant de lire ce guide, vous devez vous familiariser avec les concepts de notre présentation. Pour autoriser des comptes individuels, consultez la configuration par défaut.

Cette configuration permet aux utilisateurs de se connecter aux clusters de parc configurés à l'aide de Google Cloud CLI, de la passerelle Connect et de la console Google Cloud.

Cette fonctionnalité utilise les groupes Google associés à Google Workspace ou à n'importe quelle édition de Cloud Identity.

Types de cluster compatibles

Si vous utilisez des clusters GKE avec la passerelle Connect, vous n'avez pas besoin de suivre l'intégralité de cette configuration avec GKE Identity Service pour utiliser Google Groupes pour l'autorisation. Suivez plutôt les instructions de la page Configurer Google Groupes pour RBAC, qui permet également aux utilisateurs de se connecter aux clusters GKE à partir de la console Google Cloud en utilisant Google Groupes pour le contrôle des accès. Une fois que vous avez terminé, suivez les instructions ci-dessous dans Attribuer des rôles IAM à Google Groupes pour permettre aux membres du groupe d'accéder aux clusters via la passerelle Connect.

Vous pouvez configurer le contrôle des accès avec Google Groupes via la passerelle Connect pour les clusters GKE enregistrés, GKE sur VMware et Google Distributed Cloud Virtual pour Bare Metal à partir de GKE Enterprise 1.13 et versions ultérieures, et pour GKE sur AWS et GKE sur Azure à partir de Kubernetes 1.25 et versions ultérieures. Si vous devez mettre à niveau des clusters sur site pour utiliser cette fonctionnalité, consultez les pages Mettre à niveau des clusters GKE Enterprise pour VMWare et Mettre à niveau des clusters GKE Enterprise sur Bare Metal.

Pour utiliser cette fonctionnalité avec des clusters ou des environnements de clusters GKE associés autres que ceux répertoriés ci-dessus, veuillez contacter le Cloud Customer Care ou l'équipe Connect Passerelle.

Fonctionnement

Comme décrit dans la présentation, il est souvent utile de pouvoir autoriser les utilisateurs à accéder aux clusters en fonction de leur appartenance à des groupes Google, c'est-à-dire des groupes créés dans Google Workspace. Accorder des autorisations en fonction de l'appartenance à un groupe vous évite d'avoir à configurer une autorisation distincte pour chaque compte, ce qui simplifie la gestion et facilite l'audit des règles. Ainsi, vous pouvez facilement partager l'accès au cluster à une équipe, sans avoir à ajouter/supprimer manuellement des utilisateurs des clusters lorsqu'ils rejoignent ou quittent l'équipe. Avec une configuration supplémentaire utilisant GKE Identity Service, vous pouvez configurer la passerelle Connect de manière à obtenir des informations sur l'appartenance à un groupe Google concernant chaque utilisateur qui se connecte au cluster. Vous pouvez ensuite utiliser ces informations de groupes dans vos stratégies de contrôle d'accès.

Remarque : Les comptes de service (comptes se terminant par gserviceaccount.com) ne sont pas compatibles avec la fonctionnalité Google Groupes.

Voici un exemple de flux classique pour un utilisateur qui s'authentifie et exécute des commandes sur un cluster avec ce service activé. Pour que ce flux réussisse, une stratégie RBAC doit exister sur le cluster pour un groupe qui:

1. Contient l'utilisateur [e-mail] en tant que membre.

2. Est un groupe imbriqué de [e-mail].

1. L'utilisateur [e-mail] se connecte à l'aide de son identité Google et, s'il prévoit d'utiliser le cluster à partir de la ligne de commande, obtient la passerelle kubeconfig du cluster 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 le service Connect, qui effectue une vérification des autorisations avec IAM.
4. 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.
5. L'agent Connect transmet la requête au serveur d'API Kubernetes.
6. Le serveur d'API Kubernetes transfère la requête à GKE Identity Service, qui la valide.
7. GKE Identity Service renvoie les informations sur l'utilisateur et sur le groupe 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 situés en dehors de Google Cloud, GKE Identity Service doit appeler l'API Google Identity à partir de votre cluster. Vérifiez si votre règle de réseau nécessite que le trafic sortant passe par un proxy.

Configurer les utilisateurs et les groupes

Assurez-vous que les groupes que vous souhaitez utiliser avec cette fonctionnalité sont configurés comme suit:

1. Assurez-vous que l'espace de travail Google Workspace de votre organisation contient un groupe au format gke-security-groups@YOUR-DOMAIN. Si vous n'avez pas de groupe de ce type, suivez les instructions de la section Créer un groupe dans votre organisation pour en créer à l'aide de la console d'administration Google Workspace.
2. Suivez les instructions de la section Ajouter un groupe à un autre groupe pour ajouter les groupes que vous souhaitez utiliser pour le contrôle des accès en tant que groupes imbriqués de gke-security-groups. N'ajoutez pas d'utilisateurs individuels en tant que membres de gke-security-groups.

Les comptes utilisateur que vous souhaitez utiliser avec cette fonctionnalité doivent utiliser le même nom de domaine que celui du groupe.

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.

PROJECT_ID=example_project
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é Google Groupes de la passerelle Connect utilise GKE Identity Service pour obtenir de Google les informations sur l'appartenance à un groupe. Pour en savoir plus sur GKE Identity Service, consultez la page 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 le contrôle des accès Google Groupes. Suivez plutôt les instructions de la page Configurer Google Groupes pour RBAC, puis passez à la section Attribuer des rôles IAM à Google Groupes pour permettre aux membres du groupe d'accéder aux clusters via la passerelle Connect.

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 fonctionnalité Google Groupes 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 USER_CLUSTER_KUBECONFIG get all -n anthos-identity-service

Où :

USER_CLUSTER_KUBECONFIG représente le chemin d'accès au fichier kubeconfig pour le cluster.

Configurer la compatibilité avec Google Groupes

Si vous utilisez GKE sur AWS ou GKE sur Azure, votre cluster est automatiquement configuré pour être compatible avec Google Groupes. Vous pouvez passer à l'étape Attribuer des rôles IAM à Google Groupes.

Si vous utilisez GKE sur Bare Metal ou GKE sur VMware, la façon dont vous configurez GKE Identity Service détermine la manière dont vous devez configurer la fonctionnalité Google Groupes.

Si vous utilisez GKE Identity Service pour la première fois, vous pouvez choisir de configurer Google Groupes au niveau du parc (recommandé) ou dans une configuration par cluster.

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é Google Groupes 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 Par cluster ci-dessous pour obtenir des instructions sur la mise à jour de la configuration pour la fonctionnalité Google Groupes.

Parc

Vous pouvez utiliser la console Google Cloud ou la ligne de commande pour configurer l'accès aux groupes Google au niveau du parc.

Si vous avez déjà configuré GKE Identity Service au niveau du parc pour un autre fournisseur d'identité (tel que Microsoft AD FS ou Okta), la fonctionnalité Google Groupes de la passerelle Connect est déjà activée pour vous par défaut sur les clusters configurés, à condition que le fournisseur d'identité Google soit accessible sans nécessiter l'utilisation d'un proxy.

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 Fonctionnalités de GKE Enterprise.

   Accéder à la page "Fonctionnalités" de GKE Enterprise

2. Dans la table Fonctionnalités, cliquez sur Détails à la ligne Service d'identité. 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 du proxy.

8. Cliquez sur Mettre à jour la configuration. Cette action applique la configuration de l'identité 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 à Google Groupes à travers 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: google-authentication-method
      google:
        disable: false
      proxy: PROXY_URL

Où :

• disable (facultatif) indique si vous souhaitez activer ou désactiver la fonctionnalité Google Groupes 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.

Par cluster

Pour configurer votre cluster afin qu'il utilise GKE Identity Service avec la fonctionnalité Google Groupes, 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 USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

où USER_CLUSTER_KUBECONFIG représente le chemin d'accès au fichier kubeconfig de votre cluster.

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é Google Groupes. 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 USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

Où :

USER_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

Attribuer des rôles IAM à Google Groupes

Les groupes 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 membres du groupe d'accéder à l'API de la passerelle Connect.
  • Si les membres du groupe 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 membres du groupe 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 membres du groupe d'afficher les appartenances aux clusters enregistrées.

Vous attribuez ces rôles à l'aide de la commande gcloud projects add-iam-policy-binding, comme suit :

gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=GATEWAY_ROLE PROJECT_ID
gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=roles/gkehub.viewer PROJECT_ID

Où :

• GROUP_NAME est le groupe Google auquel vous souhaitez accorder le rôle
• DOMAIN est votre domaine Google Workspace
• GROUP_NAME@DOMAIN est un groupe imbriqué sous gke-security-groups@DOMAIN
• GATEWAY_ROLE correspond aux roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader ou gkehub.gatewayEditor.
• PROJECT_ID est votre projet.

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 provenant de vos groupes spécifiés via la passerelle. Pour chaque cluster, vous devez ajouter une règle d'autorisation RBAC spécifiant les autorisations du groupe sur le cluster.

Dans l'exemple suivant, vous verrez comment accorder aux membres du groupe cluster-admin-team les autorisations cluster-admin sur le cluster, enregistrer le fichier de stratégie sous le nom /tmp/admin-permission.yaml et l'appliquer au cluster associé au contexte actuel. Veillez aussi à inclure le groupe cluster-admin-team sous le groupe gke-security-groups.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: [e-mail]
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.