Choose an Authorization Model
Redpanda Cloud authorizes access in two places, and the model you choose depends on which one you are securing. Granting a team access to a production cluster is a different decision from granting an application write access to one topic. This page maps the options to those decisions so you can pick a model before you start configuring it.
After reading this page, you will be able to:
-
Compare control plane and data plane authorization in Redpanda Cloud
-
Choose whether to attach data plane permissions directly, through roles, or through identity provider groups
-
Explain how Redpanda evaluates ACLs, roles, and groups together
Two planes, two authorization systems
Authorization follows the split between the control plane and the data plane:
-
Control plane: who can manage your organization’s resources, such as clusters, resource groups, networks, and network peering connections. You grant this access with roles and role bindings.
-
Data plane: who can read and write your streaming data, such as topics, consumer groups, transactional IDs, and Schema Registry subjects. Every permission here is ultimately an access control list (ACL). The control plane does not use ACLs.
Most organizations need both. A platform administrator who provisions clusters needs control plane access; an application that produces to a topic needs data plane access. For how these planes fit into the wider security model, see Redpanda Cloud Security Overview.
Choose how to attach data plane permissions
In the data plane, ACLs are the primitive. You can name a user directly in an ACL, or you can attach ACLs to a group of users through role-based access control (RBAC) or group-based access control (GBAC). Roles and identity provider groups are not alternatives to ACLs; they are different ways of attaching ACLs to a set of users. A role is a named collection of ACLs, and you grant a role its permissions by creating an ACL that names the role as allowed or denied.
This matters for your decision. All three options below produce the same permission granularity, so choose based on how you want to manage membership, not on how fine-grained the access needs to be.
| Dimension | Direct ACL | Role (RBAC) | Identity provider group (GBAC) |
|---|---|---|---|
Principal |
|
|
|
Who manages membership |
Not applicable; the permission names one user |
You, in Redpanda Cloud |
Your identity provider |
Assignment unit |
One user |
One role, any number of users |
One group, any number of users |
Permission granularity |
Any ACL rule |
Any ACL rule |
Any ACL rule |
Onboarding and offboarding |
Edit ACLs for each user |
Assign or unassign the role in Redpanda Cloud |
Change group membership in your identity provider, which takes effect at the user’s next sign-in |
Scales to thousands of users |
No |
Yes, if users share a small number of roles |
Yes |
Cluster types |
All |
BYOC and Dedicated |
BYOC and Dedicated |
When to use direct ACLs
Use a direct ACL when the principal is a single long-lived identity whose permissions rarely change, such as one application’s service account that produces to one topic. Direct ACLs are also your only option on Serverless clusters, which do not support RBAC in the data plane or GBAC.
Avoid direct ACLs as your primary model for human users. Permissions accumulate per user, and offboarding means finding and removing every rule that names that person.
When to use roles
Use a role when several users need the same permissions and you manage those users in Redpanda Cloud. Change the role’s ACLs once and every user assigned to it picks up the change. This is the right default for a team that does not have an identity provider wired up, or whose identity provider does not emit group claims.
When to use identity provider groups
Use groups when you already run an identity provider with groups that model your teams. Redpanda reads the group claim from the OIDC token at sign-in, so joiners and leavers are handled entirely in your identity provider with no change in Redpanda. This is the model that scales furthest, and it keeps access reviews in the system your auditors already look at.
Groups can carry permissions two ways, and you can use both:
-
Name the group directly in an ACL with a
Group:<name>principal. -
Assign the group as a member of a role, so everyone in the group inherits that role’s ACLs.
Groups require single sign-on. Before you commit to this model, check the limitations that depend on your identity provider: Redpanda cannot resolve groups for a user with more than 200 Azure AD group memberships, it does not resolve nested group hierarchies, and Group: principals in ACLs match literal names with no wildcard support.
When to combine models
Combining models is normal, not an edge case. A common pattern is groups for broad team access plus a small number of direct ACLs for exceptions.
Redpanda evaluates every source of permissions in one flow: user ACLs, role ACLs, group ACLs, and the ACLs a group inherits through a role. Deny rules are checked first across all sources, so any matching deny rejects the request regardless of what other sources allow. If no deny matches, Redpanda looks for an allow, and denies the request if it finds none.
Because deny wins and the default is deny, you can grant broadly through a group or role and then carve out exceptions with a targeted deny rule.
Control plane access
In the control plane you grant access by binding a role to an account. An account is either a user or a service account, and a role binding can be scoped to resources including your organization, a resource group, a network, a network peering connection, a cluster, or an MCP server. A user can hold several roles at once when each binding applies to a different scope.
Redpanda Cloud includes predefined roles such as Reader, Writer, and Admin, which you cannot modify or delete. For least privilege, create a custom role instead and grant only the permissions the account needs, selecting from the Control Plane, Data Plane, IAM, and Billing permission categories.
Identity provider groups work here too: register a group and assign roles to it, so control plane access follows group membership the same way data plane access does.
BYOC agent authorization
Cloud IAM policies are not a model you choose. When you run rpk cloud byoc <provider> apply to provision a BYOC cluster, you grant IAM permissions to the agent that manages your cluster infrastructure, and those permissions authorize the agent alone.
| IAM policies do not apply to human users, and you never invoke them directly. They exist so Redpanda agents can manage cluster infrastructure in your cloud account. |
On a BYOVPC cluster (BYOVNet on Azure), you supply the identity that the agent uses and you manage its permissions yourself, so the policies below do not apply.
