GKE on-prem supports OpenID Connect (OIDC) for authenticating against user clusters using the command line. See the following topics:
To log in via Google Cloud console, GKE on-prem supports using a Kubernetes service account's bearer token. See Logging in to a cluster from Google Cloud console.
This topic assumes are you familiar with OAuth 2.0 and OpenID Connect. You should also be familiar with scopes and claims in the context of OpenID authentication.
Overview
With OIDC, you can manage access to a Kubernetes cluster by using the standard procedures in your organization for creating, enabling, and disabling employee accounts. You can also use your organization's security groups to configure access to a Kubernetes cluster or to specific services in the cluster.
A user signs in to an OpenID provider by presenting a username and password.
The OpenID provider issues an ID token for the user. The token is signed by the provider.
An application, acting on behalf of the user, sends an HTTPS request to the Kubernetes API server. The application includes the user's ID token in the request header.
The Kubernetes API server verifies the token by using the provider's certificate.
If your enterprise runs an Active Directory Federation Services (ADFS) server, the ADFS server could serve as your OpenID provider. Another option is to use a third party as your OpenID provider, For example, Google, Microsoft, Facebook, and Twitter are all OpenID providers.
Using the gcloud CLI to call the Kubernetes API server
You run the gcloud anthos auth login command to authenticate with your
clusters, and as a result, your request goes to the Kubernetes API server.
For this to work, your OIDC ID tokens must be stored in the
kubeconfig file.
GKE on-prem uses the gcloud CLI of Google Cloud CLI to request and
obtain the ID token and other OIDC values in the kubeconfig file.
The Kubernetes API server and the ID token
After authenticated with the cluster, you can interact using the kubectl CLI
of gcloud CLI. When kubectl calls the Kubernetes API server on behalf
of the user, the API server verifies the token by using the OpenID provider's
public certificate. Then the API server parses the token to learn the user's
identity and the user's security groups.
The API server determines whether the user is authorized to make this particular call by comparing the user's security groups to the cluster's role-based Access Control (RBAC) policy.