Configure OIDC providers for Anthos Identity Service
This document explains how to configure your chosen OpenID Connect (OIDC) identity provider for Anthos Identity Service. To find out more about Anthos Identity Service, see the overview.
This document is for platform administrators, or whoever manages identity setup in your organization. If you are a cluster administrator or application operator, ask your platform administrator to follow this section before you start Configure your clusters for fleet-level Anthos Identity Service or Configure clusters for Anthos Identity Service with OIDC.
Register Anthos Identity Service with your provider
Anthos Identity Service setup requires a single client ID and secret from your identity provider. This ID and secret are used by Anthos Identity Service when connecting to the provider as part of the authentication flow for users. To get these, you need to register Anthos Identity Service with your provider as a client application, following the usual procedure for your chosen provider. You can find some specific registration details for popular providers in the next section.
For redirect URLs, specify the following values:
https://console.cloud.google.com/kubernetes/oidcis the redirect URL for the Google Cloud console
http://localhost:PORT/callbackis the redirect URL for the gcloud CLI. You can specify any port number above 1024.
Save the client ID and secret you get from registration to give to cluster administrators who need to set up Anthos Identity Service.
Provider setup information
This section provides additional provider-specific information for registering Anthos Identity Service. If your provider is listed here, register Anthos Identity Service with your provider as a client application using the following instructions.
Microsoft AD FS
Use a set of AD FS management wizards to configure your AD FS server and AD user database.
Open the AD FS management pane.
Select Application Groups > Actions > Add an Application Group.
Select Server Application. Enter a name and description of your choice. Click Next.
Enter your two redirect URLs, as specified above. You are given a client ID. This is how the AD FS server identifies Anthos Identity Service. Save the client ID for later.
Select Generate a shared secret. Anthos Identity Service uses this secret to authenticate to the AD FS server. Save the secret for later.
Configuring security groups (optional)
In AD FS management, select Relying party trusts > Add a new relying party trust.
Select Claims aware, and click Start.
Select Enter data about relying party manually.
Enter a display name.
Skip the next two steps.
Enter a Relying party trust identifier. Suggestion:
For Access control policy, select Permit everyone. This means that all users share their security group information with the gcloud CLI and Google Cloud console.
Mapping LDAP attributes to claim names
In AD FS management, select Relying party trusts > Edit claim issuance policy.
Select Send LDAP Attributes as Claims, and click Next.
For Claim rule name, enter
For Attribute store, select Active Directory.
In the table, for LDAP Attribute, select:
- AD FS version 5.0 and later: Token-Groups Qualified by Domain name
- AD FS versions before 5.0: Token Groups - Qualified Names
For Outgoing Claim Type, select:
- AD FS version 5.0 and later: Group
- AD FS versions before 5.0: groups
Click Finish, and click Apply.
Registering Anthos Identity Service with AD FS
Open a PowerShell window in Administrator mode, and enter this command:
Grant-AD FSApplicationPermission ` -ClientRoleIdentifier "[CLIENT_ID]" ` -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] ` -ScopeName "allatclaims", "openid"
[CLIENT_ID] is the client ID that you obtained previously.
[SERVER_ROLE_IDENTIFIER] is the claim identifier you entered previously. Recall that the suggested identifier was
Register an OAuth client with Azure
To register an OAuth client with Azure, complete the steps at the following links:
If you haven't done so already, Set up a tenant on Azure Active Directory.
Register an application with the Microsoft identity platform.
Open the App registrations page on the Azure Portal and select your application by name.
Create a Client Secret.
Click Add a certificate or secret under Essentials. A list of certificates and a list of secrets appears.
Click New client secret. Name your secret and click Add.
Save the Value* of the secret in a secure location. You will not be able to retrieve it after you close or refresh the page.
Add redirect URIs.
Return to the application page.
Select Add a Redirect URI under Essentials. The Authentication page appears.
Choose Add a platform, and panel named Configure platforms appears on the right.
Choose Web. Under Redirect URIs, enter
http://localhost:PORT/callbackfor the gcloud CLI login flow. Pick a PORT greater than 1024. Click the Configure button.
Click the Add URI button to add another URI,
https://console.cloud.google.com/kubernetes/oidc, for the Google Cloud console login.
Click the Save button on the top.
Now your client registration is complete. You should have the following info to share with your cluster administrator:
https://login.microsoftonline.com/TENANT_ID/v2.0. The tenant ID is displayed as the
Directory (tenant) IDon the Application page on Azure portal.
Client ID: The client ID is displayed as the
Application (client) IDon the Application page on Azure portal.
Client Secret: You were given this in the last step. You won't be able to retrieve this if you close the page upon secret creation. Make sure to save the value in a secure location (or generate a new secret if you lose track of the previous one).
Advanced setup for Azure AD
Consider using this advanced setup only when you want to set up clusters with Azure AD group-based authorization policies where users of the clusters belong to more than 200 Azure AD groups. The advanced setup for Azure AD supports the following platforms:
- On-premises Anthos clusters (both VMware and bare metal): From Anthos 1.14
- Anthos clusters on AWS: From Anthos 1.14 (Kubernetes version of 1.25 or later)
- Anthos clusters on Azure: From Anthos 1.14 (Kubernetes version of 1.25 or later)
- Anthos clusters on AWS (previous generation): From Anthos 1.14
Before you begin, make sure that each user has an associated email address configured as their identifier in Azure AD. Anthos Identity Service uses the user's email to assert the user's identity and authenticate the request.
You need to ensure that the client you registered in the previous section has delegated permissions to get user and group information from the Microsoft Graph API. These permissions let the Anthos Identity Service plugin access the Microsoft Graph API endpoints from which group information is fetched. Without this step, Anthos Identity Service cannot list the user’s groups, and RBAC authorization policies based on groups will not work as expected.
You need to have global admin or organization admin permissions to perform this setup step.
- Sign in to the Azure portal.
- If you have access to multiple tenants, use the Directory + subscription filter in the top menu to select the tenant containing your client app's registration.
- Select Azure Active Directory - App registrations, and then select your client application.
- Select API permissions - Add a permission - Microsoft Graph - Delegated permissions.
- Under the Group tab, check Group.Read.All. Under the User tab, check User.Read.All.
- Click Add permissions to complete the process.
- Grant consent on behalf of all users by clicking the Grant admin consent for... button. You can find more about granting admin consent in More on API permissions and admin consent.
Share provider details
Ensure the cluster administrator has the following required information for cluster configuration:
- The provider's issuer URI
- The client secret
- The client ID
- The redirect URI and port you specified for the gcloud CLI
- The user name field (claim) that your provider uses to identify users in its tokens (the assumed default when configuring clusters is
- The group name field (claim) that your provider uses to return security groups, if any.
- Any additional scopes or parameters that are specific to your provider, as described in the previous section. For example, if your authorization server prompts for consent for authentication with Microsoft Azure and Okta, the cluster admin needs to specify
prompt=consentas a parameter. If you have configured ADFS to provide security group information, the relevant additional parameter is
resource=token-groups-claim(or whatever you chose as your relying party trust identifier).
- (Optional) If your provider is not using a certificate signed by a public certificate authority (for example if you are using self-signed certificates), then you will need a certificate (or certificate chain) of the identity provider. The certificate (or certificate chain) needs to contain the root certificate at a minimum (partial chains are accepted, as long as the chain is contiguous back to the root certificate). When providing this value in ClientConfig, it needs to be formatted as a base64 encoded string. To create the string, concatenate the complete PEM-encoded certificate(s) into a single string and then base64 encode it.
You can see a complete list of Anthos Identity Service configuration parameters in Configure clusters.