Lorsque vous enregistrez vos clusters Kubernetes avec Google Cloud à l'aide de Connect, une connexion authentifiée et chiffrée de longue durée est établie entre vos clusters et le plan de contrôle Google Cloud. La connexion affiche des informations sur les clusters dans la console Google Cloud. Elle vous permet de gérer et de déployer des configurations et des ressources sur les clusters à l'aide de composants et de fonctionnalités GKE Enterpris, tels que Config Management.
Cette page décrit la nature de la connexion entre Google Cloud et Connect, et fournit des informations sur les contrôleurs côté Google Cloud qui fonctionnent sur vos clusters via Connect.
À propos de la connexion entre Google Cloud et Connect
Comme décrit sur la page Fonctionnalités de sécurité, seul le plan de contrôle Google Cloud envoie des requêtes via Connect à chaque cluster connecté (par exemple, au serveur d'API d'un cluster), et le cluster renvoie des réponses au plan de contrôle. (Les services et les ressources de cluster ne peuvent pas initier des requêtes vers le plan de contrôle via Connect.) La connexion permet aux utilisateurs autorisés et à l'automatisation côté Google de joindre les clusters et de s'authentifier auprès de ces derniers.
Par exemple, Connect permet à Google Cloud Console d'obtenir des informations sur les charges de travail et les services ou permet à Config Management d'installer ou de mettre à jour l'agent Connect dans le cluster et de détecter l'état de synchronisation. Connect permet également à l'agent de mesure d'observer le nombre de processeurs virtuels dans un cluster connecté.
Connect ne fournit pas de transfert de données pour les images de conteneurs, l'équilibrage de charge, les connexions à la base de données, Logging ou Monitoring. Vous devez établir une connectivité pour ceux qui fonctionnent en parallèle via leurs propres mécanismes.
Accès des utilisateurs de Google Cloud Console aux clusters via Connect
Lorsque les utilisateurs de votre organisation se connectent à un cluster via Google Cloud Console, ils disposent d'autorisations de cluster spécifiques déterminées par les contrôles d'accès basés sur les rôles (RBAC) qui leur sont attribuée. Le cluster (et non Connect) applique les autorisations. Les journaux Kubernetes standards vous permettent de réaliser les audits des actions effectuées par chaque utilisateur concernant la gestion d'un cluster.
Le tableau suivant indique les sections de Google Cloud Console qui permettent aux utilisateurs d'interagir avec les clusters via Connect.
| Section de Google Cloud Console | Actions possibles |
|---|---|
| GKE Enterprise | Gérer les charges de travail et les clusters enregistrés sur le parc ; gérer les composants GKE Enterprise. |
| Kubernetes Engine | Gérer les charges de travail et les clusters enregistrés sur le parc. |
| Knative serving | Créer, déployer et gérer des services et des applications. |
| Marketplace | Déployer et gérer des applications tierces |
Accès du contrôleur côté Google Cloud aux clusters via Connect
Les contrôleurs côté Google Cloud accèdent à un cluster à partir du plan de contrôle Google Cloud à l'aide de l'agent Connect. Ces contrôleurs assurent la gestion et l'automatisation des fonctionnalités que vous activez sur vos clusters. Par exemple, Config Management dispose d'un contrôleur côté Google Cloud qui aide à diriger le cycle de vie des agents intégrés au cluster et fournit une interface utilisateur permettant de configurer et d'afficher l'état de Config Management s'exécutant sur plusieurs clusters.
Différents contrôleurs accèdent aux clusters à l'aide de différentes identités. Vous pouvez également auditer les activités de chaque contrôleur dans les journaux d'audit Kubernetes.
Le tableau suivant récapitule le fonctionnement des contrôleurs côté Google Cloud via Connect. Le tableau présente les principales informations sur les contrôleurs : les autorisations dont ils ont besoin, leurs identifiants dans les journaux d'audit Kubernetes et s'il est possible de les désactiver ou non.
Dans ce contexte, la désactivation d'un composant signifie de le désactiver complètement, sans qu'aucune partie individuelle du composant ne puisse être utilisée dans les clusters.
| Nom du composant | Peut-être désactivé ? | Rôle du cluster/Autorisations RBAC | Description | ID dans les journaux d'audit du cluster |
|---|---|---|---|---|
| Fonctionnalité Authorizer | Non (activé par défaut) | cluster-admin |
L'outil d'activation de fonctionnalités ajoute des autorisations RBAC pour les composants compatibles avec le parc (ou les fonctionnalités) fonctionnant sur les clusters Kubernetes, et garantit ainsi que chacun d'entre eux dispose des autorisations spécifiques requises pour exécuter ses fonctions. Vous ne pouvez pas désactiver l'outil d'activation de fonctionnalités tant qu'il y a des appartenances enregistrées dans le projet. Pour en savoir plus, consultez la section Activation de fonctionnalités dans un parc. |
service-project-number@gcp-sa-gkehub.iam.gserviceaccount.com |
| Config Management | Oui (désactivé par défaut) | cluster-admin |
Le contrôleur Config Management gère ses propres agents intégrés aux clusters et fournit une interface utilisateur qui indique l'état de Config Management sur tous les clusters d'un parc. Le contrôleur installe ses composants intégrés au cluster et crée un compte de service local avec les autorisations appropriées pour déployer tous les types de configurations Kubernetes au nom des utilisateurs. Si vous n'installez ni ne gérez les composants intégrés au cluster, le contrôleur Config Management lit les informations d'état à partir de son agent intégré au cluster. |
service-project-number@gcp-sa-acm.iam.gserviceaccount.com |
| Mesure de l'utilisation | Non (activé par défaut) | Voir la définition RBAC | Le contrôleur de mesure lit les informations de base sur les clusters connectés afin de fournir des services de facturation. Les autorisations du contrôleur sont nécessaires pour :
Vous ne pouvez pas désactiver les mesures, tant que des appartenances sont enregistrées dans le projet. |
service-project-number@gcp-sa-mcmetering.iam.gserviceaccount.com |
Autorisations RBAC pour des composants spécifiques fonctionnant via Connect
Les définitions d'API suivantes montrent les autorisations de contrôle d'accès pour différentes ressources de composants fonctionnant via Connect.
Autorisations RBAC pour mesurer l'utilisation via Connect
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
hub.gke.io/owner-feature: metering
hub.gke.io/project: [PROJECT_ID]
name: metering
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/metering
rules:
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- watch
- list
- apiGroups:
- metering.gke.io
resources:
- usagerecords
verbs:
- get
- list
- watch
- delete
- apiGroups:
- anthos.gke.io
resources:
- entitlements
verbs:
- create
- delete
- get
- list
- update
- watch
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- create
- list
- watch
- apiGroups:
- apiextensions.k8s.io
resourceNames:
- entitlements.anthos.gke.io
resources:
- customresourcedefinitions
verbs:
- get