使用 Connect 向 Google Cloud 注册 Kubernetes 集群后，集群和 Google Cloud控制平面之间会建立长期有效的 经过身份验证和加密的连接。此连接显示了Google Cloud 控制台中的集群的相关信息，并允许您使用 GKE Enterprise 组件和功能（例如 Config Management）管理配置和资源并将其部署到集群。
本主题描述了 Google Cloud 与 Connect 之间的连接的性质，并详细介绍了通过 Connect 在集群上运行的 Google Cloud端控制器。
Google Cloud 与 Connect 之间的连接简介
如安全功能主题中所述，只有 Google Cloud 控制平面会通过 Connect 向每个连接的集群（例如，集群的 API 服务器）发出请求，并且集群会将响应发送回该控制平面。（集群服务和资源无法通过 Connect 向控制平面发起请求。）此连接允许已获授权的用户和 Google 端自动化访问集群并对其进行身份验证。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-01。"],[],[],null,["Topic last modified: June 18 2024\n\n\u003cbr /\u003e\n\n| **Note:** The information in this topic is not exhaustive. It will change over time as new components that operate over Connect are introduced or as the scope or permissions of existing Google Cloud-side controllers evolve.\n\nWhen you register your Kubernetes clusters with Google Cloud using\nConnect, a long-lived,\n[authenticated and encrypted](/kubernetes-engine/fleet-management/docs/connect-agent/security-features)\nconnection is established between your clusters and the Google Cloud\ncontrol plane. The connection surfaces information about clusters in the\nGoogle Cloud console, and it lets you manage and deploy configurations and\nresources to clusters using GKE components and features,\nsuch as Config Management.\n\nThis topic describes the nature of the connection between Google Cloud and\nConnect and provides details about the Google Cloud-side\ncontrollers that operate on your clusters over Connect.\n\nAbout the connection between Google Cloud and Connect\n\nAs described in the [Security features](/kubernetes-engine/fleet-management/docs/connect-agent/security-features) topic,\nonly the Google Cloud control plane makes requests over\nConnect to each connected cluster (for example, to a cluster's\nAPI server), and the cluster sends responses back to the control plane. (Cluster\nservices and resources cannot initiate requests to the control plane\nover Connect.)\nThe connection allows authorized users and Google-side automation to\nreach and authenticate against clusters.\n\nFor example,\nConnect lets the Google Cloud console get information about\nworkloads and services; or allows Config Management to install or\nupdate the Connect in-cluster agent and observe the sync status.\nConnect also lets the metering agent observe the number of\nvCPUs in a connected cluster.\n\nConnect does not provide data transport for container images,\nload balancing, database connections, Logging, or\nMonitoring. You must establish connectivity for those in parallel\nthrough their own mechanisms.\n\nGoogle Cloud console user access to clusters through Connect\n\nAfter users in your organization\n[log in](/kubernetes-engine/fleet-management/docs/console#log-in) to a\ncluster through the Google Cloud console, they have specific cluster permissions\ndetermined by the role-based access controls (RBAC) assigned to them. The\ncluster (not Connect) enforces the permissions. Standard\nKubernetes logs let you audit the actions that each user took in managing\na cluster.\n\nThe following table shows which parts of the Google Cloud console let users\ninteract with clusters through Connect.\n\n| Google Cloud console section | What users can do |\n|-----------------------------------------------------------------------|------------------------------------------------------------------------|\n| [Kubernetes Engine](https://console.cloud.google.com/kubernetes/list) | Manage fleet-registered clusters and workloads, manage GKE components. |\n| [Knative serving](https://console.cloud.google.com/kubernetes/run) | Build, deploy, and manage services and applications. |\n| [Marketplace](https://console.cloud.google.com/marketplace) | Deploy and manage third-party applications. |\n\nGoogle Cloud-side controller access to clusters through Connect\n\nGoogle Cloud-side controllers access a cluster from\nthe Google Cloud control plane using the\n[Connect Agent](/kubernetes-engine/fleet-management/docs/connect-agent/security-features#architecture-of-connect-for-anthos).\nThese controllers provide management and automation for the functionality you\nenable on your clusters. For example, Config Management has a\nGoogle Cloud-side controller that helps direct the\nlifecycle of in-cluster agents and provides a UI to configure and view\nthe status of Config Management running across multiple clusters.\n\nDifferent controllers access clusters using different identities,\nand you can audit each controller's activities in Kubernetes\n[audit logs](/kubernetes-engine/docs/how-to/audit-logging).\n\nThe following table summarizes how Google Cloud-side controllers\noperate over Connect. The table highlights key details about\ncontrollers: the permissions they need, their IDs in Kubernetes audit logs,\nand whether or not you can disable them.\n\nDisabling a component in this context means turning it off completely, with\nno individual parts of the component able to be used in clusters.\n\n| Component Name | Can be disabled? | Cluster role / RBAC permissions | Description | ID in cluster audit logs |\n|--------------------|-------------------------------|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|\n| Feature Authorizer | No (**enabled** by default) | `cluster-admin` | Feature Authorizer adds RBAC for [fleet-enabled components](/kubernetes-engine/enterprise/multicluster-management/fleets#fleet-enabled-components), or features, operating on Kubernetes clusters, ensuring each has only the specific permissions required to perform its functions. You cannot disable Feature Authorizer as long as there are registered Memberships in the project. See [Feature authorization in a fleet](/kubernetes-engine/fleet-management/docs/manage-features#feature_authorization) for more information. | service-\u003cvar translate=\"no\"\u003eproject-number\u003c/var\u003e@gcp-sa-**gkehub**.iam.gserviceaccount.com |\n| Config Management | Yes (**disabled** by default) | `cluster-admin` | The Config Management controller manages its own in-cluster agents and provides a UI that shows the status of Config Management across all clusters in a fleet. The controller installs its in-cluster components and creates a local service account with the appropriate permissions to deploy all types of Kubernetes configurations on behalf of users. When not installing or managing in-cluster components, the Config Management controller reads status information from its in-cluster agent. | service-\u003cvar translate=\"no\"\u003eproject-number\u003c/var\u003e@gcp-sa-**acm**.iam.gserviceaccount.com |\n| Usage metering | No (**enabled** by default) | See [RBAC definition](#metering) | The metering controller reads basic information about connected clusters to provide billing services. This controller requires its permissions to: - Meter based on node vCPU capacity. - Watch and delete the `metering.gke.io/usagerecords` custom resource. - Create and update the `anthos.gke.io/entitlements` custom resource. You cannot disable Metering, as long as there are registered Memberships in the project. | service-\u003cvar translate=\"no\"\u003eproject-number\u003c/var\u003e@gcp-sa-**mcmetering**.iam.gserviceaccount.com |\n\nRBAC for specific components operating over Connect\n\nThe following API definitions show access control permissions for different\ncomponent resources operating over Connect.\n\nUsage metering RBAC over Connect \n\n apiVersion: rbac.authorization.k8s.io/v1\n kind: ClusterRole\n metadata:\n labels:\n hub.gke.io/owner-feature: metering\n hub.gke.io/project: [PROJECT_ID]\n name: metering\n selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/metering\n rules:\n - apiGroups:\n - \"\"\n resources:\n - nodes\n verbs:\n - get\n - watch\n - list\n - apiGroups:\n - metering.gke.io\n resources:\n - usagerecords\n verbs:\n - get\n - list\n - watch\n - delete\n - apiGroups:\n - anthos.gke.io\n resources:\n - entitlements\n verbs:\n - create\n - delete\n - get\n - list\n - update\n - watch\n - apiGroups:\n - apiextensions.k8s.io\n resources:\n - customresourcedefinitions\n verbs:\n - create\n - list\n - watch\n - apiGroups:\n - apiextensions.k8s.io\n resourceNames:\n - entitlements.anthos.gke.io\n resources:\n - customresourcedefinitions\n verbs:\n - get"]]
