How to Configure Single Sign-On for Kubernetes Clusterspublic

For each DigitalOcean role you want to use with your DOKS cluster, create an Auth0 role. Set the name of the role to the DigitalOcean role name prefixed with DO: (for example, DO:Owner or DO:My Custom Role). This prefix ensures roles associated with DigitalOcean do not conflict with other roles in your IdP.

Assign users to the newly created roles.

For each DigitalOcean role you want to use with your DOKS cluster, create a group. Set the name of the group to the DigitalOcean role name prefixed with DO: (for example, DO:Owner or DO:My Custom Role). This prefix ensures groups associated with DigitalOcean do not conflict with other groups in your IdP.

Assign users to the newly created groups.

For each DigitalOcean role you want to use with your DOKS cluster, create a group with the same name as the role. Assign users to the newly created groups.

Create a new realm or select your existing realm for your organization.

Create a group for each DigitalOcean role you want to use with your DOKS cluster. The name of the group can be arbitrary. To map the group to a DigitalOcean role, open the Attributes tab for the group and add an attribute with the key team_role and a value that exactly matches the DigitalOcean role name (for example, Owner, Modifier, or My Custom Role).

For each DigitalOcean role you want to use with your DOKS cluster, create a group. Set the name of the group to the DigitalOcean role name prefixed with DO: (for example, DO:Owner or DO:My Custom Role). This prefix ensures groups associated with DigitalOcean do not conflict with other groups in your IdP.

Assign users to the newly created groups.

Create an application of type Single Page Application. This application type does not require clients to present a client secret and uses PKCE to enhance security.

In the Settings tab, add http://localhost:8080/callback to Allowed Callback URLs. This allows the doctl DOKS authentication command to complete the authorization flow locally.

Create a new application and provider pair. Set the provider type to OAuth2/OpenID, choose the explicit authorization flow, and set the client type to Public. With this configuration, clients do not present a client secret and use PKCE to enhance security.

Add http://localhost:8080/callback to the allowed redirect URIs so the doctl DOKS authentication command can complete the authorization flow locally.

Create an application with the following settings:

• Select Custom Application as the type.
• Under features, choose Manage Single Sign-On (SSO) with Configure SSO with OIDC.

On the SSO tab for your new application:

• Choose Public as the client authentication type. Clients do not present a client secret and use PKCE to enhance security.
• Set the redirect URL to http://localhost:8080/callback so the doctl DOKS authentication command can complete the authorization flow locally.
• Set the login URL to http://localhost:8080/login.

On the User Groups tab, assign the application to every group that should have access to DOKS clusters.

Create a new client in the same realm where you created groups. Use the following settings:

• Client type: OpenID Connect
• Client ID: any descriptive string

Keep Client authentication disabled so clients do not present a client secret and use PKCE to enhance security.

Keep Standard flow and Direct access grants enabled for the authentication flow.

Add http://localhost:8080/callback to the allowed redirect URIs so the doctl DOKS authentication command can complete the authorization flow locally.

Create an app integration with the following settings:

• For the sign-in method, choose OIDC - OpenID Connect.
• For the application type, choose Single-Page Application. This type does not require clients to present a client secret and uses PKCE to enhance security.
• Set Sign-in redirect URIs to http://localhost:8080/callback so the doctl DOKS authentication command can complete the authorization flow locally.
• Under Assignments, set Controlled access to Skip group assignment for now.

Open the Assignments tab for your DigitalOcean SSO app, choose Assign, then Assign to Groups, and assign the DO:-prefixed groups you created earlier.

Create a custom post-login action named DigitalOcean Role Mapping. You might already have this action if you set up SSO for DigitalOcean Control Panel, in which case you may skip this step.

When you create the action, select Login/Post Login as the trigger. Use the following code to map only Auth0 roles whose names start with DO: into the team_role custom claim, with the prefix removed, in the ID token response:

exports.onExecutePostLogin = async (event, api) => {
  const roles = event.authorization?.roles || [];
  api.idToken.setCustomClaim(
    'team_role',
    roles.filter((role) => role.startsWith('DO:')).map((role) => role.slice('DO:'.length))
  );
};

Attach the action to the login flow. Drag your action between Start and Complete, then save the flow.

Create a custom property mapping of type Scope Mapping. The name can be arbitrary. Set Scope name to team_role and use the following expression:

do_roles = [group.name[3:] for group in request.user.ak_groups.all() if group.name and group.name[:3] == "DO:"]
return {"team_role": do_roles}

This expression selects only the groups associated with DigitalOcean and returns them under the team_role custom claim.

Open the provider for your application and choose Edit. Under Advanced protocol settings, open the Scopes section and add the new custom mapping to Selected scopes. Do not remove the default selected scopes.

On the SSO tab in the application settings, open the Attribute Mapping section, select Include Group Attribute, and set team_role as the name. The groups in this claim are not limited to DigitalOcean roles and include all of the user’s groups.

Go to Client scopes and create a new scope named team_role. Turn Include in token scope on. After the scope is created, open the Mappers tab for this scope and add a mapper of type User attribute with these settings:

• Name: team_role
• User attribute: team_role
• Token claim name: team_role

Turn the following options on:

• Add to ID token
• Multivalued
• Aggregate attribute values

Then open the client you created for DOKS, go to the Client scopes tab, and add the scope you created as an optional client scope.

In the app you created in the previous step, open the Sign On tab. Add a token claims expression with name team_role and the following expression:

user.getGroups({'group.profile.name': 'DO:.*'}).![profile.name.replaceFirst('DO:', '')]

This expression removes the DO: substring from matching group names and returns the result as the team_role claim.

On the application overview page, find the Domain and Client ID for your app. Build the issuer URL by prefixing the domain with https:// and appending a trailing /, for example https://your_tenant.auth0.com/.

You can find the client ID and issuer URL on the overview page for your application’s provider.

Copy the client ID from the application page (SSO tab).

Find the issuer URL for your geographic zone in JumpCloud’s OIDC SSO documentation.

Open Realm settings and click OpenID Endpoint Configuration at the bottom of the page. The output contains your issuer URL.

You can find the client ID on the Settings tab of the client you created for DOKS.

You can find the client ID on the general overview page for your application.

The issuer URL is your Okta domain prefixed with https://, for example https://your_application.okta.com. Find your Okta domain by clicking your username in the upper-right corner of the Admin Console.