Configure OIDC providers for GKE Identity Service

Microsoft AD FS

Use a set of AD FS management wizards to configure your AD FS server and AD user database.

1. Open the AD FS management pane.

2. Select Application Groups > Actions > Add an Application Group.

3. Select Server Application. Enter a name and description of your choice. Click Next.

4. Enter your two redirect URLs, as specified above. You are given a client ID. This is how the AD FS server identifies GKE Identity Service. Save the client ID for later.

5. Select Generate a shared secret. GKE Identity Service uses this secret to authenticate to the AD FS server. Save the secret for later.

Configuring security groups (optional)

1. In AD FS management, select Relying party trusts > Add a new relying party trust.

2. Select Claims aware, and click Start.

3. Select Enter data about relying party manually.

4. Enter a display name.

5. Skip the next two steps.

6. Enter a Relying party trust identifier. Suggestion: token-groups-claim.

7. 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.

8. Click Finish.

Mapping LDAP attributes to claim names

1. In AD FS management, select Relying party trusts > Edit claim issuance policy.

2. Select Send LDAP Attributes as Claims, and click Next.

3. For Claim rule name, enter groups.

4. For Attribute store, select Active Directory.

5. 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

6. For Outgoing Claim Type, select:

   • AD FS version 5.0 and later: Group
   • AD FS versions before 5.0: groups

7. Click Finish, and click Apply.

Registering GKE 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"

Replace the following:

• [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 token-groups-claim.

Azure AD

Register an OAuth client with Azure

To register an OAuth client with Azure, complete the steps at the following links:

1. If you haven't done so already, Set up a tenant on Azure Active Directory.

2. Register an application with the Microsoft identity platform.

3. Open the App registrations page on the Azure Portal and select your application by name.

4. Create a Client Secret.

   1. Click Add a certificate or secret under Essentials. A list of certificates and a list of secrets appears.

   2. Click New client secret. Name your secret and click Add.

   3. 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.

5. Add redirect URIs.

   1. Return to the application page.

   2. Select Add a Redirect URI under Essentials. The Authentication page appears.

   3. Choose Add a platform, and panel named Configure platforms appears on the right.

   4. Choose Web. Under Redirect URIs, enter http://localhost:PORT/callback for the gcloud CLI login flow. Pick a PORT greater than 1024. Click the Configure button.

   5. Click the Add URI button to add another URI, https://console.cloud.google.com/kubernetes/oidc, for the Google Cloud console login.

   6. 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:

• Issuer URI: https://login.microsoftonline.com/TENANT_ID/v2.0. The tenant ID is displayed as the Directory (tenant) ID on the Application page on Azure portal.

• Client ID: The client ID is displayed as the Application (client) ID on 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 GKE clusters (both VMware and bare metal): From GKE Enterprise 1.14
• Anthos clusters on AWS: From GKE Enterprise 1.14 (Kubernetes version of 1.25 or later)
• Anthos clusters on Azure: From GKE Enterprise 1.14 (Kubernetes version of 1.25 or later)
• Anthos clusters on AWS (previous generation): From GKE Enterprise 1.14

Before you begin, make sure that each user has an associated email address configured as their identifier in Azure AD. GKE 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 GKE Identity Service plugin access the Microsoft Graph API endpoints from which group information is fetched. Without this step, GKE 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.

1. Sign in to the Azure portal.
2. 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.
3. Select Azure Active Directory - App registrations, and then select your client application.
4. Select API permissions - Add a permission - Microsoft Graph - Delegated permissions.
5. Under the Group tab, check Group.Read.All. Under the User tab, check User.Read.All.
6. Click Add permissions to complete the process.
7. 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.