# Authorization

> For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt)

---
title: Authorization
latest-operator-version: v26.1.4
# EOL = End-of-Life (support lifecycle status)
page-is-nearing-eol: "false"
page-is-past-eol: "true"
page-eol-date: December 22, 2024
latest-console-tag: v3.7.3
latest-connect-version: 4.93.0
docname: security/console/authorization
page-component-name: streaming
page-version: "23.3"
page-component-version: "23.3"
page-component-title: Streaming
page-relative-src-path: security/console/authorization.adoc
page-edit-url: https://github.com/redpanda-data/docs/edit/v/23.3/modules/manage/pages/security/console/authorization.adoc
description: Redpanda Console uses role-based access control (RBAC) to restrict system access to authorized users.
page-git-created-date: "2023-05-30"
page-git-modified-date: "2024-02-26"
support-status: past end-of-life
---

<!-- Source: https://docs.redpanda.com/streaming/23.3/manage/security/console/authorization.md -->

> 📝 **NOTE**
>
> This section pertains to Redpanda Console in a self-hosted deployment, and this feature requires an [Enterprise license](https://docs.redpanda.com/streaming/23.3/get-started/licenses/). To upgrade, contact [Redpanda sales](https://redpanda.com/try-redpanda?section=enterprise-trial).

Redpanda Console uses role-based access control (RBAC) to restrict system access to authorized users. All configurations have to be provided via YAML files. Console will load these files at startup. This page describes the concept, the available roles, and how you can bind roles to your users.

> 📝 **NOTE**
>
> This page describes RBAC in Redpanda Console and therefore manages access only for Console user but not clients that interact via the Kafka API. To restrict Kafka API access, you need to use Kafka ACLs.

## [](#rbac-concepts)RBAC concepts

You can control access to different resources in Console by binding one of the existing roles (admin, editor, viewer) to one or more users. Besides binding roles to individual users, you can also use user groups (for example, Google groups) from your configured identity providers. Users who have multiple roles assigned will receive the union of all permissions that have been defined in the bound roles.

## [](#roles)Roles

Each role has a name, as well as a set of permissions, which define the user permissions when the role is bound to a user. Console comes with three primitive roles:

### [](#role-viewer)Role `viewer`

The viewer role grants you the permissions to view all resources within Console. This includes:

-   Viewing all topic aspects (messages, configs, partition, using search filters)

-   Viewing all cluster aspects (node configs, acls, service accounts, quotas)

-   Viewing all consumer group aspects (consumer groups, group offsets and lags)

-   Viewing all schema registry aspects (registered schemas with their contents)

-   Viewing all Kafka connect aspects (list configured clusters and their connectors including the status and connector configs)


It does not include permissions to view the list of Console users (admin tab) that are allowed to use Console.

### [](#role-editor)Role `editor`

The editor role grants all permissions that come with the `viewer` role and additionally includes:

-   Managing all topic aspects, such as creating topics, editing topic configuration, deleting topics, and publishing and deleting topic records.

-   Managing all cluster configuration aspects, such as editing node or cluster configs.

-   Managing all consumer group aspects, such as editing group offsets or deleting group offsets.

-   Managing all Kafka connect aspects, such as creating/updating/deleting or starting/pausing/stopping connectors.


It does not include the permission to create/remove ACLs or to create or remove a service account.

### [](#role-admin)Role `admin`

The editor role grants all permissions that come with the `editor` role and additionally includes:

-   Managing all service account aspects (create/remove service account)

-   Manage all ACL aspects (create/remove ACLs)


> 📝 **NOTE**
>
> You cannot create your own roles with a custom set of permissions.

## [](#role-bindings)Role bindings

To grant users the permissions defined in a role, you must bind the role to a user or a group. Each role binding holds a list of subjects (users or groups) and a reference to the role being granted. Optionally you can add metadata (key-value pairs) which may help you to manage your role bindings. Console shows the metadata in the UI, so that it helps you to understand how a specific user got its permissions.

Example `role-bindings.yaml` configuration file:

```yaml
roleBindings:
  - roleName: admin
    metadata:
      # Metadata properties will be shown in the UI. You can omit it if you want to
      name: Developers
      creator: John Doe
    subjects:
      - kind: user
        provider: Google
        name: john.doe@redpanda.com
      - kind: group
        provider: Google
        name: dev-team-console@redpanda.com
```

This role binding binds Google account `john.doe@redpanda.com` as well as all Google accounts which are a member of Google group `dev-team-console@redpanda.com` to the role with name `admin`. Group memberships are resolved recursively, so that members from nested groups are also considered. Users who have multiple roles assigned through role bindings will inherit the union of these roles' permissions.

You can find a [reference config for role bindings](https://docs.redpanda.com/streaming/23.3/reference/console/role-bindings/).

> ⚠️ **CAUTION**
>
> To use groups in role bindings you need to configure the [Groups sync](#groups-sync) for your respective provider.

### [](#subjects)Subjects

Each subject has three properties that are configurable to bind a role to one or more users.

`kind`: Supported kinds are: `group` and `user`.

`providers`: One of `Google`, `GitHub`, `Okta`, `OIDC` and `Plain`.

`name`: Depending on your `kind` and `provider` the `name` property may refer to different things. This is an overview to what it refers for each provider:

| Kind | Provider | Name Reference |
| --- | --- | --- |
| user | Google | Google E-Mail address |
| group | Google | Google Group Name (which is an E-Mail address) |
| user | GitHub | Login handle / GitHub username |
| group | GitHub | GitHub team name within your GitHub organization |
| user | Okta | Login handle / email |
| group | Okta | Okta Group ID (not name), for example "00gra1ajmZa1G1ks04x9" |
| user | OIDC | Configurable via login.oidc.userIdentifyingClaimKey (by default it uses the sub claim from the issued access token) |
| user | Plain | Username as defined in the login.plain.credentials configuration |

### [](#groups-sync)Groups sync

If you want to bind Roles to a set of users (for example GitHub teams or Google Groups) you need to grant Console additional permissions, so that it can resolve the memberships of these user sets. You will find more information about the setup in the respective identity provider documentation page.

All group memberships that are used in rolebindings, are resolved at startup. Group memberships will be cached for 15 minutes. Resolving group memberships proactively is required in order to support nested groups.

## Suggested labs

-   [Enable Unified Identity with Azure Entra ID for Redpanda and Redpanda Console](https://docs.redpanda.com/labs/docker-compose/oidc/)

[Search all labs](https://docs.redpanda.com/labs)