GKE on-prem supports OpenID Connect (OIDC) for authenticating against user clusters via the command line. See the following topics:
To log in via Google Cloud console, GKE on-prem suports using a Kubernetes service account's bearer token. See Logging in .
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 Kubectl Plugin for OIDC to call the Kubernetes API server
Typically, a user enters a
kubectl
command, and as a result, kubectl calls the Kubernetes API server.
For this to work, the user's ID token must be in the kubeconfig file. GKE on-prem provides the Kubectl Plugin for OIDC to include the token and other OIDC values in kubeconfig.
The Kubernetes API server and the ID token
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.