Cuando registras tus clústeres de Kubernetes con Connect, se establece una conexión autenticada y cifrada de larga duración entre tus clústeres y el Google Cloudplano de control. Google Cloud La conexión muestra información sobre los clústeres en la consola y te permite gestionar y desplegar configuraciones y recursos en los clústeres mediante componentes y funciones de GKE, como Config Management.Google Cloud
En este tema se describe la naturaleza de la conexión entre Google Cloud y Connect, y se proporcionan detalles sobre los controladores del lado de Google Cloud que operan en tus clústeres a través de Connect.
Acerca de la conexión entre Google Cloud y Connect
Como se describe en el tema Funciones de seguridad, solo el plano de control de Google Cloud hace solicitudes a través de Connect a cada clúster conectado (por ejemplo, al servidor de la API de un clúster), y el clúster envía respuestas al plano de control. Los servicios y recursos del clúster no pueden iniciar solicitudes al plano de control a través de Connect. La conexión permite que los usuarios autorizados y la automatización del lado de Google accedan a los clústeres y se autentiquen en ellos.
Por ejemplo, Connect permite que la consola Google Cloud obtenga información sobre las cargas de trabajo y los servicios, o que Gestión de configuración instale o actualice el agente de Connect en el clúster y observe el estado de sincronización. Connect también permite que el agente de medición observe el número de vCPUs de un clúster conectado.
Connect no proporciona transporte de datos para imágenes de contenedor, equilibrio de carga, conexiones de bases de datos, registro o monitorización. Debes establecer la conectividad de forma paralela a través de sus propios mecanismos.
Google Cloud acceso de los usuarios de la consola a los clústeres a través de Connect
Después de que los usuarios de tu organización inicien sesión en un clúster a través de la consola de Google Cloud , tendrán permisos específicos en el clúster, que se determinan mediante los controles de acceso basados en roles (RBAC) que se les hayan asignado. El clúster (no Connect) aplica los permisos. Los registros estándar de Kubernetes le permiten auditar las acciones que ha realizado cada usuario para gestionar un clúster.
En la siguiente tabla se muestra qué partes de la consola de Google Cloud permiten a los usuarios interactuar con los clústeres a través de Connect.
| SecciónGoogle Cloud de la consola | Qué pueden hacer los usuarios |
|---|---|
| Kubernetes Engine | Gestionar clústeres y cargas de trabajo registrados en la flota, así como componentes de GKE. |
| Servicio de Knative | Crea, despliega y gestiona servicios y aplicaciones. |
| Marketplace | Implementar y gestionar aplicaciones de terceros. |
Acceso del controlador del ladoGoogle Clouda los clústeres mediante Connect
Los controladores del ladoGoogle CloudGoogle Cloud acceden a un clúster desde el plano de control mediante el agente de Connect. Estos controladores proporcionan gestión y automatización para las funciones que habilitas en tus clústeres. Por ejemplo, Config Management tiene un controlador del lado delGoogle Cloudque ayuda a dirigir el ciclo de vida de los agentes del clúster y proporciona una interfaz de usuario para configurar y ver el estado de Config Management en varios clústeres.
Los distintos controladores acceden a los clústeres con identidades diferentes y puedes auditar las actividades de cada controlador en los registros de auditoría de Kubernetes.
En la siguiente tabla se resume cómo funcionan los controladores del lado de Google Clouda través de Connect. En la tabla se destacan los detalles clave sobre los controladores: los permisos que necesitan, sus IDs en los registros de auditoría de Kubernetes y si se pueden inhabilitar o no.
Inhabilitar un componente en este contexto significa desactivarlo por completo, de modo que no se pueda usar ninguna de sus partes en clústeres.
| Nombre del componente | ¿Se puede inhabilitar? | Rol de clúster o permisos de control de acceso basado en roles | Descripción | ID en los registros de auditoría del clúster |
|---|---|---|---|---|
| Feature Authorizer | No (habilitado de forma predeterminada) | cluster-admin |
Feature Authorizer añade RBAC para los componentes o las funciones habilitados para flotas que operan en clústeres de Kubernetes, lo que garantiza que cada uno tenga solo los permisos específicos necesarios para llevar a cabo sus funciones. No puedes inhabilitar Feature Authorizer mientras haya membresías registradas en el proyecto. Consulta más información sobre la autorización de funciones en una flota. |
service-project-number@gcp-sa-gkehub.iam.gserviceaccount.com |
| Config Management | Sí (inhabilitado de forma predeterminada) | cluster-admin |
El controlador de Config Management gestiona sus propios agentes en el clúster y proporciona una interfaz de usuario que muestra el estado de Config Management en todos los clústeres de una flota. El controlador instala sus componentes en el clúster y crea una cuenta de servicio local con los permisos adecuados para implementar todos los tipos de configuraciones de Kubernetes en nombre de los usuarios. Cuando no se instalan ni se gestionan componentes en el clúster, el controlador de Config Management lee la información de estado de su agente en el clúster. |
service-project-number@gcp-sa-acm.iam.gserviceaccount.com |
| Medición del uso | No (habilitado de forma predeterminada) | Consulta la definición de control de acceso basado en roles. | El controlador de medición lee información básica sobre los clústeres conectados para proporcionar servicios de facturación. Este controlador requiere permisos para:
No puedes inhabilitar la medición mientras haya suscripciones registradas en el proyecto. |
service-project-number@gcp-sa-mcmetering.iam.gserviceaccount.com |
RBAC para componentes específicos que operan en Connect
Las siguientes definiciones de API muestran los permisos de control de acceso de diferentes recursos de componentes que operan en Connect.
Control de acceso basado en roles de medición del uso en 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