Se connecter à des clusters enregistrés avec la passerelle Connect

Les parcs dans Google Cloud sont des groupes logiques de clusters Kubernetes et d'autres ressources qui peuvent être gérés ensemble, créés en enregistrant des clusters dans Google Cloud. La passerelle Connect exploite les performances des parcs pour permettre aux utilisateurs de GKE Enterprise de se connecter et d'exécuter des commandes sur des clusters membres du parc de manière simple, cohérente et sécurisée, qu'ils se trouvent sur Google Cloud, sur d'autres clouds publics, ou sur site, et facilite l'automatisation des processus DevOps dans l'ensemble de vos clusters.

Ce guide suppose que vous maîtrisez certains concepts de base des parcs et que vous enregistrez des clusters dans un parc. Pour en savoir plus, consultez la présentation de la gestion des parcs, la présentation de la création de parc et les guides associés. Vous devez également connaître les outils et concepts Kubernetes, y compris kubectl, client-go (si vous souhaitez utiliser la passerelle à des fins d'automatisation), le contrôle des accès basé sur les rôles (RBAC) et les ressources Kubernetes principales.

Par défaut, la passerelle Connect utilise votre ID Google pour s'authentifier auprès des clusters, avec prise en charge des fournisseurs d'identité tiers via la fédération des identités des employés et avec l'authentification basée sur les groupes via GKE Identity Service. Si vous souhaitez en savoir plus sur GKE Identity Service ou l'utiliser en tant qu'option d'authentification tierce autonome, consultez la page Présentation de GKE Identity Service.

Pourquoi utiliser la passerelle Connect ?

La gestion des charges de travail lorsque vos clusters s'exécutent dans plusieurs clouds et environnements hybrides présente de nombreux défis. Les clusters peuvent s'exécuter dans différents clouds privés virtuels (VPC) et exploiter différents fournisseurs d'identité, ce qui rend la connectivité, l'authentification et l'autorisation plus complexes. Parfois, il peut être difficile de déterminer quels clusters existent dans ces environnements.

La passerelle Connect permet de facilement :

  • Découvrir quels clusters existent (sur Google Cloud, sur un autre cloud public ou sur site) et sont enregistrés dans votre parc à l'aide d'une simple requête.
  • Vous connecter au cluster souhaité à l'aide de la même infrastructure que celle que nous utilisons pour afficher les clusters GKE enregistrés dans la console Google Cloud.
  • Vous authentifier avec les identités que vous utilisez avec les services Google Cloud.
  • Autoriser systématiquement l'ensemble de vos clusters enregistrés dans un parc.

La passerelle authentifie votre identité Google Cloud et fournit la connexion au serveur d'API du cluster via le service Connect.

Vous pouvez interagir directement avec les clusters via la passerelle à l'aide des outils de ligne de commande qui acceptent un fichier kubeconfig tel que kubectl. Vous pouvez également exploiter la passerelle avec vos pipelines de compilation et d'autres automatisations DevOps. Vous trouverez un exemple de procédure dans notre tutoriel Intégration avec Cloud Build.

Vous pouvez également utiliser le service Connect pour vous connecter à des clusters enregistrés en dehors de Google Cloud avec votre identité Google Cloud dans la console Google Cloud. Pour ce faire, suivez les instructions de la page Utiliser des clusters depuis la console Google Cloud.

Fonctionnement

Voici le flux qu'un utilisateur ou service type (par exemple, un pipeline CI/CD) exécute pour utiliser la passerelle Connect, une fois l'authentification et l'autorisation appropriées configurées. Pour obtenir des instructions plus détaillées, consultez notre guide d'utilisation.

  1. L'utilisateur ou le service découvre les clusters en répertoriant les ressources d'appartenance au parc à l'aide de la CLI Google Cloud.

    gcloud container fleet memberships list

  2. L'utilisateur ou le service récupère le fichier kubeconfig spécifique à la passerelle Connect nécessaire pour atteindre le cluster sélectionné à l'aide de la CLI Google Cloud.

    gcloud container fleet memberships get-credentials membership-name

    Si vous savez déjà comment utiliser la gcloud CLI avec GKE, cela fonctionne de la même manière que pour utiliser gcloud container clusters get-credentials à l'aide de votre compte Google Cloud, vous permettant d'accéder (si vous y êtes autorisé) à tout cluster enregistré et connecté dans votre parc de projets.

  3. L'utilisateur ou le service exécute les commandes comme il le ferait normalement avec kubectl ou client-go, à l'aide du fichier kubeconfig téléchargé.

    1. L'utilisateur/le service est authentifié par la passerelle Connect, et l'autorisation est vérifiée pour s'assurer qu'il est autorisé à utiliser la passerelle.
    2. La requête est transmise via le service Connect et l'agent Connect au serveur d'API Kubernetes correspondant.
    3. Le serveur d'API Kubernetes autorise la requête, ce qui nécessite que l'agent Connect soit autorisé à emprunter l'identité de l'utilisateur ou du service, et que l'utilisateur ou le service soit autorisé à exécuter la requête souhaitée.

Assistance Google Group

Dans le flux standard décrit dans la section précédente, la requête de l'utilisateur est autorisée en fonction de son ID individuel. Toutefois, dans de nombreux cas, il est utile de pouvoir autoriser des utilisateurs en fonction de leur appartenance à des groupes Google. 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 pour obtenir les informations d'appartenance à un groupe Google de l'utilisateur.

Pour en savoir plus sur le fonctionnement de cette fonctionnalité et sur sa configuration, consultez la section Configurer la passerelle Connect avec Google Groupes.

Si vous souhaitez utiliser cette fonctionnalité avec des clusters associés ou d'autres environnements de clusters GKE Enterprise, veuillez contacter le Cloud Customer Care ou l'équipe Connect Passerelle.

Prise en charge de l'identité tierce

En plus de fonctionner avec les utilisateurs et les groupes Google Workspace, la passerelle Connect accepte l'autorisation à l'aide d'identités tierces, telles qu'Azure Active Directory et Okta. Grâce à la fédération des identités des employés, vous pouvez utiliser un fournisseur d'identité externe pour authentifier et autoriser du personnel (un groupe d'utilisateurs tels que des employés, des partenaires et des sous-traitants) à l'aide de Identity and Access Management, afin que les utilisateurs puissent accéder aux services Google Cloud tels que la passerelle Connect. Avec une configuration supplémentaire utilisant GKE Identity Service, vous pouvez configurer la passerelle Connect pour obtenir des informations d'appartenance à des groupes tiers pour les utilisateurs.

La fonctionnalité d'identité tierce de la passerelle Connect est compatible avec les déploiements Google Distributed Cloud sur VMware et sur Bare Metal à partir d'Anthos (GKE Enterprise) 1.13. Pour les clusters associés, cette fonctionnalité est disponible dans Anthos 1.16 et versions ultérieures.

Pour en savoir plus sur le fonctionnement de cette fonctionnalité et sur sa configuration, consultez la section Configurer la passerelle Connect avec des identités tierces.

Si vous préférez, vous pouvez configurer entièrement l'authentification tierce à l'aide de GKE Identity Service en suivant les instructions de sa documentation.

Latence

La latence totale d'une requête via la passerelle peut être divisée en deux parties : le délai aller-retour (DAR) du service de passerelle Connect à l'agent Connect, et la durée d'exécution de la requête au sein du cluster. La latence supplémentaire générée par le DAR est de p95<500ms et de p99<1s. Notez que la plupart des commandes kubectl effectuent une série de plusieurs requêtes, chacune nécessitant un aller-retour, avant d'afficher une réponse à l'utilisateur.

Étape suivante