How do I set up OIDC/SSO and RBAC in Redpanda for platform teams vs application teams?

Most teams hit the same wall on their first serious Redpanda deployment: platform engineers need deep, cluster-wide control, while application teams just need safe, scoped access to a handful of topics and tools. OIDC/SSO and RBAC are how you draw that line cleanly—without turning your Kafka-compatible streaming layer into a ticket-driven bottleneck.

Quick Answer: Use OIDC/SSO to centralize identity and group mapping from your IdP, then layer Redpanda RBAC and ACLs on top to separate “platform” permissions (cluster, security, quotas) from “application” permissions (namespaced topics, consumer groups, and tools). The result: governed, auditable access for every team, with platform engineers still in control of the plane agents and apps run on.

The Quick Overview

What It Is: A Kafka-compatible streaming platform with enterprise-grade identity and access control: OIDC/SSO for authentication, RBAC for cluster-level permissions, and ACLs for fine-grained data access.
Who It Is For: Platform and data infrastructure teams that need to govern Redpanda access across many application teams, AI agents, and services, while meeting compliance and audit requirements.
Core Problem Solved: You can’t safely move agents and event-driven apps into production if anyone can connect to anything. Redpanda lets you centralize identity, separate duties, and enforce least privilege—before actions happen.

How It Works

At a high level you:

Connect identity via OIDC/SSO.
Redpanda authenticates users and services against your IdP (Okta, Azure AD, Auth0, etc.) using OIDC. Console SSO gives humans a consistent login experience; OIDC tokens or compatible mechanisms back your automation and agents.
Define roles via RBAC.
You map IdP groups (like platform-engineering, payments-app-team, support-copilot) to Redpanda roles. Roles define which administrative surfaces a group can touch—cluster configuration, security, audit logs, and so on.
Scope access via ACLs and policies.
You then apply ACLs at the Kafka API layer—topics, consumer groups, and (for AI) specific tools or agent capabilities. Platform teams own the plane; application teams get controlled, auditable lanes on top.

That’s the pattern: Connect / Control / Operate.

1. Connect: Configure OIDC and SSO

You want a single source of truth for identity. That starts with OIDC and SSO.

Key goals:

Every human user logs into Redpanda Console via SSO.
Every service and agent authenticates using tokens or credentials traceable back to your IdP or service account system.
Group membership in the IdP drives which Redpanda role a user/team receives.

Typical setup steps (conceptual):

Create a Redpanda app in your IdP.
- Register a confidential client in Okta/Azure AD/Auth0.
- Configure redirect URIs for Redpanda Console.
- Enable OIDC scopes (openid, profile, email, plus group claims).
Configure OIDC in Redpanda Console.
- Add the IdP issuer URL and discovery endpoint.
- Configure client ID and client secret.
- Map IdP group claims (e.g., groups) into Redpanda roles.
Enforce SSO for Console access.
- Disable local password-based login for production environments.
- Require SSO for all administrative actions in the Console.

Redpanda supports OIDC and Kerberos authentication, so you can align with existing enterprise standards. The objective isn’t just convenience—it’s traceability. When every platform change and topic policy is linked to a real identity, audit becomes a first-class feature, not an afterthought.

2. Control: Design RBAC for Platform vs Application Teams

This is where you draw the boundary.

Think in two layers:

Cluster-level control: Who can change the plane? (platform teams)
Data-level control: Who can use the plane? (application teams and agents)

Recommended role model

Below is a conceptual RBAC sketch you can adapt to your org.

Platform Admin (cluster-wide)
Mapped from IdP group: redpanda-platform-admins

Permissions typically include:
- Manage clusters and brokers (scale, settings, storage, read replicas).
- Manage security configuration (OIDC, Kerberos, TLS, RBAC).
- Manage quotas and global resource limits.
- View and manage audit logging configuration.
- Create/update high-level policies and global tools for agents.
Platform admins are the only humans allowed to change the plane itself.
Platform Operator (day-two operations)
IdP group: redpanda-platform-ops

Permissions:
- View cluster health, metrics (Prometheus), and logs.
- Trigger safe operational tasks: maintenance, rolling upgrades, continuous data balancing.
- No ability to weaken security: cannot change RBAC, identity, or encryption settings.
These folks keep the system running, but don’t get to rewrite governance.
Application Team Owner (namespaced) IdP group: e.g., redpanda-app-payments, redpanda-app-marketing

Permissions:
- Create and manage topics within a bounded namespace (e.g., payments.*).
- Manage consumer groups for their services.
- View topic-level metrics and lag for their own topics.
- No cluster-level privileges; no ability to see or modify other teams’ namespaces.
Read-only Observer IdP group: redpanda-readonly

Permissions:
- Read metrics, topic lists, and cluster status.
- No write or config privileges.
This is useful for SRE, compliance, and auditors who need visibility without risk.

You then map each IdP group to these roles in Redpanda. When a new engineer joins the payments team, they inherit the app-level role through normal HR/IT flows—no manual ACL tweaking.

3. Operate: Enforce Access with ACLs and Policies

RBAC defines who can touch the administration plane. ACLs and policies define what they can do with data and tools.

Topic and consumer group ACL strategy

Use clear, predictable patterns:

