Introducing GKE Identity Service

GKE Identity Service is an authentication service that lets you bring your existing identity solutions for authentication to multiple GKE Enterprise environments. Users can log in to and use your GKE clusters from the command line or from the Google Cloud console, all using your existing identity provider.

If you already use or want to use Google IDs to log in to your GKE clusters instead of an OIDC or LDAP provider, see Connecting to registered clusters with the Connect gateway.

Supported identity providers

GKE Identity Service supports identity providers using the following protocols:

Supported cluster types

Protocol GKE on VMware GKE on Bare Metal GKE on AWS GKE on Azure EKS attached clusters GKE
OIDC
LDAP
SAML

Other attached cluster types are not supported for use with GKE Identity Service.

How it works

GKE Identity Service lets users log in to configured clusters using their usual organization username and password. How exactly this works depends on the type of identity provider used.

OIDC

With OIDC providers, GKE Identity Service itself is registered as a client application for the identity provider, and then set up for each cluster by the cluster administrator.

Diagram showing the basic AIS flow

When a user wants to log in to a cluster from the command line, they must first run a gcloud anthos auth login command, and input their login details for the identity provider. This retrieves an identity token from the provider. The token is added to their kubeconfig file and is used when making requests with kubectl to the cluster. The Kubernetes API server then uses GKE Identity Service to validate the ID token and allow (or deny) access to the cluster. GKE Identity Service can also optionally retrieve security group membership information from the identity provider.

Cluster administrators can add finer-grained access control using Kubernetes role-based access control (RBAC) if required.

Users can also log in with OIDC from the Google Cloud console. In this case, they are directed to the identity provider's UI to provide their login details before they are returned to the Google Cloud console to continue viewing and managing the cluster's resources.

LDAP

With LDAP providers, GKE Identity Service is set up for each cluster by the cluster administrator, including providing LDAP client credentials for GKE Identity Service.

Diagram showing the LDAP AIS flow

When a user wants to log in to a cluster from the command line, they must first run a gcloud anthos auth login command, and input their login details for the identity provider. The request goes to GKE Identity Service, which queries the LDAP server and returns the user attributes in a short-lived token (STS), ensuring that the user's LDAP credentials do not need to be stored locally in plaintext. The token is added to their kubeconfig file and is used when making requests with kubectl to the cluster. The Kubernetes API server then uses GKE Identity Service to get the user and group information from the token and allow (or deny) access to the cluster. By default the token lasts for one hour before the user needs to log in again.

Cluster administrators can add finer-grained access control using Kubernetes role-based access control (RBAC) if required.

Setup options

Depending on the cluster type and environment, cluster administrators can either set up GKE Identity Service on each cluster individually, or at the project fleet level.

Per-cluster setup

You can set up GKE Identity Service on a cluster by cluster basis for GKE clusters on-premises (both VMware and bare metal), on AWS, and on Azure. See the following guides for details:

OIDC setup

LDAP setup

SAML setup

Fleet-level setup

A fleet in Google Cloud is a logical group of clusters that lets you enable functionality and update configuration across those clusters. For supported cluster types, you can set up GKE Identity Service for the clusters in your project's fleet. Fleet-level setup lets you centrally apply authentication configuration to multiple clusters, where the configuration is maintained by Google Cloud.

The following cluster types are supported for fleet-level setup:

The following cluster type and environment is supported for fleet-level setup as a Pre-GA feature:

See the following for setup details:

What's next?

  • If you are a platform administrator or cluster administrator and want to configure clusters to use GKE Identity Service, follow the appropriate setup guides above.
  • If you are a developer or other cluster user and want to access GKE clusters using your existing identity, see Access clusters using GKE Identity Service.