Streaming

Authorization in Redpanda Console

This feature requires an enterprise license. To get a trial license key or extend your trial period, generate a new trial license key. To purchase a license, contact Redpanda Sales.

If Redpanda Console has enterprise features enabled and it cannot find a valid license, it redirects you to the license expiration landing page, and all other access is restricted.

Authentication allows users to log in, but authorization determines what they can do once authenticated.

Redpanda Console decides authorization per API, not through a single global setting. You enable user impersonation separately for each upstream API. Redpanda authorizes requests to an API with impersonation enabled. Redpanda Console authorizes every other request itself, using the role bindings and group bindings in its configuration.

Request target Who evaluates permissions?

An API with impersonateUser: true

Redpanda, using its internal RBAC and ACLs. Redpanda Console defers authorization for these endpoints, so its own role bindings and group bindings do not apply to them.

An API with impersonateUser: false

Redpanda Console, using the role bindings and group bindings in its configuration. Redpanda sees these requests as coming from a static service account.

An endpoint that Redpanda Console serves itself

Redpanda Console, using the role bindings and group bindings in its configuration. These endpoints have no upstream to defer to.

You set impersonateUser independently for the Kafka API (kafka.sasl), the Schema Registry (schemaRegistry.authentication), and the Redpanda Admin API (redpanda.adminApi.authentication). Enabling impersonation for one API does not change how the others are authorized.

Enabling impersonation for every upstream API does not switch off Redpanda Console authorization. Redpanda Console continues to authorize the endpoints it serves itself, including Kafka Connect, secret management, and its own API. Role bindings and group bindings remain in effect for those endpoints, so keep them configured.

For more information about authentication options, see the Redpanda Console authentication.

Modes of service account usage

When impersonation is disabled, Redpanda Console uses a static service account to connect to Redpanda APIs. This service account must be listed as a superuser principal in the Redpanda superusers configuration.

In Redpanda, a principal is the authenticated identity (such as a username or OIDC subject) used for access control. For details, see Users, Principals, and Superusers.

For any secret values, use environment variables instead of hardcoding them in the configuration file. For example, use KAFKA_SASL_PASSWORD for the service account password.

There are two ways to use this service account:

Static service account only (no login)

Use this mode to connect Redpanda Console to Redpanda with a static service account and no user login. When using the static service account (no login) mode:

  • There is no login screen.

  • All users share the same access level.

  • Redpanda Console roles and RBAC are not enforced.

  • It can be useful for internal tools.

Example
authentication:
  basic:
    enabled: false
  oidc:
    enabled: false

kafka:
  sasl:
    enabled: true
    impersonateUser: false
    username: "console-superuser"
    password: "secret"

Static service account with user login

Use this mode to allow users to log in, while still having all API calls executed under a single service account. When using static service accounts with user login:

  • Users authenticate to the UI using basic or OIDC login.

  • All backend communication to Redpanda APIs uses the service account.

  • Redpanda Console roles (roleBindings) determine what users can see or do in the UI.

  • Redpanda authorization is evaluated against the service account.

  • Standalone

  • Kubernetes embedded

  • Kubernetes standalone

authentication:
  basic:
    enabled: true
  oidc:
    enabled: true

kafka:
  sasl:
    enabled: true
    impersonateUser: false
    username: "console-superuser"
    password: "secret"

authorization:
  roleBindings:
    - roleName: admin
      users:
        - loginType: basic
          name: alice

When Redpanda Console is part of the Redpanda Helm chart or Operator:

  • Operator

  • Helm

redpanda-cluster.yaml
apiVersion: cluster.redpanda.com/v1alpha2
kind: Redpanda
metadata:
  name: redpanda
spec:
  clusterSpec:
    console:
      enabled: true
      console:
        config:
          authentication:
            basic:
              enabled: true
            oidc:
              enabled: true
          kafka:
            sasl:
              enabled: true
              impersonateUser: false
              username: "console-superuser"
              password: "secret"
          authorization:
            roleBindings:
              - roleName: admin
                users:
                  - loginType: basic
                    name: alice
redpanda-values.yaml
console:
  enabled: true
  console:
    config:
      authentication:
        basic:
          enabled: true
        oidc:
          enabled: true
      kafka:
        sasl:
          enabled: true
          impersonateUser: false
          username: "console-superuser"
          password: "secret"
      authorization:
        roleBindings:
          - roleName: admin
            users:
              - loginType: basic
                name: alice

When using the standalone Redpanda Console Helm chart:

console-values.yaml
config:
  authentication:
    basic:
      enabled: true
    oidc:
      enabled: true

  kafka:
    sasl:
      enabled: true
      impersonateUser: false
      username: "console-superuser"
      password: "secret"

  authorization:
    roleBindings:
      - roleName: admin
        users:
          - loginType: basic
            name: alice

