Connect を使用して Kubernetes クラスタを Google Cloud に登録すると、クラスタと Google Cloudコントロール プレーンの間に認証され、暗号化された長期間継続する接続が確立されます。この接続により、クラスタに関する情報がGoogle Cloud コンソールに表示され、Config Management などの GKE Enterprise コンポーネントと機能を使用して構成とリソースを管理し、クラスタにデプロイできるようになります。
このトピックでは、 Google Cloud と Connect 間の接続の性質と、Connect を介してクラスタで動作する Google Cloud側のコントローラの詳細について説明します。
Google Cloud と Connect 間の接続について
セキュリティ機能のトピックで説明されているとおり、接続されている各クラスタ（クラスタの API サーバーなど）への Connect を介してのリクエストは、 Google Cloud コントロール プレーンによってのみ行われ、クラスタからコントロール プレーンへのレスポンスが返信されます（クラスタのサービスとリソースは、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-01 UTC。"],[],[],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"]]
