Authorization

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.

Redpanda Console supports role-based access control (RBAC) to restrict system access to authorized users. This page is intended for cluster administrators who manage Redpanda Console access and need to configure UI-based authorization.

Redpanda Console supports two authorization modes, depending on whether user impersonation is enabled in the authentication configuration:

Mode Who Evaluates Permissions?

Impersonation disabled (impersonateUser: false)

Redpanda Console evaluates permissions using role bindings defined in its configuration. Redpanda sees all requests as coming from a static service account.

Impersonation enabled (impersonateUser: true)

Redpanda evaluates permissions using its internal RBAC and ACLs. Any role bindings in the Redpanda Console configuration are ignored.

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.

Example
authentication:
  basic:
    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. These roles are configured in the roleBindings stanza of the Redpanda Console configuration file and are evaluated only when impersonation is disabled.

Do you have user impersonation enabled?

Redpanda Console roles are not used when user impersonation is enabled for an API. When impersonation is enabled, the user’s identity is forwarded to Redpanda, which then authorizes access based on RBAC and ACL rules.

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 Access Control Lists.

When impersonation is disabled, Redpanda Console authorizes access to features in the UI based on the configured roles in roleBindings. 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 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

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.

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:
    - "http://broker1.example.com:8081"
    - "http://broker2.example.com:8081"
  authentication:
    impersonateUser: false
    basic:
      username: "console-superuser" (1)
      password: "secret-password"
redpanda:
  adminApi:
    enabled: true
    urls:
      - "http://broker1.example.com:9644"
      - "http://broker2.example.com:9644"
    authentication:
      impersonateUser: false
      basic:
        username: "console-superuser" (1)
        password: "secret-password"
authentication:
  jwtSigningKey: "<secret-key>"
  basic:
    enabled: true
authorization:
  roleBindings:                        (2)
    - roleName: viewer
      users:
        - loginType: basic
          name: matt
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.

Multiple roles and duplicate bindings

You can assign multiple roles to the same user through role bindings. 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, 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