This model is recommended if you want to manage RBAC in Redpanda Console, but still want to use a service account for API calls.

Roles

Roles in Redpanda Console determine which UI features users can access. You assign them in the roleBindings stanza (to individual users) or the groupBindings stanza (to groups from an OIDC token) of the Redpanda Console configuration file. Redpanda Console evaluates them for every request it authorizes itself: requests to APIs with impersonation disabled, and requests to endpoints it serves directly.

Do you have user impersonation enabled?

Redpanda Console roles are not used for requests to an API that has user impersonation enabled. For those requests, the user’s identity is forwarded to Redpanda, which then authorizes access based on RBAC and ACL rules. Roles still apply to the endpoints Redpanda Console authorizes itself.

To successfully log in and access the UI, users must have valid Redpanda credentials and ACLs that permit access to the Kafka API.

To access full Redpanda Console functionality (for example, downloading debug bundles or viewing broker configs), the user must also be a superuser in Redpanda.

For information on assigning ACLs and superuser status, see Configure Access Control Lists.

When Redpanda Console authorizes a request itself, it grants access to UI features based on the roles bound in roleBindings and groupBindings. However:

  • Redpanda Console roles are not shown in the Roles tab on the Security page.

  • Redpanda Console roles do not grant access to Redpanda APIs (such as the Kafka API).

  • A Redpanda Console Admin is not a Redpanda superuser by default.

To perform protected actions (for example, creating topics, managing ACLs, or accessing the Admin API), users must be granted corresponding permissions in Redpanda.

If you’re running Redpanda Console with impersonation disabled, ensure the Redpanda Console service account is listed as a superuser in Redpanda. Otherwise, Redpanda Console cannot perform administrative actions on behalf of logged in users.

Redpanda Console provides the following predefined roles:

Role Permissions Limitations

Viewer

  • View topic data (messages, configs, partitions with search filters)

  • View cluster data (node configs, ACLs, service accounts, quotas)

  • View consumer group data (consumer groups, group offsets, lags)

  • View Schema Registry data (registered schemas with contents)

  • View Kafka Connect data (configured clusters, connectors including status and configs)

Cannot view the list of users

Editor

Inherits all Viewer permissions, plus:

  • Manage topics (create, edit configurations, delete topics, publish and delete records)

  • Manage cluster configurations (edit node or cluster settings)

  • Manage consumer groups (edit or delete group offsets)

  • Manage Kafka Connect (create, update, delete, start, pause, or stop connectors)

Cannot create or remove ACLs or service accounts

Admin

Inherits all Editor permissions, plus:

No limitations
Kafka Connect is community-supported on Redpanda Community Slack. Redpanda Data does not provide enterprise support for Kafka Connect with Redpanda Console. For a supported and scalable Kafka Connect alternative, try Redpanda Connect.

Grant permissions through role bindings

When impersonation is disabled, Redpanda Console connects to Redpanda APIs using the service account defined in:

  • kafka.sasl: For the Kafka API

  • schemaRegistry.authentication: For the Schema Registry API

  • redpanda.adminApi.authentication: For the Admin API

The Redpanda Console service account must be a superuser principal in Redpanda. Without superuser privileges, Redpanda Console is unable to perform actions such as listing topics, retrieving cluster metrics, managing ACLs, or accessing administrative endpoints.

To grant superuser permissions to the service account:

rpk cluster config set superusers '["console-superuser"]' \
  -X user=<existing-superuser> -X pass=<password>

Before login, Redpanda Console authenticates the user by validating their credentials against the Kafka API. If the user does not exist in Redpanda (for example, if they have not been created or their identity is not mapped through OIDC), login fails.

After login, all API communication is performed using the service account’s credentials, not the end-user’s. This ensures Redpanda Console can act on the user’s behalf. As such, the service account must have sufficient privileges to cover the actions users are allowed to perform in the UI.

Example: Assign the Viewer role

This example shows how to grant the Viewer role to a user named matt. The Redpanda Console service account (console-superuser) is used to authenticate to all Redpanda services.

  • Standalone

  • Kubernetes embedded

  • Kubernetes standalone

kafka:
  brokers: ["broker1.example.com:9092"]
  sasl:
    enabled: true
    impersonateUser: false (1)
    username: "console-superuser" (1)
    password: "secret-password"
    mechanism: "SCRAM-SHA-256"
schemaRegistry:
  enabled: true
  urls:
    - "broker1.example.com:8081"
    - "broker2.example.com:8081"
  authentication:
    impersonateUser: false
    basic:
      username: "console-superuser" (1)
      password: "secret-password"
