Gateway Connect
Use the Connect gateway to connect to clusters that have been registered.
By registering clusters to Google Cloud, logical groups of Kubernetes clusters and other resources that may be managed jointly are called fleets. In addition to facilitating the automation of DevOps processes across all of your clusters, the Connect gateway expands on the capabilities of fleets by enabling GKE Enterprise users to connect to and execute commands against fleet member clusters in a straightforward, consistent, and secure manner, regardless of whether the clusters are located on-site or on Google Cloud or other public clouds.
It is assumed in this article that you are already familiar with registering clusters to a fleet and some basic fleet ideas. Otherwise, the Fleet creation overview, Fleet administration overview, and their associated manuals provide additional information. Kubernetes tools and concepts, such as kubectl, client-go (if you wish to use the gateway for automation), role-based access control (RBAC), and core Kubernetes Resources, should also be familiar to you.
The Connect gateway authenticates to clusters using your Google ID by default. It also supports group-based authentication with GKE Identity Service and third-party identity providers through workforce identity federation.
Why use the Connect gateway?
Workload management becomes extremely difficult when your clusters are operating in hybrid and different cloud environments. Clusters may use various identity providers and operate in various virtual private clouds (VPCs), which complicates authorisation, authentication, and networking. It can also be challenging to simply identify the clusters that are present in these contexts.
The Connect gateway facilitates the following:
- Use a straightforward query to find out which clusters are registered to your fleet and are available (on Google Cloud, another public cloud, or on-premises).
- Using the same infrastructure that we use to show registered GKE clusters in the Google Cloud dashboard, connect to a selected cluster.
- Use the same IDs that you use to log in to Google Cloud services.
- Give uniform authorisation to each of your clusters that are enrolled in a fleet.
Through the Connect service, the gateway establishes a connection to the cluster’s API server and verifies your Google Cloud identity.
Through the gateway, you can use command-line tools like kubectl that accept a kubeconfig to directly interface with clusters. Using the gateway with your build pipelines and other DevOps automation is very simple. Our tutorial on Integrating with Cloud Build provides an example of how to accomplish this.
Using your Google Cloud identity in the Google Cloud UI, you can also connect to registered clusters outside of Google Cloud using the Connect service. To accomplish this, adhere to the guidelines in the Google Cloud console’s Work with clusters section.
How it operates?
Once the proper authentication and authorisation are set up, this is the process that a normal user or service (like a CI/CD pipeline) follows to use the Connect gateway.
Using the Google Cloud CLI to list fleet Membership resources, the user or service finds clusters.
gcloud container fleet memberships list
Using the Google Cloud CLI, the user or service retrieves the Connect gateway-specific kubeconfig required to access the cluster of their choice.
gcloud container fleet memberships get-credentials membership-name
This is comparable to running gcloud container clusters get-credentials with your Google Cloud account if you are already accustomed to using the gcloud CLI with GKE. If you are granted permission, you can access any cluster that is registered and connected inside the fleet of your project.
- Using the downloaded kubeconfig file, the user or service runs their commands as they would with kubectl or client-go.
- The Connect gateway authenticates the user or service and verifies that they are authorised to use the gateway.
- The request is routed to the relevant Kubernetes API server via the Connect service and Connect Agent.
- Both the user or service must be authorised to execute the requested action and the Connect agent must be authorised to impersonate the user or service in order for the Kubernetes API server to authorise the request.
Google Group assistance
The user’s request is approved based on their unique ID in the typical flow that was explained in the previous section. Nonetheless, the ability to grant users access based on their Google Group membership is often helpful. Group membership-based authorisation eliminates the need to create unique authorisation for every account, simplifying management and auditing of policies. For instance, sharing cluster access with a team is simple and eliminates the need to manually add or delete team members from clusters as they join or go. You may set up the Connect gateway to retrieve the user’s Google Group membership details with a little extra work using GKE Identity Service.
Support for third-party identities
Connect gateway allows authorisation using third-party identities, including Azure Active Directory and Okta, in addition to working with Google Workspace users and groups. In order to authenticate and authorise a workforce a collection of users, including partners, contractors, and employees using Identity and Access Management, you can utilise workforce identity federation. This allows users to access Google Cloud services, such as Connect gateway, through an external identity provider. You may set up the Connect gateway to retrieve user membership information for third-party groups with a little extra work using GKE Identity Service.
The third-party identification capability of the Connect gateway is compatible with Google Distributed Cloud deployments running on bare metal and VMware starting with Anthos (GKE Enterprise) version 1.13. This capability is available for attached clusters starting with Anthos 1.16.
Latency
The RTT (round trip time) from the Connect gateway service to the Connect agent and the request execution time within the cluster are the two components of the overall latency of a request made through the gateway. The RTT adds p95<500ms and p99<1s to the latency. Before providing a response to the user, the majority of kubectl commands execute a sequence of many queries, each of which necessitates a round-trip.
