Azure AD SSO Authentication in Redpanda Console

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

By integrating Redpanda Console with Azure AD, your users can sign in to Redpanda Console using their Azure AD login credentials.

Prerequisites

You must have:

An Azure AD account and permissions to create applications within your directory.

A registered OIDC application with Azure AD configured as the OpenID Connect (OIDC) provider. For instructions, see the Microsoft documentation.

When you register the application, provide the following inputs when you are asked for them:

Name: Enter a name for the application
Supported account types: Select a supported account type. For details, see the Microsoft documentation.
Redirect URI: Enter the domain where Redpanda Console is hosted followed by the /login/callbacks/azure-ad path. For example, https://console.<your-company>.com/login/callbacks/azure-ad or https://localhost:8080/login/callbacks/azure-ad.

When you configure the identity provider, make a note of the client ID and client secret. You must add these credentials to the console configuration file so that Repanda Console can establish communication with Azure AD.

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.

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.
  #
  # To securely generate a jwtSecret key, run 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: ""

  azureAd:
    enabled: true
    # ProviderURL must be specified in the following format:
    # https://login.microsoftonline.com/{tenantId}/v2.0 .
    # To get this URL, browse to the registered app in your
    # Azure Portal and click the "Endpoints" tab. A drawer
    # opens with several links. The link below
    # "OpenID Connect metadata document" contains the
    # provider URL; however, you must remove the suffix
    # "/.well-known/openid-configuration" so that it
    # matches the expected format.
    providerUrl: ""

    clientId: ""
    clientSecret: ""

    #  userIdentifyingClaimKey is only needed when you want
    #  to use a different claim key to identify users in the
    #  role binding. By default, Redpanda uses the 'oid' claim key,
    #  which resolves to the unique user ID within the identity
    #  provider. This means that you must provide the oid
    #  identifier in the roleBindings as 'name' as well.
    #  Other common options are:
    #  - upn (unique principal name - you need to add the upn
    #    claim as a claim for id tokens in your Azure AD application)
    #  - email (under certain conditions there's no value for
    #    the email propagated)
    userIdentifyingClaimKey: "oid"

    # The directory configuration is only required if you want to use
    # Azure AD groups in your role bindings, as described
    # in the next section.
    # directory:
    #   tenantId: ""

RBAC Azure AD groups sync

You can bind roles to Azure groups from your organization by providing the tenantId in the directory configuration and adding API permissions to your client application. To retrieve the tenantId, go to your registered application in the Azure Active Directory portal. The Directory (tenant) ID is listed along with other configurations in the Essentials section.

login:
  azureAd:
    directory:
      tenantId: ""

If you specify the tenantId, Redpanda Console will send a request to the Microsoft Graph API to retrieve the memberships for the specified groups. In order for the Microsoft Graph API to grant the request, the client must have the appropriate permissions. In your AzureAD application, go to API permissions and add the following permissions:

Group.Read.All
User.Read.All
Directory.Read.All

Next, grant admin consent for the default directory by clicking Grant admin consent for Default Directory.

Define role-bindings

When you set up the Azure AD login configuration, you can bind Azure AD users or groups to roles. Following is a sample role binding:

roleBindings:
  - metadata:
      name: Developers
    subjects:
      - kind: group
        provider: AzureAD
        # Name for group refers to the group's oid.
        name: ef0dd5b8-93c3-4a4f-9d90-cba243973d32
      - kind: user
        provider: AzureAD
        # Name refers to the user's OID.
        # This depends on your userIdentifyingClaimKey
        # configuration. For example, if you use `email` as the claim key,
        # use the email address for the name.
        name: c86fdb3f-b0f4-4b0b-9be3-ddf56f48b62f
    roleName: editor

The resolved group memberships can also include transitive members. This allows you to create nested groups and refer to them in your role bindings.