Connecting to registered clusters with the Connect gateway
Fleets 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 Anthos users connect to and run commands against registered Anthos 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.
This guide assumes that you are already familiar with some basic fleet concepts, and with registering clusters to Google Cloud. If not, you can find out more in the Fleet management overview, the Fleet creation overview, and their linked guides. You should also be familiar with Kubernetes tools and concepts, including
client-go (if you want to use the gateway for automation purposes), role-based access control (RBAC), and core Kubernetes Resources.
The Connect gateway uses your Google ID to authenticate to clusters. To find out how to use IDs from your existing OIDC identity provider instead, see Introducing Anthos Identity Service.
Why use the Connect gateway?
There 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.
The Connect gateway makes it easy to:
- Discover what clusters exist (on Google Cloud, on another public cloud, or on premises) and are registered to your fleet through a simple query.
- Connect to a desired cluster using the same infrastructure we use to display registered Anthos clusters in the Google Cloud console.
- Authenticate using the same identities you use with Google Cloud services.
- Authorize consistently across all your clusters registered in a fleet.
The gateway authenticates your Google Cloud identity and provides the connection to the cluster's API server via the Connect service.
You 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 tutorial.
You 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 Logging in to a cluster from the Google Cloud console.
How it works
Here 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.
The user or service discovers clusters by listing fleet Membership resources with the Google Cloud CLI.
gcloud container fleet memberships list
The user or service fetches the Connect gateway-specific
kubeconfigneeded to reach their selected cluster by using the Google Cloud CLI.
gcloud container fleet memberships get-credentials membership-name
If you're already familiar with using the gcloud CLI with GKE, this is similar to running
gcloud container clusters get-credentialsusing your Google Cloud account, letting you (if authorized) access any cluster registered and connected within your project's fleet.
The user or service executes their commands as they normally would with
client-go, using the downloaded
- The user/service is authenticated by the Connect gateway, and authorization is checked to ensure they have permission to use the gateway.
- The request is forwarded through the Connect service and Connect Agent to the corresponding Kubernetes API server.
- 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.
Google Group support
In the standard flow described in the previous section, the user or service'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 security 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 Anthos Identity Service, you can configure the Connect gateway to get Google Group membership information for the user or service.
You can find out more about how this feature works and how to set it up in Set up the Connect gateway with Google Groups.
The 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<500ms and p99<1s. Note that most
kubectl commands perform a series of several different requests, each requiring a round-trip, before rendering a response to the user.
- Learn how to set up the Connect gateway for users and service accounts
- Learn how to set up Google Groups support for the Connect gateway.
- Learn how to connect to and run commands against a registered cluster using the Connect gateway
- See an example of how to use the Connect gateway as part of your DevOps automation in our Integrating with Cloud Build tutorial.