redpanda:
  adminApi:
    enabled: true
    urls:
      - "broker1.example.com:9644"
    authentication:
      impersonateUser: false
      basic:
        username: "console-superuser" (1)
        password: "secret-password"
authorization:
  roleBindings:
  - roleName: viewer (2)
    users:
      - loginType: basic
        name: "matt" (2)

When using the Redpanda Operator or the Redpanda Helm chart, configure authorization through the cluster configuration:

  • Operator

  • Helm

apiVersion: cluster.redpanda.com/v1alpha2
kind: Redpanda
metadata:
  name: redpanda
spec:
  clusterSpec:
    console:
      enabled: true
      console:
        config:
          kafka:
            sasl:
              enabled: true
              impersonateUser: false (1)
              username: "console-superuser" (1)
              password: "secret-password"
              mechanism: "SCRAM-SHA-256"
          schemaRegistry:
            enabled: true
            authentication:
              impersonateUser: false
              basic:
                username: "console-superuser" (1)
                password: "secret-password"
          redpanda:
            adminApi:
              enabled: true
              authentication:
                impersonateUser: false
                basic:
                  username: "console-superuser" (1)
                  password: "secret-password"
          authorization:
            roleBindings:
            - roleName: viewer (2)
              users:
                - loginType: basic
                  name: "matt" (2)
console:
  enabled: true
  console:
    config:
      kafka:
        sasl:
          enabled: true
          impersonateUser: false (1)
          username: "console-superuser" (1)
          password: "secret-password"
          mechanism: "SCRAM-SHA-256"
      schemaRegistry:
        enabled: true
        authentication:
          impersonateUser: false
          basic:
            username: "console-superuser" (1)
            password: "secret-password"
      redpanda:
        adminApi:
          enabled: true
          authentication:
            impersonateUser: false
            basic:
              username: "console-superuser" (1)
              password: "secret-password"
      authorization:
        roleBindings:
        - roleName: viewer (2)
          users:
            - loginType: basic
              name: "matt" (2)

When using the standalone Redpanda Console Helm chart:

config:
  kafka:
    brokers: ["broker1.example.com:9092"]
    sasl:
      enabled: true
      impersonateUser: false (1)
      username: "console-superuser" (1)
      password: "secret-password"
      mechanism: "SCRAM-SHA-256"
  schemaRegistry:
    enabled: true
    urls:
      - "broker1.example.com:8081"
      - "broker2.example.com:8081"
    authentication:
      impersonateUser: false
      basic:
        username: "console-superuser" (1)
        password: "secret-password"
  redpanda:
    adminApi:
      enabled: true
      urls:
        - "broker1.example.com:9644"
      authentication:
        impersonateUser: false
        basic:
          username: "console-superuser" (1)
          password: "secret-password"
  authorization:
    roleBindings:
    - roleName: viewer (2)
      users:
        - loginType: basic
          name: "matt" (2)

Apply with:

helm upgrade --install redpanda-console redpanda/console -f console-values.yaml
1 With impersonation disabled, Redpanda Console uses the static service account (console-superuser) to connect to the Redpanda APIs. For security, store private data such as passwords in environment variables. For example: KAFKA_SASL_PASSWORD.
2 Role bindings map UI users to Redpanda Console roles. This does not grant Redpanda-level permissions. The user (matt) must also exist in Redpanda.

All APIs must be accessible using a superuser principal. If the service account lacks superuser status, Redpanda Console may not be able to fetch cluster status, access the Admin API, or interact with the Schema Registry.

Transform identities with principal mappings

If you use OIDC login, the identity in the JWT token is extracted using a JSONPath expression. By default, this expression is $.sub, which means the value of the sub claim is used as the username. You can override this expression using the principalMapping option to transform or extract a different claim to match the name values in your roleBindings configuration.

To keep authorization consistent between Redpanda Console and Redpanda, set principalMapping to match Redpanda’s cluster configuration value for oidc_principal_mapping.

Example: Map email to local username
authentication:
  oidc:
    enabled: true
    issuerUrl: https://auth.dev.cloud.redpanda.com/
    clientId: R1iX7Pls9UMXiUoYBOn4NcIUTbaGX4JG
    clientSecret: redacted
    redirectUrl: http://localhost:9090/auth/callbacks/oidc
    successfulLoginRedirectUrl: http://localhost:3000
    principalMapping: $.email/([^@]+)@example.com/$1/L

This example:

  • Extracts the email field from the OIDC token

  • Uses a regular expression to capture the username part

  • Replaces the value with the captured group $1

  • Converts the result to lowercase (L modifier)

As a result, the user identity becomes matt when the email is matt@example.com.

You can then define role bindings like this:

  • Standalone

  • Kubernetes embedded

  • Kubernetes standalone

authorization:
  roleBindings:
    - roleName: admin
      users:
        - loginType: OIDC
          name: matt

