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

Most teams hit the same wall: platform engineering wants tight control over Redpanda clusters, while application teams just want to ship services and agents without learning every security knob. OIDC/SSO and RBAC are how you keep both groups productive without opening the door to chaos.

Below is a practical, production-focused way to set up OIDC, SSO, and RBAC in Redpanda for platform teams vs application teams—so you can govern access before anything happens and still move fast.

Note: Exact UI labels and config keys may differ slightly by version, but the architecture and role model stay the same.

The Quick Overview

What It Is: A reference pattern for configuring OIDC/SSO and RBAC in Redpanda so platform teams get cluster-wide control and application teams get scoped, least-privilege access.
Who It Is For: Platform, data, and security engineers responsible for securing Kafka-compatible streaming platforms and agentic workloads in Redpanda.
Core Problem Solved: Avoiding “one giant admin role” and over-permissive service accounts by clearly separating platform operations from application and agent access.

How It Works

At a high level, you’re doing three things:

Connect identity
Wire Redpanda into your enterprise IdP (Okta, Azure AD, Keycloak, etc.) using OIDC so both humans and agents authenticate with centralized identities.
Map identity to roles
Use SSO groups/claims from your IdP and map them to Redpanda roles using RBAC. Platform teams get broad, cluster-level privileges; application teams get scoped, topic- and tool-specific permissions.
Enforce least privilege everywhere
Apply fine-grained ACLs on topics, consumer groups, and tools (for agents) so application workloads and AI agents only see and change what they’re allowed to—and every action is auditable.

Step 1: Design your access model before you configure anything

You want to think in terms of personas and boundaries before touching YAML.

Personas
- Platform team
  - Owns clusters, storage tiers, security, networking, and global configuration.
  - Needs to create and manage topics, configure tiered storage, set quotas, manage read replicas, and perform day-two operations.
- Application teams
  - Own services, agents, and data contracts for their domains (payments, support, logistics, etc.).
  - Need scoped access to “their” topics and consumers, plus any cross-team streams explicitly shared.
Boundaries
- Platform team: full control of clusters and global settings.
- Application teams: constrained to namespaces (topic prefixes), consumer groups, and tools for AI agents.

Create a naming convention that encodes this boundary:

Topics like payments.*, support.*, fraud.*
Consumer group patterns like app-<team>-*
Agent tools named/scoped by domain: tool:payments-write, tool:support-read-customer-history

You’ll map these to RBAC and ACLs later.

Step 2: Configure OIDC and SSO in Redpanda

Redpanda supports OIDC for secure SSO, plus Kerberos if you’re in more traditional environments. OIDC is what unlocks clean, centralized identity for both platform and application teams.

2.1 Prepare your IdP (Okta, Azure AD, Keycloak, etc.)

In your IdP:

