Step 1: Configure an Identity Management Provider in the Cluster ¶

The first step is to configure an OIDC provider ( VMware Cloud Service Portal (CSP) login in this example) in the VMware Tanzu™ Kubernetes Grid™ (TKG) cluster and configure Pinniped to trust this provider for authenticating Kubernetes API calls.

Step 1.1: Configure an OIDC Provider ¶

TKG comes with Pinniped installed by default; you only need to configure an OIDC provider and then make Pinniped trust that OIDC provider. The OIDC provider is responsible for authenticating users in the TKG cluster and the Kubeapps dashboard. The steps below use the VMware Cloud Services Platform (CSP) as an example; however, a similar process applies to any other OIDC-compliant provider, including Google Cloud, Azure Active Directory, Dex, Okta, and others.

NOTE: You need a recent version of Kubeapps (2.3.3 onwards), otherwise, you would need to install an additional Pinniped (version 0.6.0 onwards).

NOTE: If your cluster is already attached to VMware Tanzu™ Mission Control™ (TMC) an additional Pinniped version is automatically installed in another namespace. However, this guide always uses the Pinniped version installed by TKG (not by TMC).

Create an OAuth2 Application ¶

Begin by creating an OAuth2 application to retrieve the information required by Pinniped and, later on, Kubeapps. Follow the steps below:

NOTE: You must have Developer access in the organization to perform these steps. Also, note that if the organization is restricted, only users belonging to this organization are able to log in.

  1. Navigate to the CSP Console at https://console.cloud.vmware.com .

  2. Click the drop-down menu in the top-right corner.

  3. Under the Organization settings, click View Organization.

    View organization

  4. Click the OAuth Apps tab.

    OAuth Apps tab

  5. Select Web app and click the Continue button.

    OAuth Apps tab

  6. Enter a name and description for the OAuth app. For the moment, enter the value https://localhost/oauth2/callback in the Redirect URIs field (this will be updated after Kubeapps is installed).

    Add name and description

  7. Leave the rest of the options at their default values.

  8. Tick the OpenID checkbox and click the Create button.

    OpenID and create

    The CSP Console displays a success screen with an auto-generated application ID and secret. Click the Download JSON link to download these values.

Retrieve app id and secret

NOTE: Store this file carefully as it contains important credentials which are needed when configuring Pinniped and Kubeapps.

TIP: Any OIDC-compliant provider should expose a .well-known/openid-configuration ( example ) endpoint where you can find other useful and required information. This endpoint allows using the base URL to discover the rest of the URLs (authorization, token, end session, jwks and issuer) automatically. For CSP, the endpoint is https://console.cloud.vmware.com/csp/gateway/am/api.

At this point, an OAuth2 application is configured.

Configure Pinniped to Trust the OIDC Provider ¶

Once the OIDC provider has been fully configured, the next step is to configure Pinniped to trust this provider. This implies that a successful authentication with the OIDC provider results in authentication with the TKG cluster.

Since Pinniped manages this process, the only requirement is to have a JWTAuthenticator CustomResource in the cluster. To do so, follow the steps below:

  1. Create a file named kubeapps-jwt-authenticator.yaml with the following content. Replace the placeholders as follows:

    • Replace the OIDC-ISSUER-URL with the issuer URL of the OIDC provider. For CSP it is https://gaz.csp-vidm-prod.com.
    • Replace CLIENT-ID with the application ID obtained from the JSON file in the previous step.
    ---
    apiVersion: authentication.concierge.pinniped.dev/v1alpha1
    kind: JWTAuthenticator
    metadata:
    name: kubeapps-jwt-authenticator
    namespace: pinniped-concierge
    spec:
    issuer: OIDC-ISSUER-URL
    audience: CLIENT-ID
    claims:
       username: email
       groups: groups
    #   tls:
    #     certificateAuthorityData: LS0t... # optional base64 CA data if using a self-signed certificate
    

    The name field specifies the name of the JWTAuthenticator resource, which is required in the next step.

    NOTE: Ignore the tls section of the configuration shown above unless the OIDC uses a self-signed certificate. If it does, follow these additional steps .

    NOTE: Just if you are using the Pinniped version provided by TMC (instead of the one already provided by TKG), the line namespace: pinniped-concierge must be removed.

  2. Install the JWTAuthenticator resource in your cluster:

    kubectl apply -f kubeapps-jwt-authenticator.yaml
    

    TIP: When using more than one workload cluster, apply this JWTAuthenticator resource in every cluster.

    At the end of this step, an identity management provider has been configured in the cluster. The next step is to install Kubeapps .

Tutorial index ¶

  1. Step 1: Configure an Identity Management Provider in the Cluster
  2. Step 2: Configure and Install Kubeapps
  3. Step 3: Add Application Repositories to Kubeapps
  4. Step 4: Deploy and Manage Applications with Kubeapps