When using the Redpanda Operator or the Redpanda Helm chart, configure role bindings through the cluster configuration:

  • Operator

  • Helm

apiVersion: cluster.redpanda.com/v1alpha2
kind: Redpanda
metadata:
  name: redpanda
spec:
  clusterSpec:
    console:
      enabled: true
      console:
        config:
          authorization:
            roleBindings:
              - roleName: admin
                users:
                  - loginType: OIDC
                    name: matt
console:
  enabled: true
  console:
    config:
      authorization:
        roleBindings:
          - roleName: admin
            users:
              - loginType: OIDC
                name: matt

When using the standalone Redpanda Console Helm chart:

config:
  authorization:
    roleBindings:
      - roleName: admin
        users:
          - loginType: OIDC
            name: matt

Apply with:

helm upgrade --install redpanda-console redpanda/console -f console-values.yaml

Match syntax and modifiers

The principalMapping syntax uses this format:

<jsonpath>/<regex>/<replacement>/<modifiers>

  • jsonpath: Path to the claim field in the token (such as $.email)

  • regex: A regular expression to extract part of the claim

  • replacement: A replacement string using a captured group (such as $1)

  • modifiers: Optional flags, such as:

    • L — convert to lowercase

    • U — convert to uppercase

If principalMapping is not set, Redpanda Console defaults to using the sub claim as the user identity.

Grant permissions to groups

Group bindings are available in Redpanda Console v3.7.0 and later.

Instead of binding a role to each user, you can bind a role to a group carried in the user’s OIDC token. Group bindings are useful when your identity provider already models teams, because your identity provider manages membership rather than the Redpanda Console configuration.

Group names come from the OIDC token, so group bindings apply to users who log in through OIDC.

Example: Assign roles to groups
authorization:
  groupBindings:
    - roleName: admin
      groups:
        - platform-team
    - roleName: viewer
      groups:
        - data-analysts
        - support-engineers

Each entry requires:

  • roleName: A built-in role (viewer, editor, or admin), or a custom role if you define one in the roles stanza. Redpanda Console fails to start if the role does not exist.

  • groups: One or more group names. The list cannot be empty.

Redpanda Console reads group names from the token using authentication.oidc.groupClaimPath and compares them to the groups list using an exact, case-sensitive match. A group name that differs in case or surrounding whitespace does not match.

A user receives the union of every role bound to them directly and every role bound to a group they belong to. See Multiple roles and duplicate bindings.

Redpanda Console does not apply group bindings in Redpanda Serverless deployments, which use a custom principal extractor.

Group bindings compared with Redpanda group-based access control

Redpanda Console group bindings and Redpanda group-based access control are separate mechanisms. Each reads group names from the token using its own claim settings, so you must configure both independently. They resolve the same set of groups only when you set both claim paths to the same value.

Aspect Redpanda Console group bindings Redpanda group-based access control

What it grants

A Redpanda Console role, controlling access to UI features and to the endpoints Redpanda Console authorizes

Redpanda permissions for Group: principals, controlling access to the Kafka API and other Redpanda resources. You can create ACLs directly for the group or assign the group to an RBAC role.

Where you configure it

authorization.groupBindings in the Redpanda Console configuration

Redpanda cluster properties and ACLs

Which claim path applies

authentication.oidc.groupClaimPath in Redpanda Console

oidc_group_claim_path in Redpanda

How nested group names are handled

authentication.oidc.nestedGroupClaimBehavior: none (default) or flatten

nested_group_behavior: none (default) or suffix

The flatten and suffix values have the same effect, keeping only the last path segment, but the names differ. You cannot copy one setting into the other.

Redpanda Console does not grant Redpanda permissions. A group binding that assigns the admin role does not make its members Redpanda superusers. To grant permissions on Redpanda resources, either create ACLs for the Group: principal or assign the group to a Redpanda RBAC role, as described in Configure Group-Based Access Control.

Multiple roles and duplicate bindings

You can assign multiple roles to the same user through role bindings, group bindings, or a combination of the two. In this case, the user receives the union of all permissions associated with those roles.

For example, if a user is assigned both viewer and editor, they can perform all actions granted to each role.

Example: User with multiple role assignments
authorization:
  roleBindings:
  - roleName: viewer
    users:
      - loginType: OIDC
        name: john.doe@redpanda.com
  - roleName: editor
    users:
      - loginType: OIDC
        name: john.doe@redpanda.com

Duplicate role assignments do not cause errors. If the same role is assigned more than once to a user, whether through repeated role bindings or through both a role binding and a group binding, the user receives the permissions only once.

Suggested reading

For details on how to assign Redpanda-level permissions through ACLs or RBAC, see:

Suggested labs

Search all labs