Google Cloud 中的機群是 Kubernetes 叢集和其他資源的邏輯群組，可透過向 Google Cloud註冊叢集來建立，並統一管理。Connect 閘道以機群的強大功能為基礎，讓 GKE 使用者能以簡單、一致且安全的方式，連線至機群成員叢集並執行指令，無論叢集位於 Google Cloud、其他公用雲端或內部部署環境，都能輕鬆自動化所有叢集的 DevOps 程序。
根據預設，Connect 閘道會使用您的 Google ID 向叢集進行驗證，並支援透過員工身分聯盟使用第三方識別資訊提供者，以及透過 GKE Identity Service 支援以群組為基礎的驗證。如要進一步瞭解 GKE Identity Service，或將其做為獨立的第三方驗證選項，請參閱「GKE Identity Service 簡介」。
如果是非 GKE Kubernetes 叢集，Kubernetes API 伺服器會授權要求，這需要授權 Connect 代理程式模擬使用者或服務，且使用者或服務已獲授權執行所需要求。
Google 群組支援
在上一節所述的標準流程中，系統會根據使用者的個別 ID 授權要求。不過，在許多情況下，根據使用者是否為 Google 群組成員授權，會很有幫助。根據群組成員資格授權，表示您不必為每個帳戶分別設定授權，因此政策管理和稽核作業都會更簡單。舉例來說，您可以輕鬆與團隊共用叢集存取權，當有人加入或離開團隊時，不必再手動新增/移除叢集中的個別使用者。透過 GKE Identity Service 進行一些額外設定後，您就能設定 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,["Connect to registered clusters with the Connect gateway\n\n\u003cbr /\u003e\n\nFleets in Google Cloud are logical groups of Kubernetes clusters and other resources that can be managed together, created by registering clusters to Google Cloud. The Connect gateway builds on the power of fleets to let GKE users connect to and run commands against fleet member clusters in a simple, consistent, and secured way, whether the clusters are on Google Cloud, other public clouds, or on-premises, and makes it easier to automate DevOps processes across all your clusters.\n\nThis guide assumes that you are already familiar with some basic fleet concepts, and with registering clusters to a fleet. If not, you can find out more in the [Fleet management overview](/kubernetes-engine/enterprise/multicluster-management/fleet-overview), the [Fleet creation overview](/kubernetes-engine/enterprise/multicluster-management/fleet-creation), and their linked guides. You should also be familiar with Kubernetes tools and concepts, including `kubectl`, `client-go` (if you want to use the gateway for automation purposes), role-based access control (RBAC), and core Kubernetes Resources.\n\nBy default the Connect gateway uses your Google ID to authenticate to clusters, with support for third party identity providers using [workforce identity federation](/kubernetes-engine/enterprise/multicluster-management/gateway/iam/docs/workforce-identity-federation), and with group-based authentication support via GKE Identity Service. If you want to find out more about GKE Identity Service, or use it as a standalone third-party authentication option, see [Introducing GKE Identity Service](/kubernetes-engine/enterprise/identity).\n\nWhy use the Connect gateway?\n\nThere are many challenges in managing workloads when your clusters are running in multiple clouds and hybrid environments. Clusters might be running in different virtual private clouds (VPCs) and leverage different identity providers, making connectivity, authentication, and authorization more complicated. Sometimes, just finding out which clusters exist across these environments is difficult.\n\nThe Connect gateway makes it easy to:\n\n- **Discover** what clusters exist (on Google Cloud, on another public cloud, or on-premises) and are registered to your fleet through a simple query.\n- **Connect** to a desired cluster using the same infrastructure we use to display registered GKE clusters in the Google Cloud console.\n- **Authenticate** using the same identities you use with Google Cloud services.\n- **Authorize** consistently across all your clusters registered in a fleet.\n\nThe gateway authenticates your Google Cloud identity and provides the connection to the cluster's API server via the Connect service.\n\nYou can interact with clusters directly yourself through the gateway using command line tools that accept a `kubeconfig` such as `kubectl`. You can also easily leverage the gateway with your build pipelines and other DevOps automation. You can see an example of how to do this in our [Integrating with Cloud Build](/kubernetes-engine/enterprise/multicluster-management/gateway/tutorials/cloud-build-integration) tutorial.\n\nYou can also use the Connect service to connect to registered clusters outside Google Cloud with your Google Cloud identity in the Google Cloud console. To do this, follow the instructions in [Work with clusters from the Google Cloud console](/kubernetes-engine/fleet-management/docs/console).\n\nHow it works\n\nHere is the flow that a typical user or service (such as a CI/CD pipeline) performs to use the Connect gateway, after appropriate authentication and authorization is configured. For more detailed user instructions, see our [usage guide](/kubernetes-engine/enterprise/multicluster-management/gateway/using).\n\n1. The user or service discovers clusters by listing fleet Membership resources with the Google Cloud CLI.\n\n ```\n gcloud container fleet memberships list\n ```\n2. The user or service fetches the Connect gateway-specific `kubeconfig` needed to reach their selected cluster by using the Google Cloud CLI.\n\n ```\n gcloud container fleet memberships get-credentials membership-name\n ```\n\n If you're already familiar with using the gcloud CLI with GKE, this is similar to running `gcloud container clusters get-credentials` using your Google Cloud account, letting you (if authorized) access any cluster registered and connected within your project's fleet.\n3. The user or service executes their commands as they normally would with`kubectl` or `client-go`, using the downloaded `kubeconfig` file.\n\n 1. The user/service is authenticated by the Connect gateway, and authorization is checked to ensure they have permission to use the gateway. For GKE clusters, gateway connects to the GKE cluster directly.\n 2. For non-GKE Kubernetes clusters, the request is forwarded through the Connect service and Connect Agent to the corresponding Kubernetes API server.\n 3. For non-GKE Kubernetes clusters, the Kubernetes API server authorizes the request, which requires that the Connect agent is authorized to impersonate the user or service, and that the user or service is authorized to execute the desired request.\n\n| **Note:** Using Chrome Enterprise Premium with IP address restrictions as an attribute, including through geographical restrictions, is not supported by the Connect gateway for GKE clusters.\n\nGoogle Group support\n\nIn the standard flow described in the previous section, the user's request is authorized based on their individual ID. However, in many cases it's useful to be able to authorize users on the basis of their membership of *Google Groups* . Authorizing based on group membership means you don't have to set up separate authorization for each account, making policies simpler to manage and easier to audit. So, for example, you can easily share cluster access to a team, removing the need to manually add/remove individual users from clusters when they join or leave the team. With some additional setup using [GKE Identity Service](/kubernetes-engine/enterprise/identity), you can configure the Connect gateway to get Google Group membership information for the user.\n\nYou can find out more about how this feature works and how to set it up in [Set up the Connect gateway with Google Groups](/kubernetes-engine/enterprise/multicluster-management/gateway/setup-groups).\n| **Note:** The Connect gateway's Google groups feature is supported for Google Distributed Cloud deployments [on VMware](/anthos/clusters/docs/on-prem) and [on bare metal](/anthos/clusters/docs/bare-metal/latest/concepts/about-bare-metal) from Distributed Cloud software only version 1.13 onwards.\n\nIf you want to use this feature with attached clusters or other GKE environments, contact [Cloud Customer Care](/support) or [the Connect gateway team](mailto:connect-gateway-feedback@google.com).\n\nThird-party identity support\n\nIn addition to working with Google Workspace users and groups, Connect gateway\nsupports authorization using third-party identities, such as Azure Active Directory and\nOkta. By using\n[workforce identity federation](/kubernetes-engine/enterprise/multicluster-management/gateway/iam/docs/workforce-identity-federation),\nyou can use an external identity provider to authenticate and authorize a\nworkforce---a group of users, such as employees, partners, and\ncontractors---using Identity and Access Management, so that the users can access\nGoogle Cloud services like Connect gateway. With some additional setup using\n[GKE Identity Service](/kubernetes-engine/enterprise/identity), you can configure the Connect\ngateway to get third-party group membership information for users.\n\nFor GKE attached clusters, this feature is available for all\n[supported Kubernetes cluster versions](/kubernetes-engine/multi-cloud/docs/attached/aks/reference/supported-versions).\n\nYou can find out more about how this feature works and how to set it up in [Set up the Connect gateway with third-party identities](/kubernetes-engine/enterprise/multicluster-management/gateway/setup-third-party).\n\nIf you prefer, you can set up third-party authentication entirely using GKE Identity Service\nfollowing the instructions in its [documentation](/kubernetes-engine/enterprise/identity).\n\nLatency\n\nThe total latency of a request via the gateway can be divided into two parts: the RTT (Round Trip Time) from the Connect gateway service to the Connect agent, and the request execution time inside the cluster. The extra latency brought by the RTT is p95\\\u003c500ms and p99\\\u003c1s. Note that most `kubectl` commands perform a series of several different requests, each requiring a round-trip, before rendering a response to the user.\n\nWhat's next?\n\n- Learn how to [set up the Connect gateway](/kubernetes-engine/enterprise/multicluster-management/gateway/setup) for users and service accounts\n- Learn how to [set up Google Groups support for the Connect gateway](/kubernetes-engine/enterprise/multicluster-management/gateway/setup-groups).\n- Learn how to connect to and run commands against a registered cluster [using the Connect gateway](/kubernetes-engine/enterprise/multicluster-management/gateway/using)\n- See an example of how to use the Connect gateway as part of your DevOps automation in our [Integrating with Cloud Build](/kubernetes-engine/enterprise/multicluster-management/gateway/tutorials/cloud-build-integration) tutorial."]]
