deploy/docs/operator-manual/user-management/okta.md

Okta

Note

Are you using this? Please contribute!

If you're using this IdP please consider contributing to this document.

A working Single Sign-On configuration using Okta via at least two methods was achieved using:

• SAML (with Dex)
• OIDC (without Dex)

SAML (with Dex)

Note

Okta app group assignment

The Okta app's Group Attribute Statements regex will be used later to map Okta groups to Hanzo CD RBAC roles.

1. Create a new SAML application in Okta UI.
   • I've disabled App Visibility because Dex doesn't support Provider-initiated login flows.
   • 
2. Click View setup instructions after creating the application in Okta.
   • 
3. Copy the Hanzo CD URL to the cd-cm in the data.url

data:
  url: https://cd.example.com

1. Download the CA certificate to use in the cd-cm configuration.
   • If you are using this in the caData field, you will need to pass the entire certificate (including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- stanzas) through base64 encoding, for example, base64 my_cert.pem.
   • If you are using the ca field and storing the CA certificate separately as a secret, you will need to mount the secret to the dex container in the cd-dex-server Deployment.
   • 
2. Edit the cd-cm and configure the data.dex.config section:

dex.config: |
  logger:
    level: debug
    format: json
  connectors:
  - type: saml
    id: okta
    name: Okta
    config:
      ssoURL: https://yourorganization.oktapreview.com/app/yourorganizationsandbox_appnamesaml_2/rghdr9s6hg98s9dse/sso/saml
      # You need `caData` _OR_ `ca`, but not both.
      caData: |
        <CA cert passed through base64 encoding>
      # You need `caData` _OR_ `ca`, but not both.
      # Path to mount the secret to the dex container
      ca: /path/to/ca.pem
      redirectURI: https://ui.cd.yourorganization.net/api/dex/callback
      usernameAttr: email
      emailAttr: email
      groupsAttr: group

---

Private deployment

It is possible to setup Okta SSO with a private Hanzo CD installation, where the Okta callback URL is the only publicly exposed endpoint. The settings are largely the same with a few changes in the Okta app configuration and the data.dex.config section of the cd-cm ConfigMap.

Using this deployment model, the user connects to the private Hanzo CD UI and the Okta authentication flow seamlessly redirects back to the private UI URL.

Often this public endpoint is exposed through an Ingress object.

1. Update the URLs in the Okta app's General settings
   • The Single sign on URL field points to the public exposed endpoint, and all other URL fields point to the internal endpoint.
2. Update the data.dex.config section of the cd-cm ConfigMap with the external endpoint reference.

dex.config: |
  logger:
    level: debug
  connectors:
  - type: saml
    id: okta
    name: Okta
    config:
      ssoURL: https://yourorganization.oktapreview.com/app/yourorganizationsandbox_appnamesaml_2/rghdr9s6hg98s9dse/sso/saml
      # You need `caData` _OR_ `ca`, but not both.
      caData: |
        <CA cert passed through base64 encoding>
      # You need `caData` _OR_ `ca`, but not both.
      # Path to mount the secret to the dex container
      ca: /path/to/ca.pem
      redirectURI: https://external.path.to.cd.io/api/dex/callback
      usernameAttr: email
      emailAttr: email
      groupsAttr: group

Connect Okta Groups to Hanzo CD Roles

Hanzo CD is aware of user memberships of Okta groups that match the Group Attribute Statements regex. The example above uses the cd-* regex, so Hanzo CD would be aware of a group named cd-admins.

Modify the cd-rbac-cm ConfigMap to connect the cd-admins Okta group to the builtin Hanzo CD admin role.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cd-rbac-cm
data:
  policy.csv: |
    g, cd-admins, role:admin
  scopes: '[email,groups]'

OIDC (without Dex)

Warning

Okta groups for RBAC

If you want groups scope returned from Okta, you will need to enable API Access Management with Okta. This addon is free, and automatically enabled, on Okta developer edition. However, it's an optional add-on for production environments, with an additional associated cost.

You may alternately add a "groups" scope and claim to the default authorization server, and then filter the claim in the Okta application configuration. It's not clear if this requires the Authorization Server add-on.

If this is not an option for you, use the SAML (with Dex) option above instead.

Note

These instructions and screenshots are of Okta version 2023.05.2 E. You can find the current version in the Okta website footer.

