You can use existing third-party identity providers to authenticate to your Kubernetes clusters. 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 GKE clusters instead of 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
| Protocol | GDC (VMware) | GDC (bare metal) | GKE on AWS | GKE on Azure | GKE on Google Cloud |
|---|---|---|---|---|---|
| OIDC | |||||
| LDAP | |||||
| SAML |
You can't authenticate to other attached cluster types from third-party identity providers.
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 individual clusters or set up your fleet: The cluster administrator sets up clusters for your identity service. Cluster administrators can configure individual clusters for Google Distributed Cloud (both VMware and bare metal), GKE on AWS, or GKE on Azure. Alternatively, you can choose to configure an entire fleet, which is a logical group of clusters that lets you enable functionality and update configuration across these clusters.
- 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.