Per-team topic namespaces
- platform.* for internal/platform streams.
- payments.*, risk.*, support.* per application domain.
Per-team consumer groups
- payments-*, risk-*, etc., mapped to the same team role.

Then enforce:

Platform Admins
- Read/write to all topics and groups (for incident response and migrations).
Application Team Owners
- ALLOW produce/consume on topics within their namespace.
- ALLOW manage consumer groups within their namespace.
- DENY for everything else by default.
Services and agents
- Use service-specific credentials or tokens mapped to a restricted ACL set.
- Only expose the minimal topics and tools required for a given agent workflow.

This is where Redpanda’s Kafka compatibility is your friend—ACLs behave in the way Kafka teams expect, but you’re running on a simpler, “one binary, zero dependencies” stack.

Agent-specific controls (Agentic Data Plane)

Agents aren’t just reading data; they’re acting on it. That raises the stakes.

You can:

Authenticate agents with OIDC/OBO (on-behalf-of) tokens.
- The agent runs as its own identity but performs actions on behalf of a user or team.
Apply tool-level policies.
- Filter/redact data before the agent sees it.
- Restrict which tools an agent can invoke and where it can write back.
Scope agents to streams + history via SQL.
- Use Redpanda’s unified query layer to retrieve continuous context but bounded by policies:
  - “Agents can read customer history but not PII fields.”
  - “Agents can write to staging topics only; promotion to production topics is a separate controlled process.”

Combine that with audit logging, and you can replay exactly what an agent did, when, and under which identity.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
OIDC/SSO Integration	Connects Redpanda Console and services to your IdP for centralized auth	One set of identities and groups; no identity snowflakes
RBAC & Fine-Grained ACLs	Separates cluster-level rights from topic/group-level access	Clean split between platform teams and application teams
Audit Logging & Replay	Captures admin and agent actions as immutable logs	Compliance-ready history and debuggable production behavior

Ideal Use Cases

Best for platform teams standardizing multi-tenant streaming:
Because it lets you give each application team an isolated, governed namespace on a shared high-throughput cluster—without sacrificing Kafka compatibility or operational simplicity.
Best for AI and agentic workloads needing strict governance:
Because you can authenticate agents via OIDC, apply tool-level policies, and keep an immutable audit trail across streams and history, so you govern every action before it happens and can replay it later.

Limitations & Considerations

OIDC group mapping complexity:
If your IdP group model is messy, your Redpanda RBAC model will inherit that complexity. Consider creating Redpanda-specific groups (e.g., redpanda-*) to keep mappings clean.
ACL sprawl risk:
Without naming conventions and role-based defaults, ACLs can become hard to reason about. Use namespaces and patterns (team.*) and push most access control through roles rather than one-off exceptions.

Pricing & Plans

Redpanda offers a Community Edition and enterprise options designed for production, governed workloads.

At a high level:

Community Edition:
Best for developers and small teams needing Kafka-compatible streaming in dev/test. You get the “one binary, zero dependencies” experience to prototype your OIDC/RBAC model quickly before rolling into prod.
Enterprise / Managed (Platform):
Best for platform and data teams running mission-critical workloads with strict SLOs, compliance, and support requirements. You get enterprise security (RBAC, OIDC/Kerberos, TLS, fine-grained ACLs), audit logging, tiered storage, read replicas, continuous data balancing, SSO for Console, and 24x7 commercial support with SLAs.

For full plan details and deployment options (including BYOC and air-gapped), check the Redpanda site.

Frequently Asked Questions

How should I separate platform vs application access in Redpanda?

Short Answer:
Use IdP groups mapped to distinct RBAC roles: platform admins/operators get cluster and security privileges; application teams get namespaced topic and consumer group rights, enforced via ACLs.

Details:
Start by defining two main categories of roles:

Platform roles: platform-admin, platform-ops with permissions to manage clusters, security config, quotas, and global policies, plus read access for incident response.
Application roles: app-owner-* and app-readonly-* scoped to specific topic/consumer group patterns like payments.*.

Map your IdP groups to these roles using OIDC. Then implement ACLs to ensure an application role can only produce/consume within its namespace. This gives platform teams full control of the plane, while application teams safely operate within their lanes.

How do OIDC/SSO and RBAC help with compliance and audit?

Short Answer:
They give you identity-backed, least-privilege access to every action, plus a complete audit trail you can replay and inspect.

Details:
With OIDC/SSO, every human and service is tied to a real identity from your IdP. RBAC defines what that identity can change at the cluster level; ACLs define what data and tools they can touch. Redpanda’s audit logging records these actions using a FIPS-compliant binary and enterprise-grade security features. For AI agents and event-driven apps, this means you can reconstruct decisions, prove who did what and when, and shut down misbehaving agents using the same control plane that governs your streaming data.

Summary

When agents, apps, and humans all share the same streaming backbone, you need hard boundaries—not wishful thinking. In Redpanda, OIDC/SSO gives you a single identity fabric; RBAC and ACLs turn that into a clear separation between platform teams (who operate the plane) and application teams (who fly their workloads on it). Add audit logging and replay, and you can govern every action before it happens, then inspect what really occurred when something goes wrong.

This is how you move from prototype to production safely, without sacrificing Kafka compatibility or operational simplicity.

Next Step

Get Started