Redpanda Console 2.x End of Life notice.

Last updated: September 1, 2026

Summary:

Redpanda Console 2.x reaches End of Life on 20 November 2026. After this date, Redpanda will not publish security fixes, bug fixes, or further releases for Console 2.x, and technical support will be limited to assistance upgrading to Console 3.x.

Upgrading to Console 3.x requires configuration changes, as Console 3.0 removed several Console 2.x configuration options — including the legacy Console-only RBAC model.

Redpanda Products Affected:

Self Managed Redpanda and Redpanda Console 

Releases Affected:

All Redpanda Console 2.x releases.

Impact:

After 20 November 2026, for Console 2.x:

  • No security patches at any CVSS severity, including Critical.

  • No bug fixes or backports to the 2.x line.

  • Technical Support limited to upgrade assistance.

Configuration options removed in Console 3.0

The following Console 2.x options were deprecated with the release of Console 3.0 and are not available in Console 3.x. See Deprecated features — Redpanda Console configuration.

Console 2.x

Console 3.x

login stanza

authentication stanza

login.jwtSecret

authentication.jwtSigningKey

login.plain (plain login provider)

authentication.basic (requires a SASL/SCRAM user in Redpanda)

login.<oidc-provider>

authentication.oidc (one provider only)

Group-based authorization through OIDC

Reintroduced in Console v3.7.0 as authorization.groupBindings — see Group-based authorization below

enterprise.rbac stanza

authorization.roleBindings

External / separate role-bindings file

Inline under authorization.roleBindings

subjects (kind, provider)

users (loginType, name)

Nested Schema Registry (kafka.schemaRegistry.*)

Top-level schemaRegistry.*

kafka.protobuf.schemaRegistry

Top-level schemaRegistry.*

kafka.protobuf, kafka.cbor, kafka.messagePack

Top-level serde.*

console.maxDeserializationPayloadSize

serde.maxDeserializationPayloadSize

connect configuration block

kafkaConnect

Group-based authorization

Console 3.0 removed the v2 implementation of group-based authorization, OIDC group authorization, GitHub team synchronization, and Keycloak group sync, and roleBindings now support user subjects only. Two replacements exist. In Console v3.7.0 and later, the authorization.groupBindings stanza binds Console's predefined roles to IdP groups in the Console configuration file; a user receives the union of roles bound to them directly and through their groups. For APIs where user impersonation is enabled, use Redpanda cluster RBAC and group-based access control (GBAC) instead: bind OIDC group claims to cluster roles or create Group:<name> ACLs, managed in Redpanda, including through the Console UI's Security page.

Legacy Console role

Equivalent Redpanda permissions

Viewer

read, describe on topics and groups

Editor

read, write, describe on topics; describe on groups

Admin

All of the above, plus the user added as a superuser principal in the cluster configuration

Two behaviors to note:

  • With user impersonation, Console evaluates permissions using Redpanda’s internal RBAC and ACLs, documented here. Impersonation is set per API (Kafka, Schema Registry, Admin API), and role/group bindings remain in effect for endpoints Console serves itself, such as Kafka Connect and secret management, keep them configured

  • Redpanda 26.1 and later support group-based access control (GBAC), which grants permissions to IdP groups using Group:<name> ACL principals or by assigning groups as members of RBAC roles. GBAC requires an Enterprise Edition license, OIDC authentication enabled on the cluster, and your IdP configured to include group claims in the access token. See Configure Group-Based Access Control.

Action Required:

  1. Identify your Console version from the Console UI or your deployment's image tag.

  2. Check your configuration for the removed options above — in particular a login stanza, an enterprise.rbac stanza, a separate role-bindings file, or any group or team synchronization.

  3. Migrate the configuration using the conversion tool in Migrate to Redpanda Console v3.0.0. Review the output before applying it, and recreate group-based access manually (step 4).

  4. If you enable user impersonation for an API, provision each user in Redpanda and grant ACLs per the role mapping above — regardless of whether their access was user-based or group-based. If you keep static credentials, migrated user role bindings continue to work; recreate group-based access either with authorization.groupBindings (Console v3.7.0+) or as Redpanda roles and ACLs. Custom v2 Console roles must be recreated as Redpanda roles in both cases.

  5. Upgrading the Helm chart or Operator may also upgrade Console, as it is included as a subchart. When upgrading via the Operator, the v2 console stanza is automatically migrated to the new Console custom resource — but the migration is not validated, does not handle group-based access, and Console v3 refuses to start on unknown config keys, so check kubectl get console <name> -o jsonpath='{.spec.warnings}' after upgrading.

Questions?

If you have any questions, or need further guidance, reach out to Redpanda Support