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 suivants :

  • GKE sur Google Cloud : toutes les versions disponibles. Pour configurer la passerelle Connect, configurez Google Groupes pour RBAC, puis attribuez des rôles IAM à Google Groupes.
  • Google Distributed Cloud (logiciel uniquement) sur VMware et Bare Metal : toutes les versions disponibles.
  • Google Distributed Cloud connecté : toutes les versions disponibles.
  • Clusters associés à GKE : version 1.28.0-gke.2 et versions ultérieures.

  • GKE sur AWS et GKE sur Azure : toutes les versions disponibles.

Pour utiliser cette fonctionnalité avec des environnements qui ne figurent pas dans la liste précédente, contactez l'assistance Cloud Customer Care ou l'équipe de la 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 des identités des employés, 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 alice@example.com 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.

Schéma illustrant le flux d'identité tierce de la passerelle

  1. L'utilisateur alice@example.com se connecte à gcloud CLI 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 au composant service d'identité du cluster, qui la valide.
  8. Le composant de service d'identité 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

  1. Connectez-vous à votre compte Google Cloud . 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 Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. 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 Service Usage (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. 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 avez des règles de réseau qui exigent 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 des mappages d'attributs d'identité tiers à l'aide de la fédération des identités des employés

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é :

Configurer la prise en charge des groupes

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

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.

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 surGoogle 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 compatibilité avec les groupes pour des clusters individuels ou pour un parc. Le type de cluster que vous utilisez détermine la façon dont vous configurez la compatibilité avec les groupes :

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

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 exige 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 console Google Cloud , 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 contenant 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 permet la prise en charge des groupes. Pour désactiver la prise en charge des groupes, définissez cette valeur sur 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 au sein du 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 d'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 Connected, activez la prise en charge des groupes en mettant à jour ClientConfig default dans chaque cluster :

  1. Obtenez les informations 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 de membre 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 fichier 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 sur l'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.

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 Connect Gateway.
    • 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.

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 l'authentification à partir d'identités tierces externes n'est pas configurée 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ù l'authentification à partir d'identités tierces externes est configurée. 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.

.

Étape suivante