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 cette page, assurez-vous que vous maîtrisez 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 la Google Cloud CLI, de la passerelle Connect et de la Google Cloud console.

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

Types de cluster compatibles

Vous pouvez configurer le contrôle des accès avec Google Groupes via la passerelle Connect pour les types de clusters suivants :

Pour utiliser cette fonctionnalité avec des environnements qui ne figurent pas dans la liste précédente, contactez Cloud Customer Care ou l'équipe de la passerelle Connect.

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. 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 dans vos stratégies de contrôle des accès.

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 aboutisse, une stratégie RBAC doit exister sur le cluster pour un groupe qui :

  1. Contient l'utilisateur alice@example.com comme membre.

  2. Est un groupe imbriqué de gke-security-groups@example.com.

Schéma illustrant le flux Google Groupes de la passerelle

  1. L'utilisateur alice@example.com se connecte à l'aide de son identité Google et, si il prévoit d'utiliser le cluster à partir de la ligne de commande, obtient la passerelle du cluster kubeconfig comme décrit dans Utiliser la passerelle Connect.
  2. L'utilisateur envoie une requête en exécutant une kubectl commande ou en ouvrant les pages Charges de travail ou Navigateur d'objets de Google Kubernetes Engine dans la Google Cloud console.
  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 au pod anthos-identity-service du cluster, qui la valide.
  7. Le pod anthos-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

  1. Connectez-vous à votre Google Cloud compte. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

  2. Installez la Google Cloud CLI.

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

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

    gcloud init

  5. Vérifiez que vous disposez des autorisations requises pour suivre les instructions de ce guide.

  6. Activez les API Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service et Cloud Resource Manager :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur de Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l' serviceusage.services.enable autorisation. Découvrez comment attribuer des rôles. 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

  7. Installez la Google Cloud CLI.

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

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

    gcloud init

  10. Vérifiez que vous disposez des autorisations requises pour suivre les instructions de ce guide.

  11. Activez les API Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service et Cloud Resource Manager :

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur de Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l' serviceusage.services.enable autorisation. Découvrez comment attribuer des rôles. 

    gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com
    12.
  12. Pour les clusters en dehors de Google Cloud, les composants d'authentification de votre cluster doivent appeler l'API Cloud Identity. Vérifiez si vous disposez de règles de réseau qui nécessitent que le trafic sortant de votre cluster passe par un proxy.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer la passerelle Connect et vos clusters, demandez à votre administrateur de vous accorder le rôle IAM Éditeur (roles/editor) sur le projet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

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 qu'un groupe au format gke-security-groups@YOUR-DOMAIN existe dans l'espace Google Workspace de votre organisation. Si vous n'avez pas de groupe de ce type, suivez les instructions de la section Créer un groupe dans votre organisation pour le créer à l'aide de la console d'administration Google.
  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 de leur groupe.

Configurer la prise en charge des groupes

La passerelle Connect utilise des composants d'authentification dans votre cluster pour récupérer les informations sur l'appartenance à un groupe. Pour activer les composants requis, consultez l'un des documents suivants en fonction de votre type de cluster :

Les sections suivantes vous expliquent comment mettre à jour la ressource personnalisée ClientConfig pour activer la prise en charge des groupes. Ces sections ne s'appliquent qu'aux clusters Google Distributed Cloud. Pour les autres types de clusters, tels que GKE sur Google Cloud; GKE sur AWS ; et GKE sur Azure, passez à la section Attribuer des rôles IAM à des groupes.

Pour Distributed Cloud, vous pouvez configurer la prise en charge des groupes pour des clusters individuels ou pour un parc. Le type de cluster que vous utilisez détermine la manière dont vous configurez la prise en charge des groupes, comme suit :

  • Distributed Cloud connecté : clusters individuels uniquement. La configuration au niveau du parc n'est pas prise en charge.
  • Google Distributed Cloud (logiciel uniquement) sur VMware et Bare Metal : clusters individuels ou parcs.

Configurer la prise en charge des groupes à l'aide de l'API GKE Fleet

Pour Google Distributed Cloud (logiciel uniquement) sur VMware et Bare Metal, vous pouvez configurer la prise en charge des groupes au niveau du parc. Si vous avez déjà configuré l'authentification au niveau du parc, par exemple pour un autre fournisseur d'identité, l'authentification de groupe est déjà activée. Toutefois, si votre règle de réseau nécessite que le trafic sortant passe par un proxy, vous devez mettre à jour la configuration existante avec des informations sur ce proxy.

Pour configurer la prise en charge des groupes au niveau du parc, sélectionnez l'une des options suivantes :

Console

  1. Dans la Google Cloud console, accédez à la page GKE Identity Service.

    Accéder à GKE Identity Service

  2. Cliquez sur Activer Identity Service.

  3. Sélectionnez les clusters Google Distributed Cloud (logiciel uniquement) sur VMware et Bare Metal que vous souhaitez configurer.

  4. Cliquez sur Mettre à jour la configuration. Le volet Modifier la configuration des clusters Identity Service s'ouvre.

  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

  1. Activez la fonctionnalité de service d'identité au niveau du parc et configurez les clusters, comme décrit dans Configurer la gestion de l'authentification au niveau du parc.

  2. Dans le fichier auth-config.yaml qui contient votre spécification ClientConfig, ajoutez le champ suivant :

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

    La valeur false dans le champ google.disable active la prise en charge des groupes. Pour désactiver la prise en charge des groupes, remplacez cette valeur par true.

  3. Facultatif : Si vous devez accéder au fournisseur d'identité Google via un proxy, ajoutez le champ proxy à la configuration précédente :

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

    Remplacez PROXY_URL par l'adresse du serveur proxy pour vous connecter à l'identité Google. Exemple : http://user:password@10.10.10.10:8888

  4. Appliquez la configuration à un cluster de votre parc :

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

    Remplacez CLUSTER_NAME par le nom d'appartenance unique de votre cluster dans le parc.

Une fois que vous avez configuré la prise en charge des groupes au niveau du parc, le contrôleur de parc gère la configuration. La configuration au niveau du parc remplace toutes les modifications locales que vous apportez à la configuration dans un cluster spécifique.

Configurer la prise en charge des groupes pour des clusters individuels

Pour tous les clusters Distributed Cloud, y compris Distributed Cloud connecté, activez la prise en charge des groupes en mettant à jour le ClientConfig default dans chaque cluster :

  1. Obtenez les détails d'appartenance de votre cluster :

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

    Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du 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.

    Dans la réponse, reportez-vous au champ spec.owner.id pour récupérer les informations d'appartenance du cluster. L'identifiant d'appartenance est au format //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.

    Le résultat ressemble à ce qui suit :

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

  2. Ouvrez le ClientConfig default dans votre cluster pour le modifier :

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

  3. Pour activer la prise en charge des groupes, ajoutez le champ google au champ spec.authentication :

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

    Remplacez CLUSTER_IDENTIFIER par les informations d'appartenance de votre cluster.

    Assurez-vous que le champ internalServer a la valeur https://kubernetes.default.svc.

  4. Facultatif : Si vous devez accéder au fournisseur d'identité Google via un proxy, ajoutez le champ proxy à la configuration précédente :

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

    Remplacez PROXY_URL par l'adresse du serveur proxy pour vous connecter à l'identité Google. Exemple : http://user:password@10.10.10.10:8888

Attribuer des rôles IAM à Google Groupes

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

  • 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: cluster-admin-team@example.com
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.

.

Étape suivante