Google Cloud 中的舰队是 Kubernetes 集群及其他可共同管理的资源的逻辑分组，通过将集群注册到 Google Cloud来创建。Connect 网关以舰队为基础，让 GKE Enterprise 用户能够以简单、一致且安全的方式连接到舰队成员集群并运行命令，无论集群是位于 Google Cloud、其他公有云还是本地部署上，让您可以更轻松地在所有集群中自动执行 DevOps 流程。
默认情况下，Connect Gateway 会使用您的 Google ID 向集群进行身份验证，支持使用员工身份联合的第三方身份提供方，并通过 GKE Identity Service 提供基于群组的身份验证支持。如果您想要详细了解 GKE Identity Service，或将其用作独立的第三方身份验证选项，请参阅 GKE Identity Service 简介。
请求通过 Connect 服务和 Connect Agent 转发到相应的 Kubernetes API 服务器。
Kubernetes API 服务器为请求授权，这要求 Connect 代理有权模拟用户或服务，并且用户或服务有权执行所需的请求。
Google 群组支持
在上一部分所述的标准流程中，用户的请求基于其个人 ID 进行授权。但是，在许多情况下，如果能够根据用户的 Google 群组成员资格为用户授权，会是很有帮助的。基于群组成员资格进行授权意味着您无需为每个账号设置单独的授权，这样可以使政策更易于管理且更易于审核。例如，您可以轻松与团队共享集群访问权限，而无需在单个用户加入或离开团队时从集群手动添加/移除他们。使用 GKE Identity Service 进行一些额外设置，您可以将 Connect Gateway 配置为获取用户的 Google 群组成员资格信息。
除了使用 Google Workspace 用户和群组之外，Connect Gateway 还支持使用第三方身份（例如 Azure Active Directory 和 Okta）进行授权。通过使用员工身份联合，您可以使用外部身份提供方通过 Identity and Access Management 对员工（一组用户，例如员工、合作伙伴和承包商）进行身份验证和授权，以便用户能够访问 Connect Gateway 等Google Cloud 服务。使用 GKE Identity Service 进行一些额外设置后，您可以配置 Connect Gateway 以获取用户的第三方群组成员资格信息。
从 Anthos (GKE Enterprise) 1.13 开始，Google Distributed Cloud on VMware 和 Google Distributed Cloud on Bare Metal 部署支持 Connect 网关的第三方身份功能。对于关联集群，此功能从 Anthos 1.16 及更高版本开始可用。
[[["易于理解","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-08-04。"],[],[],null,["# Connect to registered clusters with the Connect gateway\n=======================================================\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 Enterprise 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----------------------------\n\nThere are many challenges in managing workloads when your clusters are running in multiple clouds and hybrid environments. Clusters may 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------------\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.\n 2. The request is forwarded through the Connect service and Connect Agent to the corresponding Kubernetes API server.\n 3. 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\n### Google 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 Anthos (GKE Enterprise) version 1.13 onwards.\n\nIf you want to use this feature with attached clusters or other GKE Enterprise environments, please contact [Cloud Customer Care](/support) or [the Connect gateway team](mailto:connect-gateway-feedback@google.com).\n\n### Third-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\nThe Connect gateway's third-party identity feature is supported for\nGoogle 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 Anthos (GKE Enterprise) version 1.13 onwards. For attached clusters, this feature\nis available from Anthos 1.16 and later.\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\n### Latency\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\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."]]
