Welcome to Part 3 of the TMc Self-Managed series. Part 1 concentrated on a general introduction to TMC Self-Managed, while Part 2 dived into the DNS configuration. You may read the previous entries in this series if you missed them by clicking the links below.

1: TMC Self-Managed – Introduction & Architecture

2: Configure DNS for TMC Self-Managed

Tanzu Mission Control Self-Managed manages user authentication using Pinniped Supervisor as the identity broker and requires an existing OIDC-compliant identity provider (IDP). Examples of OIDC-compliant IDPs are Okta, Keycloak, VMware Workspace One, etc. The Pinniped Supervisor expects the Issuer URL, client ID, and client secret to integrate with your IDP.

Note: This post demonstrates configuring Okta as an IDP. Although Okta is a SaaS service and is reachable over the internet, the intent is to show how you configure upstream IDP for authentication. In an airgap environment, you may use any IDP that doesn’t require an internet connection.

To enable integration with Pinniped Supervisor, configure the following in your IDP.

Step 1: Create Groups

TMC Self-Managed requires 2 groups: tmc:admin and tmc:member in your IDP. 

Groups can be created in Okta by navigating to Home > Directory > Groups > Add Group

Step 2: Create and Add Users

Add a user to the tmc:admin group. To complete the onboarding, the user that first logs in to Tanzu Mission Control Self-Managed must be a member of the tmc:admin group. 

Note: If the user doesn’t exist, you must first create the user by navigating to Home > Directory > People and clicking Add Person.

To add a user to the group, click on the newly created tmc:admin group, click on the Assign people button, choose the user from the list, and then assign the user to the group.

Step 3: Create an OIDC Client Application

The client application must have the following properties:

• Sign-in method as OIDC – OpenID Connect.
• (optional) Should support the resource-owner password flow where users can exchange their username and password for the OIDC tokens.
• Should use client secret as the client authentication method. This is what will generate a client secret for this app and it is this client secret that will be used in the TMC Self-Managed configuration file used during installation.
• Should require PKCE as additional verification.
• Should have the following grant types:
  • authorization code
  • refresh token
  • resource owner password (optional as noted above)
• Should use sign-in redirect URI: https://pinniped-supervisor.<my-tmc-dns-zone>/provider/pinniped/callback
• Should limit access to this application by selecting appropriate entities (users or groups) in your IDP.

Note: The resource owner password grant type is necessary only if you want to login with the CLI using a username and password. If this grant is not included, the TMC CLI will require a browser to complete the login.

To create an application in Okta, navigate to Home > Applications and click on the Create App Integration button.

Create the application of type Native and set the Sign-in method to OIDC.

Provide the app integration name and select the Grant type as discussed in the OIDC application properties section. Also, configure the Sign-in redirect URIs.

Note: You can leave Sign-out redirect URIs blank.

Under the Assignments tab, limit application access to the tmc:admin & tmc:member groups.

The application creates a Client ID after you click the Save button. Keep a note of this ID because you’ll need it to install TMC Self-Managed later.

To create a new client secret, edit the client credentials, change the client authentication setting to Client secret, and then click the Save button.

Make a note of the client secret generated by the application.

Additionally configure the following settings for the application (if not configured automatically).

Under the Okta API Scopes tab, ensure that the following rights are granted.

• Okta.groups.read
• okta.userTypes.read
• okta.users.read

Note: To assign the grants, you need to click on the ‘Any’ tab and click on the Grant option.

The last configuration piece is to add an Auth server claim by navigating to Security > API and editing the default authorization server. Under the claims tab, add the following claims.

And that’s it for this post. In the next post, I will walk through configuring Cluster Issuer for automatic certificate generation for cert-manager.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.