Authorization

Redpanda Console uses role-based access control (RBAC) to manage and restrict access to features in the user interface. RBAC allows you to control access to different resources in Redpanda Console by binding roles (admin, editor, viewer) to users. These role bindings determine the permissions that users have when interacting with 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.

RBAC behavior depends on your authentication configuration in Redpanda Console. When using static credentials, you must give users permissions to use Redpanda Console by defining RBAC rules in the Redpanda Console configuration file. If authentication for an API is configured to impersonate users, Redpanda Console RBAC rules are ignored for that API and permissions are derived only from the roles assigned in Redpanda. For more information, see the Authentication.

Roles

Roles defined in Redpanda Console are separate from roles in Redpanda. Roles in Redpanda Console control what a user can see and do within the Console interface and only apply to endpoints where user impersonation is disabled. For example, while an admin user in Redpanda Console can generate debug bundles, the user must also have the corresponding MANAGE_DEBUG_BUNDLE ACL in Redpanda to execute the operation.

Redpanda Console comes with the following 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)

Does not include permission to 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)

Does not include permission to create/remove ACLs or to create/remove service accounts

Admin

Inherits all Editor permissions, plus:

None
Redpanda Console roles do not appear in the Roles tab on the Security page. This page displays only the roles defined in Redpanda.

Grant permissions through role bindings

To grant users the permissions defined in a role, you must bind the role to a non-impersonated user. Each role binding defines the role being granted and a list of users to assign that role.

For example, this role binding gives the Admin role to the Google account john.doe@redpanda.com and the Viewer role to the user Alice:

Example role bindings
kafka:
  brokers: ["broker1.example.com:9092"]
  sasl:
    enabled: true
    impersonateUser: false (1)
authentication: (2)
  jwtSigningKey: secret-key
  useSecureCookies: false
  oidc:
    enabled: true
    issuerUrl: https://accounts.google.com
    clientId: "example-client-id"
    clientSecret: "example-client-secret"
    redirectUrl: http://localhost:9090/auth/callbacks/oidc
  basic:
    enabled: true (2)
authorization: (3)
  roleBindings:
  - roleName: admin
    users:
      - loginType: OIDC
        name: john.doe@redpanda.com # Refers to the sub claim in the JWT token
  - roleName: viewer
    users:
      - loginType: basic
        name: Alice # Refers to the SASL/SCRAM username for the Kafka API or the basic auth username for the HTTP APIs.
1 The impersonateUser flag is set to false, which means Redpanda Console does not impersonate the user who is logged in when making requests to the Kafka API.
2 The authentication block enables users to log into Redpanda Console using OIDC or basic authentication.
3 The authorization block defines the role bindings that grant permissions to users. If this user logs into Redpanda Console as either john.doe@redpanda.com or Alice, they will have the permissions of an Admin or Viewer, respectively.

If the user is impersonated, like in the following example, the role binding is ignored, and the user’s permissions are determined by the roles assigned to them in Redpanda:

Role bindings ignored
kafka:
  brokers: ["broker1.example.com:9092"]
  sasl:
    enabled: true
    impersonateUser: true (1)
authentication: (2)
  jwtSigningKey: secret-key
  useSecureCookies: false
  basic:
    enabled: true (2)
# Role bindings are ignored because the user is impersonated for the Kafka API.
authorization:
  roleBindings:
  - roleName: admin
    users:
      - loginType: basic
        name: name: Peter (3)
1 The impersonateUser flag is set to true, which means Redpanda Console impersonates the user who is logged in when making requests to the Kafka API.
2 The authentication block enables users to log into Redpanda Console using basic authentication.
3 The role binding is ignored because the user is impersonated for the Kafka API.

Multiple roles and duplicate role bindings

Redpanda Console allows you to assign multiple roles to users through role bindings. When a user is associated with more than one role, the user is granted all the permissions defined in each role they are assigned.

For example, if a user is assigned both the viewer and editor roles, they will have all the permissions of a viewer as well as the additional permissions of an editor. Here is an example of a role binding that assigns both the viewer and editor roles to the user john.doe@redpanda.com:

authorization:
  roleBindings:
  - roleName: admin
    users:
      - loginType: OIDC
        name: john.doe@redpanda.com
  - roleName: viewer
    users:
      - loginType: OIDC
        name: john.doe@redpanda.com

Duplicate role bindings do not cause errors or conflicts. If a user is assigned the same role multiple times through role bindings, the duplicate role bindings do not affect the user’s final set of permissions, which are the same as if the role was assigned once.

Suggested reading