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 gcloud CLI to call the Kubernetes API server
You run the gcloud anthos auth login command to authenticate with your
clusters, and as a result, your request goes to the Kubernetes API server.
For this to work, your OIDC ID tokens must be stored in the
kubeconfig file.
Google Distributed Cloud uses the gcloud CLI of Google Cloud CLI to request and
obtain the ID token and other OIDC values in the kubeconfig file.
The Kubernetes API server and the ID token
After authenticated with the cluster, you can interact using the kubectl CLI
of gcloud CLI. 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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eGoogle Distributed Cloud utilizes OpenID Connect (OIDC) for command-line authentication against user clusters, offering flexibility in managing user access.\u003c/p\u003e\n"],["\u003cp\u003eUsers can authenticate with clusters using the \u003ccode\u003egcloud anthos auth login\u003c/code\u003e command, which interacts with the Kubernetes API server to verify OIDC ID tokens.\u003c/p\u003e\n"],["\u003cp\u003eThe Kubernetes API server verifies user ID tokens using the OpenID provider's certificate and determines authorization based on the user's security groups and the cluster's role-based access control (RBAC) policy.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Distributed Cloud supports multiple OIDC providers, including Active Directory Federation Services (ADFS) or third parties like Google, Microsoft, Facebook, and Twitter.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Cloud console can also be used to log in to clusters, by utilizing a Kubernetes service account's bearer token.\u003c/p\u003e\n"]]],[],null,["# Authentication\n\nGoogle Distributed Cloud supports OpenID Connect (OIDC) for authenticating\nagainst user clusters using the command line. See the following topics:\n\n- [Authenticating with OIDC](/anthos/clusters/docs/on-prem/1.8/how-to/oidc)\n- [Authenticating with OIDC and ADFS](/anthos/clusters/docs/on-prem/1.8/how-to/oidc-adfs)\n- [Authenticating with OIDC and\n Google](/anthos/clusters/docs/on-prem/1.8/how-to/oidc-google)\n\nTo log in via Google Cloud console, Google Distributed Cloud supports using a\nKubernetes service account's bearer token. See [Logging in to a cluster from\nGoogle Cloud console](/anthos/multicluster-management/console/logging-in).\n\nThis topic assumes are you familiar with\n[OAuth 2.0](https://oauth.net/2/) and\n[OpenID Connect](https://openid.net/connect/).\nYou should also be familiar with\n[scopes](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims)\nand\n[claims](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)\nin the context of OpenID authentication.\n\nOverview\n--------\n\nWith OIDC, you can manage access to a Kubernetes cluster by using the standard\nprocedures in your organization for creating, enabling, and disabling employee\naccounts. You can also use your organization's security groups to configure\naccess to a Kubernetes cluster or to specific services in the cluster.\n\n- A user signs in to an OpenID provider by presenting a username and\n password.\n\n- The OpenID provider issues an ID token for the user. The token is signed\n by the provider.\n\n- An application, acting on behalf of the user, sends an HTTPS request to the\n Kubernetes API server. The application includes the user's ID token in the\n request header.\n\n- The Kubernetes API server verifies the token by using the provider's\n certificate.\n\nIf your enterprise runs an\n[Active Directory Federation Services (ADFS)](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services)\nserver, the ADFS server could serve as your OpenID provider. Another option is\nto use a third party as your OpenID provider, For example, Google, Microsoft,\nFacebook, and Twitter are all OpenID providers.\n\nUsing the gcloud CLI to call the Kubernetes API server\n------------------------------------------------------\n\nYou run the `gcloud anthos auth login` command to authenticate with your\nclusters, and as a result, your request goes to the Kubernetes API server.\n\nFor this to work, your OIDC ID tokens must be stored in the\n[`kubeconfig` file](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).\nGoogle Distributed Cloud uses the gcloud CLI of Google Cloud CLI to request and\nobtain the ID token and other OIDC values in the `kubeconfig` file.\n\nThe Kubernetes API server and the ID token\n------------------------------------------\n\nAfter authenticated with the cluster, you can interact using the `kubectl` CLI\nof gcloud CLI. When `kubectl` calls the Kubernetes API server on behalf\nof the user, the API server verifies the token by using the OpenID provider's\npublic certificate. Then the API server parses the token to learn the user's\nidentity and the user's security groups.\n\nThe API server determines whether the user is authorized to make this particular\ncall by comparing the user's security groups to the cluster's\n[role-based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)\n(RBAC) policy."]]