First, create the OIDC integration:

1. On the Okta Admin page, navigate to the Okta Applications at Applications > Applications.
2. Choose Create App Integration, and choose OIDC, and then Web Application in the resulting dialogues.
3. Update the following:
   1. App Integration name and Logo - set these to suit your needs; they'll be displayed in the Okta catalogue.
   2. Sign-in redirect URLs: Add https://cd.example.com/auth/callback; replacing cd.example.com with your Hanzo CD web interface URL.
   3. Sign-out redirect URIs: Add https://cd.example.com; substituting the correct domain name as above.
   4. Either assign groups, or choose to skip this step for now.
   5. Leave the rest of the options as-is, and save the integration.
4. Copy the Client ID and the Client Secret from the newly created app; you will need these later.

Next, create a custom Authorization server:

1. On the Okta Admin page, navigate to the Okta API Management at Security > API.
2. Click Add Authorization Server, and assign it a name and a description. The Audience should match your Hanzo CD URL - https://cd.example.com
3. Click Scopes > Add Scope:
   1. Add a scope called groups. Leave the rest of the options as default.
4. Click Claims > Add Claim:
   1. Add a claim called groups.
   2. Adjust the Include in token type to ID Token, Always.
   3. Adjust the Value type to Groups.
   4. Add a filter that will match the Okta groups you want passed on to Hanzo CD; for example Regex: cd-.*.
   5. Set Include in to groups (the scope you created above).
5. Click on Access Policies > Add Policy. This policy will restrict how this authorization server is used.
   1. Add a name and description.
   2. Assign the policy to the client (application integration) you created above. The field should auto-complete as you type.
   3. Create the policy.
6. Add a rule to the policy:
   1. Add a name; default is a reasonable name for this rule.
   2. Fine-tune the settings to suit your organization's security posture. Some ideas:
      1. uncheck all the grant types except the Authorization Code.
      2. Adjust the token lifetime to govern how long a session can last.
      3. Restrict refresh token lifetime, or completely disable it.
7. Finally, click Back to Authorization Servers, and copy the Issuer URI. You will need this later.

CLI login

In order to login with the CLI cd login https://cd.example.com --sso, Okta requires a separate dedicated App Integration:

1. Create a new Create App Integration, and choose OIDC, and then Single-Page Application.
2. Update the following:
   1. App Integration name and Logo - set these to suit your needs; they'll be displayed in the Okta catalogue.
   2. Sign-in redirect URLs: Add http://localhost:8085/auth/callback.
   3. Sign-out redirect URIs: Add http://localhost:8085.
   4. Either assign groups, or choose to skip this step for now.
   5. Leave the rest of the options as-is, and save the integration.
   6. Copy the Client ID from the newly created app; cliClientID: <Client ID> will be used in your cd-cm ConfigMap.
3. Edit your Authorization Server Access Policies:
   1. Navigate to the Okta API Management at Security > API.
   2. Choose your existing Authorization Server that was created previously.
   3. Click Access Policies > Edit Policy.
   4. Assign your newly created App Integration by filling in the text box and clicking Update Policy.

If you haven't yet created Okta groups, and assigned them to the application integration, you should do that now:

1. Go to Directory > Groups
2. For each group you wish to add:
   1. Click Add Group, and choose a meaningful name. It should match the regex or pattern you added to your custom group claim.
   2. Click on the group (refresh the page if the new group didn't show up in the list).
   3. Assign Okta users to the group.
   4. Click on Applications and assign the OIDC application integration you created to this group.
   5. Repeat as needed.

Finally, configure Hanzo CD itself. Edit the cd-cm configmap:

url: https://cd.example.com
oidc.config: |
  name: Okta
  # this is the authorization server URI
  issuer: https://example.okta.com/oauth2/aus9abcdefgABCDEFGd7
  clientID: 0oa9abcdefgh123AB5d7
  cliClientID: gfedcba0987654321GEFDCBA # Optional if using the CLI for SSO
  clientSecret: ABCDEFG1234567890abcdefg
  requestedScopes: ["openid", "profile", "email", "groups"]
  requestedIDTokenClaims: {"groups": {"essential": true}}

You may want to store the clientSecret in a Kubernetes secret; see how to deal with SSO secrets for more details.