Register a new OIDC application for Redpanda Console and/or cluster access.
Configure:
- Redirect URI: https://<your-console-domain>/oauth/callback
- Grant type: Authorization Code (with PKCE if supported by your flow).
Collect:
- issuer URL (e.g., https://login.microsoftonline.com/<tenant>/v2.0)
- client_id
- client_secret
Define groups:
- redpanda-platform-admins
- redpanda-app-team-payments
- redpanda-app-team-support
- …and so on for each domain.

Make sure these groups are included in ID tokens as a claim (e.g., groups).

2.2 Configure OIDC in Redpanda / Redpanda Console

In your Redpanda console or cluster config, wire up OIDC:

oidc:
  enabled: true
  issuer: "https://your-idp-issuer-url/"
  client_id: "your-client-id"
  client_secret: "your-client-secret"
  redirect_uri: "https://your-console-domain/oauth/callback"
  scopes:
    - openid
    - profile
    - email
    - groups
  claim_mappings:
    username: "preferred_username"
    groups: "groups"

Key goals:

Every human user who logs into Redpanda Console comes via your IdP.
Group membership from the IdP is passed down to Redpanda so you can attach RBAC roles to those groups.

Now you’ve centralized identity. Next is controlling what those identities can actually do.

Step 3: Build an RBAC model for platform vs application teams

Redpanda supports role-based access control (RBAC) and fine-grained ACLs. You’ll use them together:

RBAC: attach high-level capabilities to groups (cluster vs app-level).
ACLs: pin permissions to specific topics, groups, and tools.

3.1 Define roles for platform teams

Create a role like platform-admin:

Capabilities:

Manage clusters, brokers, and storage:
- Create/delete topics
- Configure tiered storage
- Manage partitions and data balancing
- Configure read replicas
Manage security:
- Configure authentication (OIDC, Kerberos)
- Manage RBAC and ACLs
Day-two operations:
- Observe metrics (Prometheus)
- Access audit logs
- Trigger cluster balancing and maintenance

Conceptually:

roles:
  - name: platform-admin
    permissions:
      - manage:cluster
      - manage:topics
      - manage:quotas
      - manage:security
      - view:audit-logs
      - manage:connectors
      - manage:read-replicas

Then bind this to your IdP group:

role_bindings:
  - role: platform-admin
    groups:
      - "redpanda-platform-admins"

Platform engineers log in via SSO and automatically get this role.

3.2 Define roles for application teams

Each application team should get a domain-scoped role. Example: app-payments and app-support.

For app-payments:

roles:
  - name: app-payments
    permissions:
      - read:topics: "payments.*"
      - write:topics: "payments.*"
      - manage:consumer-groups: "app-payments-*"
      - view:metrics: "payments.*"

Bind it:

role_bindings:
  - role: app-payments
    groups:
      - "redpanda-app-team-payments"

For app-support:

roles:
  - name: app-support
    permissions:
      - read:topics: "support.*"
      - write:topics: "support.*"
      - read:topics: "customer-profile.*"   # if platform explicitly shares that domain
      - manage:consumer-groups: "app-support-*"

Binding:

role_bindings:
  - role: app-support
    groups:
      - "redpanda-app-team-support"

Platform team creates the roles and keeps ownership of the global boundary. App teams get SSO into Redpanda Console or CLI with just the privileges their group gives them.

Step 4: Layer fine-grained ACLs on top

RBAC gets you “who can do what generally.” ACLs get you “who can access this exact thing” in the streaming plane.

You’ll typically:

Use RBAC for console/admin capabilities.
Use ACLs for broker-level access (Kafka API-style).

4.1 ACL patterns for platform teams

Platform admins often need broad ACLs to bootstrap the system, but you should still keep identities clear.

Example: allow platform-admin principals to manage all topics:

rpk acl create \
  --allow \
  --operation all \
  --topic '*' \
  --principal User:platform-admin

Similarly for consumer groups:

rpk acl create \
  --allow \
  --operation all \
  --group '*' \
  --principal User:platform-admin

You might wrap this in automation to ensure you don’t accidentally give these permissions to non-admin identities.

4.2 ACL patterns for application teams

For the payments team:

# Produce to their domain topics
rpk acl create \
  --allow \
  --operation write \
  --topic 'payments.*' \
  --principal User:svc-payments

# Consume from their topics
rpk acl create \
  --allow \
  --operation read \
  --topic 'payments.*' \
  --group 'app-payments-*' \
  --principal User:svc-payments

For the support team:

rpk acl create \
  --allow \
  --operation read \
  --topic 'support.*' \
  --group 'app-support-*' \
  --principal User:svc-support

# Optional cross-domain read if approved
rpk acl create \
  --allow \
  --operation read \
  --topic 'customer-profile.*' \
  --group 'app-support-*' \
  --principal User:svc-support

Combine this with RBAC-bound human roles:

Humans log in via OIDC and see only the topics/consumer groups they’re allowed to manage.
Services and agents use service principals + ACLs to access the data plane.

Step 5: Integrate agents and enforce “govern before it happens”

Redpanda isn’t just a Kafka-compatible core. It’s an Agentic Data Plane. That means your RBAC model needs to cover not just topics and consumers, but tools and actions agents can take.

5.1 Identify agent tools and scopes

For application teams, define tools by domain and privilege:

payments-read-ledger – read-only access to payments streams.
payments-write-ledger – append-only writes to payments topics.
support-read-history – read-only view over support events and customer history.

Each tool maps to:

Specific topics
Optional SQL queries across streams + historical records
Policies for redaction/filtering

5.2 Apply RBAC to tools, not just topics

Extend the application team roles:

roles:
  - name: app-payments
    permissions:
      - use:tool: "payments-read-ledger"
      - use:tool: "payments-write-ledger"
      - read:topics: "payments.*"
      - write:topics: "payments.*"

For support:

roles:
  - name: app-support
    permissions:
      - use:tool: "support-read-history"
      - read:topics: "support.*"
      - read:topics: "customer-profile.redacted.*"

Now agents operated by those teams:

Authenticate via OIDC (or on-behalf-of flows).
Get a scoped agent identity.
Are restricted to the toolset and data plane access granted by their role.

You’ve moved from “agents can call whatever they want” to “agents can only use tools pre-approved for that team and domain.”

Step 6: Separate platform vs application workflows in practice

Here’s how this looks day-to-day.

6.1 Platform team workflow

Uses SSO via redpanda-platform-admins.
Manages:
- Cluster sizing, brokers, and storage tiers (including tiered storage).
- Continuous data and partition balancing.
- Remote read replicas for analytics.
- Security posture: OIDC, Kerberos, TLS, RBAC, ACLs.
- Observability via Prometheus and OTel.
- Audit logging and compliance reporting (FIPS-compliant binary, RBAC enforcement, log export).

Platform team is effectively managing the plane: operational, secure, reliable.

6.2 Application team workflow

Team members use SSO via their domain group.
They can:
- View and manage only their domain topics and consumer groups.
- Configure and observe domain-specific streams and agents.
- Use tools and SQL queries over streams + history allowed by their role.

App teams build in “single-player mode” (their domain) while platform ensures the whole system stays “multiplayer-safe” (cross-team collisions, least privilege, budgets, compliance).

Best-practice patterns and guardrails

To keep this maintainable at scale:

Prefix everything.
Topics, consumer groups, roles, and tools should encode team and domain: payments.*, role:app-payments, tool:payments-read-ledger.
Automate role and ACL creation.
Use Terraform or GitOps around Redpanda security configs so platform teams don’t manually click-ops RBAC rules.
Default-deny stance.
No role → no access. No ACL → no broker access. This aligns well with compliance and audit expectations.
Use audit logging.
Turn on audit logs so every interaction is captured: who accessed which topic, which agent used which tool, which policies were applied.
Separate human and service principals.
Humans come through OIDC/SSO with group-based roles. Services and agents use dedicated service identities with minimal ACLs.

Summary

To set up OIDC/SSO and RBAC in Redpanda for platform teams vs application teams, you:

Connect identity via OIDC/SSO.
Plug Redpanda into your IdP so every human and agent runs with a central, auditable identity.
Split roles by persona.
Platform gets platform-admin–style roles for cluster and security control. App teams get domain-scoped roles like app-payments or app-support.
Enforce least privilege with RBAC + ACLs.
RBAC defines what a group can do; ACLs define what a principal can touch in the Kafka-compatible plane.
Extend the model to agents and tools.
Agents authenticate via OIDC, run with scoped tools, and are governed before they act—so they can use and change data without risking chaos.

You end up with an agentic, Kafka-compatible streaming backbone where platform teams control the plane, and application teams safely build on top of it.

Next Step

Get Started(https://redpanda.com)