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 fleet 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 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:
- OpenID Connect (OIDC). We provide specific instructions for setup for some popular OpenID providers, including Microsoft, but you can use any provider that implements OIDC.
- Lightweight Directory Access Protocol (LDAP). You can use GKE Identity Service to authenticate using LDAP with Active Directory or an LDAP server.
- Security Assertion Markup Language (SAML). You can use GKE Identity Service to authenticate using SAML.
Supported cluster types
Protocol | GDC (VMware) | GDC (bare metal) | GKE on AWS | GKE on Azure | EKS attached clusters | GKE on Google Cloud |
---|---|---|---|---|---|---|
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.
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.
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
- Configure OIDC providers for GKE Identity Service
- Set up clusters for GKE Identity Service with OIDC
- Set up user access for GKE Identity Service
LDAP setup
- Configure LDAP providers for GKE Identity Service
- Set up clusters for GKE Identity Service with LDAP
- Set up user access for GKE Identity Service
SAML setup
- Configure SAML providers for GKE Identity Service
- Set up clusters for GKE Identity Service with SAML
- Set up user access for GKE Identity Service through an alternative authentication process
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:
- Google Distributed Cloud on VMware, version 1.8.2 or higher
- Google Distributed Cloud on bare metal, version 1.8.3 or higher
- GKE on Azure
- GKE on AWS running Kubernetes 1.21 or higher
- GKE clusters on Google Cloud with Identity service for GKE enabled
The following cluster type and environment is supported for fleet-level setup as a Pre-GA feature:
- Amazon Elastic Kubernetes Service (Amazon EKS) attached clusters
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.