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-08-29 UTC."],[[["\u003cp\u003eGoogle Distributed Cloud utilizes OpenID Connect (OIDC) for command-line authentication against user clusters, simplifying access management through standard organizational procedures for managing employee accounts.\u003c/p\u003e\n"],["\u003cp\u003eUsers can sign in to an OpenID provider, receiving a signed ID token that is then used by applications to authenticate with the Kubernetes API server.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Distributed Cloud supports Active Directory Federation Services (ADFS) or third-party providers like Google, Microsoft, Facebook, and Twitter as OpenID providers.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003egcloud anthos auth login\u003c/code\u003e command is used to authenticate with clusters, with OIDC ID tokens stored in the \u003ccode\u003ekubeconfig\u003c/code\u003e file, enabling \u003ccode\u003ekubectl\u003c/code\u003e to interact with the Kubernetes API server.\u003c/p\u003e\n"],["\u003cp\u003eThe Kubernetes API server validates tokens using the OpenID provider's certificate and checks user permissions against the cluster's role-based access control (RBAC) policy.\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.7/how-to/oidc)\n- [Authenticating with OIDC and ADFS](/anthos/clusters/docs/on-prem/1.7/how-to/oidc-adfs)\n- [Authenticating with OIDC and\n Google](/anthos/clusters/docs/on-prem/1.7/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."]]