Configure GitHub Identity Provider

Configure GitHub as an identity provider and grant access to DKP.

Authorize Access to Your Clusters using your GitHub Account

DKP allows configuring access to the UI with GitHub credentials, but it must be configured in the dashboard. To ensure every developer in your GitHub organization has access to your Kubernetes clusters using their GitHub credentials, you will add that option for log in by adding an Identity Provider with information from your GitHub profile in the OAuth application settings.

Add Identity Provider

To authorize all developers to have access to your clusters using their GitHub credentials, follow these steps to set up GitHub as an identity provider log in option:

1. Start by creating a new OAuth Application in our GitHub Organization by filling out this form. Use your cluster URL in the HomePage URL field.

Important: Use your cluster URL followed by /dex/callback as the Authorization callback URL by adding to the end of your URL.

2. After you create the application, you will be taken to a settings page. You will need the Client ID and Client Secret from this page for the DKP UI. If you do not already have a Client Secret for the application, select the Generate a new client secret button.

3. Log in to your DKP UI, and from the top menu bar, select the Global workspace.

4. Select Identity Providers in the Administration section of the sidebar menu.

5. Select the Identity Providers tab, and then select the + Add Identity Provider button.

6. Ensure GitHub is selected as the identity provider type, and select the target workspace.

7. Copy the Client ID and Client Secret values from GitHub into this form.

8. Select the checkbox next to Load All Groups. Checking the Load All Groups checkbox configures dex to load all groups configured in the users GitHub identity. This allows you to configure group-specific access to DKP and Kubernetes resources.

Do not select the checkbox for Enable Device Flow before selecting <Register the Application> button.

9. Select Save to create your Identity Provider.

Map the Identity Provider Groups to the Kubernetes Groups

1. In the DKP UI, select the Groups tab from the Identity Provider screen, and then select the Create Group button.

2. Give your group a descriptive name in the Enter Name box.
   

   

   The syntax for the Identity Provider groups you add to a DKP Group varies depending on the context for which you have established an Identity Provider.

   • If you have set up an identity provider globally, for All Workspaces:

     • For groups: Add an Identity Provider Group in the oidc:<IdP_user_group> format. For example, oidc:engineering.

     • For users: Add an Identity Provider User in the <user_email>. For example, jane.doe@example.com.

   • If you have set up an identity provider for a Specific Workspace:

     • For groups: Add an Identity Provider Group in the oidc:<workspace_name>:<IdP_user_group> format. For example, oidc:tenant-z:engineering.

     • For users: Add an Identity Provider User in the <workspace_ID>:<user_email> format. For example, tenant-z:jane.doe@example.com.

       Run kubectl get workspaces to obtain a list of all existing workspaces. The workspace_ID is listed under the NAME column.

3. Add the groups/teams from your GitHub provider under Identity Provider Groups. For more information on finding the teams to which you are assigned in GitHub, refer to the GitHub Documentation for GitHub Teams.

4. Click Save to create the group, which creates it on the management cluster and federates it to all target clusters.

Assign the Role to the Developers Group

Now that you have a Group defined, you can bind one or more Roles to this Group. In the following example, we show how to bind the group to the View Only role.

1. In the DKP UI, select Global, or the target workspace from the top menu bar.

2. Select the Cluster Role Bindings tab, and then select the Add roles button for your group.

3. Select View Only role from the Roles drop-down and select <Save>.

4. Follow the example in the Granting Access to Kubernetes and Kommander Resources to grant users access to Kommander paths on your cluster. At a minimum, add a read only path for access to all the Kommander Dashboard views:

When you check your attached clusters and login as a user from your matched groups, you can see every resource, but neither delete or edit them, as intended.

Future Log In

The first login will require you to authorize the GitHub account, so the administrator of the cluster will select <Authorize github-username> button on the page that follows the login. After setting up GitHub authorization, future login screens will have that as an option: <Log in with github-auth> button.