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 Cloud Console.
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.
gcloud tool 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
GKE on-prem uses the
gcloud tool of Cloud SDK to request and
obtain the ID token and other OIDC values in the
The Kubernetes API server and the ID token
After authenticated with the cluster, you can interact using the
of Cloud SDK. 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.