使用 Connect 註冊 Kubernetes 叢集時，系統會在叢集和 Google Cloud控制層之間建立經過驗證及加密的長期連線。 Google Cloud 連線會在Google Cloud 控制台中顯示叢集相關資訊，並讓您使用 GKE 元件和功能 (例如 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"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],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"]]
