デフォルトでは、Connect Gateway は Google ID を使用してクラスタに対する認証を行います。これは、Workforce Identity 連携を使用するサードパーティの ID プロバイダと、GKE Identity Service を介したグループベースの認証をサポートしています。GKE Identity Service の詳細を確認したり、スタンドアロンのサードパーティ認証オプションとして使用する場合は、GKE Identity Service の概要をご覧ください。
Connect Gateway を使用する理由
クラスタが複数のクラウドやハイブリッド環境で実行されている場合、ワークロードの管理には多くの課題があります。クラスタが異なる Virtual Private Cloud（VPC）で実行され、異なる ID プロバイダを利用するため、接続、認証、承認が複雑になる場合があります。このような環境では、どのクラスタが存在するのか確認するのも難しい場合があります。
Connect Gateway を使用すると、次の処理を簡単に行うことができます。
Google Cloud、別のパブリック クラウド、オンプレミスに存在するクラスタを検出し、簡単なクエリを使用してフリートに登録する。
Google Cloud コンソールで登録済み GKE クラスタの表示に使用したものと同じインフラストラクチャを使用して、目的のクラスタに接続する。
Google Cloud サービスで使用しているものと同じ ID を使用して認証する。
フリートに登録されているすべてのクラスタに対して一貫して認可を行う。
Gateway は、 Google Cloud ID を認証し、Connect サービスを介してクラスタの API サーバーへの接続を提供します。
また、Connect サービスを使用して、 Google Cloud コンソールで Google Cloud ID を使用して Google Cloud 外部の登録済みクラスタに接続することもできます。これを行うには、 Google Cloud コンソールからクラスタを操作するの手順に沿って操作します。
仕組み
ここでは、標準的なユーザーまたはサービス（CI / CD パイプラインなど）が、適切な認証と認可を構成した後に、Connect Gateway を使用するために行うフローを示します。ユーザー向けの手順の詳細については、使用方法のガイドをご覧ください。
リクエストは、Connect Service と Connect Agent を介して、対応する Kubernetes API サーバーに転送されます。
Kubernetes API サーバーがリクエストを承認します。そのためには、Connect Agent がユーザーまたはサービスの権限を借用でき、ユーザーまたはサービスに目的のリクエストを行うための権限が付与されている必要があります。
Google グループのサポート
前のセクションで説明した標準フローでは、ユーザーのリクエストが個々の ID に基づいて承認されます。ただし、多くの場合、Google グループのメンバーシップに基づいてユーザーを認証できると便利です。グループ メンバーシップに基づいて認証すると、アカウントごとに個別の認証を設定する必要がないため、ポリシーの管理が簡素化され、監査が容易になります。たとえば、クラスタへのアクセスをチームで共有することで、ユーザーがチームに入ったり、チームから抜けたときに、個々のユーザーを手動でクラスタに追加または削除する必要がなくなります。GKE Identity Service を使用して追加設定を行うことで、ユーザーの Google グループ メンバーシップ情報を取得するように Connect Gateway を構成できます。
[[["わかりやすい","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,["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."]]
