Project: Pinniped (Provisioning / Key Management)
File: configure-supervisor-with-okta.md

title: Configure the Pinniped Supervisor to use Okta as an OIDC provider description: Set up the Pinniped Supervisor to use Okta login. cascade: layout: docs menu: docs: name: With Okta OIDC weight: 80 parent: howto-configure-supervisor aliases: /docs/howto/configure-supervisor-with-okta/ The Supervisor is an issuer that supports connecting "upstream" identity providers to many "downstream" cluster clients. This guide shows you how to configure the Supervisor so that users can authenticate to their Kubernetes cluster using their Okta credentials. This how-to guide assumes that you have already with working ingress, and that you have . Follow the instructions for and create an app. Optionally follow the instructions for if you want to pass users' Okta group information through to your Kubernetes clusters. For example, to create an app: In the Okta Admin Console, navigate to Applications > Applications. Create a new app: Click `Create App Integration`. For `Sign-on method`, select `OIDC`. For `Application type`, app `Web Application`, then click next. Only if you would like to offer the password grant flow to your end users, then choose `Native Application` instead. Enter a name for your app, such as "My Kubernetes Clusters". If you chose to create a `Web Application` then in the General Settings section, choose Grant Types `Authorization Code` and `Refresh Token`. If you chose `Native Application` then in the General Settings section, choose Grant Types `Authorization Code`, `Refresh Token`, and `Resource Owner Password`. Enter the sign-in redirect URI. This is the `spec.issuer` you configured in your `FederationDomain` appended with `/callback`. Optionally select `Limit access to selected groups` to restrict which Okta users can log in to Kubernetes using this integration. Save the app and make note of the Client ID and Client secret. If you chose to create a `Native Application` then there is an extra step required to get a client secret: after saving the app, in the Client Credentials section click `Edit`, choose `Use Client Authentication`, and click `Save`. Navigate to the Sign On tab > OpenID Connect ID Token and click `Edit`. Fill in the Groups claim filter. For example, for all groups to be present under the claim name `groups`, fill in "groups" in the first box, then select "Matches regex" and ".*". Create an in the same namespace as the Supervisor. For example, this OIDCIdentityProvider and corresponding Secret use Okta's `email` claim as the Kubernetes username: ```yaml apiVersion: idp.supervisor.pinniped.dev/v1alpha1 kind: OIDCIdentityProvider metadata: namespace: pinniped-supervisor name: okta spec: issuer: https://my-company.okta.com authorizationConfig: additionalScopes: [offline_access, groups, email] allowPasswordGrant: false claims: username: email groups: groups client: secretName: okta-client-credentials apiVersion: v1 kind: Secret metadata: namespace: pinniped-supervisor name: okta-client-credentials type: secrets.pinniped.dev/oidc-client stringData: clientID: "<your-client-id>" clientSecret: "<your-client-secret>" ``` Note that the `metadata.name` of the OIDCIdentityProvider resource may be visible to end users at login prompts if you choose to enable `allowPasswordGrant`, so choose a name which will be understood by your end users. For example, if you work at Acme Corp, choose something like `acme-corporate-okta` over `my-idp`. Once your OIDCIdentityProvider has been created, you can validate your configuration by running: ```shell kubectl describe OIDCIdentityProvider -n pinniped-supervisor okta ``` Look at the `status` field. If it was configured correctly, you should see `phase: Ready`. Next, ! Then you'll be able to log into those clusters as any of the users from the Okta directory.