You can use existing third-party identity providers to authenticate to your Kubernetes clusters that are registered to a fleet. This document describes the supported authentication protocols and the types of clusters that support each protocol. Users can access and manage your clusters from the command line or from the Google Cloud console, without requiring you to change your identity provider.
If you prefer to use Google IDs to log in to your clusters instead of using an identity provider, see Connect to registered clusters with the Connect gateway.
Supported identity providers
If you have a third-party identity provider, you can use the following protocols to authenticate to your clusters:
- OpenID Connect (OIDC): OIDC is a modern, lightweight authentication protocol built on top of the OAuth 2.0 authorization framework. We provide specific instructions for setup of some popular OpenID Connect providers, including Microsoft, but you can use any provider that implements OIDC.
- Security Assertion Markup Language (SAML): SAML is an XML-based standard for exchanging authentication and authorization data between parties, primarily between an identity provider (IdP) and a service provider (SP).
- Lightweight Directory Access Protocol (LDAP): LDAP is a mature, standardized protocol for accessing and managing directory information services. It's commonly used to store and retrieve user information, such as usernames, passwords, and group memberships. You can authenticate by using LDAP with Active Directory or an LDAP server.
Supported cluster types
This authentication service can be installed only on clusters that are registered to a fleet. Most cluster types are always registered to a fleet. For GKE clusters on Google Cloud, you must explicitly register the clusters to your fleet to use this service.
The following table describes the cluster types that support third-party authentication and the specific protocols that you can use for each type:
| Supported cluster types and protocols | |
|---|---|
| GDC (VMware) |
Supports the following protocols:
|
| GDC (bare metal) |
Supports the following protocols:
|
| GKE on Google Cloud (fleet members only) | Supports OIDC |
| GKE on AWS |
Supports OIDC |
| GKE on Azure |
Supports OIDC |
The following configurations aren't supported:
- GKE attached clusters: any EKS, AKS, or other Kubernetes installations aren't supported. To connect to these GKE attached clusters, use the Connect gateway.
- For VMware deployments of Google Distributed Cloud, you can authenticate only to user clusters by using the LDAP protocol. Admin clusters on VMware don't support authentication with LDAP.
- GKE clusters on Google Cloud: your GKE clusters must be registered to your fleet. To connect to GKE clusters that aren't in a fleet, use Workforce Identity Federation.
Setup process
Setting up authentication from third-party identity providers involves the following users and steps:
- Configure providers: The platform administrator registers a client application with their identity provider. This client application has the protocol-specific configuration for Kubernetes. The platform administrator gets a client ID and secret from the identity provider.
Set up clusters: The cluster administrator sets up clusters for your identity service. Cluster administrators can set up clusters as follows:
- Fleet-level setup: the cluster administrator configures all of the clusters that are registered to a specific fleet. Use this method to set up multiple clusters at once with a similar configuration. For more information, see Set up fleet-level authentication.
Individual cluster setup: the cluster administrator configures each cluster separately. Use this method for scenarios where different cluster types need different authentication configurations. For more information, see the following documents:
Set up user access: The cluster administrator sets up user login access to authenticate to the clusters using the FQDN access (recommended) or file-based access approach, and optionally configures Kubernetes role-based access control (RBAC) for users on these clusters.