Okta SSO Setup

This section pertains to Redpanda Console in a self-hosted deployment, and this feature requires an Enterprise license. To upgrade, contact Redpanda sales.

Integrating Redpanda Console with Okta allows your users to use their Okta identities to sign in to Redpanda Console. This guide is based on the assumption that you already have an Okta account and permissions to create applications within your organization.

Create an OpenID connect application

Refer to the Okta guide to create an application integration for Redpanda Console. As you follow the guide to create the Okta integration, use the following inputs when prompted:

The following configurations are based on the assumption that you want to host Redpanda Console so that it is accessible using https://console.<your-company>.com.

Redirect URI: https://console.<your-company>.com/login/callbacks/okta
Logout Redirect URI: https://console.<your-company>.com
Sign-in method: OIDC - Open ID Connect / Application type: Web Application
Assignments: Select groups that are authorized to use Redpanda Console (authorization can be made more granular using Redpanda Console’s RBAC system)

Edit the console configuration file

Edit the console configuration file associated with your deployment method and incorporate the details from your client application. For example, Kubernetes deployments use the values.yaml file. Linux deployments use the redpanda-console-config.yaml file, which is in /etc/redpanda.

When you create the Okta application, you should be able to retrieve the application’s client ID and client secret and put them in your Redpanda Console configuration.

login:
  enabled: true

  # jwtSecret is the secret key you must use to sign and encrypt the JSON
  # web token used to store user sessions. This secret key is
  # critical for the security of Redpanda Console's authentication and
  # authorization system. Use a long, complex key with a combination of
  # numbers, letters, and special characters. The minimum number of
  # characters is 10, but Redpanda recommends using more than 32
  # characters. For additional security, use a different secret key for
  # each environment. jwtSecret can be securely generated with the following
  # command: LC_ALL=C tr -dc '[:alnum:]' < /dev/random | head -c32
  #
  # If you update this secret key, any users who are
  # already logged in to Redpanda Console will be logged out and will have
  # to log in again.
  jwtSecret: ""

  okta:
    enabled: true
    # URL to the OIDC endpoint; for example, "https://<your-company>.okta.com"
    url: ""
    clientId: ""
    # ClientSecret is sensitive. You can also provide this config by setting
    # the environment variable LOGIN_OKTA_CLIENTSECRET.
    clientSecret: ""
    # The directory config is only required if you want to use Okta
    # groups in your role bindings. This is described further in the next section.
    # directory:
    #   apiToken: ""

RBAC Okta groups sync

To bind roles to Okta groups, you must set up an API token in Okta so that Redpanda Console can retrieve groups and their memberships using the Okta API. To create an API token, refer to the Okta guide. After completing the steps in the guide, insert the created API token into the configuration:

login:
  okta:
    # The directory config is only required if you want to use Okta
    # groups in your role bindings.
    directory:
      apiToken: ""

Define role bindings

After setting up the Okta login configuration, you can bind Okta users or groups to roles. Following is a sample role binding:

roleBindings:
  - metadata:
      name: Developers
    subjects:
      - kind: group
        provider: Okta
        name: 00qri1afoAa12G9js04x6 # Okta group id
      - kind: user
        provider: Okta
        name: joe@yourcompany.com # Okta user login
    roleName: editor