Cloud

Configure ACLs

Access control lists (ACLs) provide a way to configure fine-grained access to Redpanda resources. ACLs are permission rules that determine which actions users or roles can perform on Redpanda resources. Redpanda stores ACLs internally, replicated with Raft to provide the same consensus guarantees as your data.

For complex organizational hierarchies or large numbers of users, consider using role-based access control for a more flexible and efficient way to manage user permissions.

ACLs overview

ACLs control access by defining:

  • Who can access resources (principals - users or roles)

  • What they can access (clusters, topics, consumer groups, transactional IDs, Schema Registry subjects, and Schema Registry operations)

  • How they can interact with those resources (operations like read, write, describe)

  • Where they can connect from (host restrictions)

ACLs work with SASL/SCRAM and mTLS authentication methods to provide comprehensive security.

Manage ACLs

You can create and manage ACLs in the following ways:

  • Redpanda Cloud: Select Security from the left navigation menu, select the ACLs tab. After the ACL is created, you can add users or roles to it.

  • Command Line: Use the rpk command-line tool for programmatic management.

    For example, suppose you want to create a user named analytics-user who can read from topics starting with logs- and write to a topic called processed-data:

    # 1. Create the user
rpk security user create analytics-user --password 'secure-password'

# 2. Grant read access to topics with "logs-" prefix
rpk security acl create --allow-principal analytics-user \
  --operation read,describe --topic 'logs-' \
  --resource-pattern-type prefixed

# 3. Grant write access to the processed-data topic
rpk security acl create --allow-principal analytics-user \
  --operation write,describe --topic processed-data

ACL terminology

Understanding these terms helps you configure least-privilege access.

Term Definition Example

Principal

The entity (user, role, or group) requesting access

User:analytics-user, RedpandaRole:data-engineers, Group:engineering

Resource

The Redpanda component being accessed (cluster, topic, consumer group, transactional ID, Schema Registry subject, and Schema Registry operation)

Topic: sensor-data, Group: analytics-group, Cluster: kafka-cluster

Operation

The action being performed on the resource

READ, WRITE, CREATE, DELETE, DESCRIBE

Host

The IP address or hostname from which access is allowed/denied

192.168.1.100, * (any host)

Permission

Whether access is allowed or denied

ALLOW, DENY

An ACL rule combines these elements to create a permission statement:

ALLOW User:analytics-user to READ topic:sensor-data from host:192.168.1.100

ACL commands work on a multiplicative basis. If you specify two principals and two permissions, you create four ACLs: both permissions for each principal.

Principals

All ACLs require a principal. A principal is composed of two parts: the type, and the name. Redpanda supports the types "User", "RedpandaRole", and "Group". When you create user "bar", Redpanda expects you to add ACLs for "User:bar". To grant permissions to an OIDC group, use the Group: prefix (for example, Group:engineering). See Configure GBAC in the Data Plane.

The --allow-principal and --deny-principal flags add this prefix for you, if necessary.

The special character * matches any name, meaning an ACL with principal User:* grants or denies the permission for any user.

To set multiple principals in a single comma-separated string, you must enclose the string with quotes. Otherwise, rpk splits the string on commas and fails to read the option correctly.

For example, use double quotes:

rpk security acl create --allow-principal="\"C=UK,ST=London,L=London,O=Redpanda,OU=engineering,CN=__schema_registry\""

Alternatively, use single quotes:

rpk security acl create --allow-principal='"C=UK,ST=London,L=London,O=Redpanda,OU=engineering,CN=__schema_registry"'

Hosts

Hosts can be seen as an extension of the principal and can effectively gate where the principal can connect from. When creating ACLs, unless otherwise specified, the default host is the wildcard *, which allows or denies the principal from all hosts.

When specifying hosts, you must pair the --allow-host flag with the --allow-principal flag and the --deny-host flag with the --deny-principal flag.

Resources

A resource is what an ACL allows or denies access to. The following resources are available within Redpanda:

  • cluster

  • topics

  • groups

  • transactionalid

Starting in v25.2, Redpanda also supports the following ACL resources for Schema Registry:

  • subject: Controls ACL access for specific Schema Registry subjects. Specify using the flag --registry-subject.

  • registry: Controls whether or not to grant ACL access to global, or top-level Schema Registry operations. Specify using the flag --registry-global.

ACLs for Schema Registry must be enabled for each cluster. See Schema Registry Authorization.

Resources combine with the operation that is allowed or denied on that resource. By default, resources are specified on an exact name match (a "literal" match).

Names for each of these resources can be specified with their respective flags.

Use the --resource-pattern-type flag to specify that a resource name is "prefixed", meaning to allow anything with the given prefix. A literal name of "foo" matches only the topic "foo", while the prefixed name of "foo-" matches both "foo-bar" and "foo-jazz". The special wildcard resource name '*' matches any name of the given resource type (--topic '*' matches all topics).

Operations

Operations define what actions are allowed or denied on resources. Here are the available operations with common use cases:

Operation Description Common use case

READ

Allows reading data from a resource

Consumers reading from topics, fetching consumer group offsets

WRITE

Allows writing data to a resource

Producers publishing messages to topics

CREATE

Allows creating new resources

Auto-creating topics, creating new consumer groups

DELETE

Allows deleting resources

Removing topics, deleting consumer groups

DESCRIBE

Allows querying resource metadata

Listing topics, getting topic configurations

ALTER

Allows modifying resource properties

Changing topic partition counts, updating consumer group settings

DESCRIBE_CONFIGS

Allows viewing resource configurations

Reading topic settings, broker configurations

ALTER_CONFIGS

Allows modifying resource configurations

Changing topic retention policies, updating broker settings

IDEMPOTENT_WRITE

Allows idempotent produce semantics initialization

Required for idempotent producers (InitProducerID)

ALL

Grants all operations above

Administrative access to resources

Common combinations:

  • Producer: WRITE + DESCRIBE on topics

  • Consumer: READ + DESCRIBE on topics, READ on consumer groups

  • Admin: ALL on cluster and specific resources

Producing/Consuming

For quick reference, here are the ACL requirements for common client scenarios:

Client type Required ACLs

Simple producer

  • WRITE + DESCRIBE on target topics

Simple consumer

  • READ + DESCRIBE on target topics

  • READ on consumer group

Transactional producer

  • WRITE + DESCRIBE on target topics

  • WRITE on transactional ID

Consumer group admin

  • READ + DESCRIBE on target topics

  • READ + DESCRIBE + DELETE on consumer groups

Command examples:

# Basic producer access
rpk security acl create --allow-principal producer-user \
  --operation write,describe --topic my-topic

# Basic consumer access
rpk security acl create --allow-principal consumer-user \
  --operation read,describe --topic my-topic
rpk security acl create --allow-principal consumer-user \
  --operation read --group my-consumer-group

The following operations are necessary for each individual client request, where resource corresponds to the resource flag, and "for xyz" corresponds to the resource names in the request.

Show operations 
PRODUCING/CONSUMING

    Produce      WRITE on TOPIC for topics
                 WRITE on TRANSACTIONAL_ID for the transaction.id

    Fetch        READ on TOPIC for topics

    ListOffsets  DESCRIBE on TOPIC for topics

    Metadata     DESCRIBE on TOPIC for topics
                 CREATE on CLUSTER for kafka-cluster (if automatically creating topics)
                 or, CREATE on TOPIC for topics (if automatically creating topics)

    InitProducerID  IDEMPOTENT_WRITE on CLUSTER
                    or, WRITE on any TOPIC
                    or, WRITE on TRANSACTIONAL_ID for transactional.id (if using transactions)

    OffsetForLeaderEpoch  DESCRIBE on TOPIC for topics

GROUP CONSUMING

    FindCoordinator  DESCRIBE on GROUP for group
                     DESCRIBE on TRANSACTIONAL_ID for transactional.id (transactions)

    OffsetCommit     READ on GROUP for groups
                     READ on TOPIC for topics

    OffsetFetch      DESCRIBE on GROUP for groups
                     DESCRIBE on TOPIC for topics

    OffsetDelete     DELETE on GROUP for groups
                     READ on TOPIC for topics

    JoinGroup        READ on GROUP for group
    Heartbeat        READ on GROUP for group
    LeaveGroup       READ on GROUP for group
    SyncGroup        READ on GROUP for group

TRANSACTIONS (including FindCoordinator above)

    AddPartitionsToTxn  WRITE on TRANSACTIONAL_ID for transactional.id
                        WRITE on TOPIC for topics

    AddOffsetsToTxn     WRITE on TRANSACTIONAL_ID for transactional.id
                        READ on GROUP for group

    EndTxn              WRITE on TRANSACTIONAL_ID for transactional.id

    TxnOffsetCommit     WRITE on TRANSACTIONAL_ID for transactional.id
                        READ on GROUP for group
                        READ on TOPIC for topics

ADMIN

    CreateTopics      CREATE on CLUSTER for kafka-cluster
                      CREATE on TOPIC for topics
                      DESCRIBE_CONFIGS on TOPIC for topics,
                      for returning topic configs on create

    CreatePartitions  ALTER on TOPIC for topics

    DeleteTopics      DELETE on TOPIC for topics
                      DESCRIBE on TOPIC for topics, if deleting by topic ID
                      (in addition to prior ACL)

    DeleteRecords     DELETE on TOPIC for topics

    DescribeGroup     DESCRIBE on GROUP for groups

    ListGroups        DESCRIBE on GROUP for groups
                      or, DESCRIBE on CLUSTER for kafka-cluster

    DeleteGroups      DELETE on GROUP for groups

    DescribeConfigs   DESCRIBE_CONFIGS on CLUSTER for cluster (broker describing)
                      DESCRIBE_CONFIGS on TOPIC for topics (topic describing)

    AlterConfigs      ALTER_CONFIGS on CLUSTER for cluster (broker altering)
                      ALTER_CONFIGS on TOPIC for topics (topic altering)

    AlterPartitionAssignments   ALTER on CLUSTER for kafka-cluster
    ListPartitionReassignments  DESCRIBE on CLUSTER for kafka-cluster

    AlterReplicaLogDirs    ALTER on CLUSTER for kafka-cluster
    DescribeLogDirs        DESCRIBE on CLUSTER for kafka-cluster

    AlterClientQuotas      ALTER on CLUSTER for kafka-cluster
    DescribeClientQuotas   DESCRIBE_CONFIGS on CLUSTER for kafka-cluster

    AlterUserScramCreds    ALTER on CLUSTER for kafka-cluster
    DescribeUserScramCreds DESCRIBE_CONFIGS on CLUSTER for kafka-cluster

    DescribeProducers      READ on TOPIC for topics
    DescribeTransactions   DESCRIBE on TRANSACTIONAL_ID for transactional.id
                           DESCRIBE on TOPIC for topics
    ListTransactions       DESCRIBE on TRANSACTIONAL_ID for transactional.id

 REGISTRY

    GetGlobalConfig         DESCRIBE_CONFIGS on REGISTRY for schema registry
    UpdateGlobalConfig      ALTER_CONFIGS on REGISTRY for schema registry

    GetGlobalMode           DESCRIBE_CONFIGS on REGISTRY for schema registry
    UpdateGlobalMode        ALTER_CONFIGS on REGISTRY for schema registry

    GetReferencedBy         DESCRIBE on REGISTRY for schema registry
    ListSchemasForId        DESCRIBE on REGISTRY for schema registry

    ListSchemaTypes         (no ACLs required)
    HealthCheck             (no ACLs required)

 SUBJECT

    ListSubjects            DESCRIBE on SUBJECT for subject

    CheckSchema             READ on SUBJECT for subject
    RegisterSchema          WRITE on SUBJECT for subject

    GetSchemaByVersion      READ on SUBJECT for subject
    GetSchemaRaw            READ on SUBJECT for subject

    ListSubjectVersions     DESCRIBE on SUBJECT for subject

    DeleteSchemaVersion     DELETE on SUBJECT for subject
    DeleteSubject           DELETE on SUBJECT for subject

    GetSubjectConfig        DESCRIBE_CONFIGS on SUBJECT for subject
    UpdateSubjectConfig     ALTER_CONFIGS on SUBJECT for subject
    DeleteSubjectConfig     ALTER_CONFIGS on SUBJECT for subject

    GetSubjectMode          DESCRIBE_CONFIGS on SUBJECT for subject
    UpdateSubjectMode       ALTER_CONFIGS on SUBJECT for subject
    DeleteSubjectMode       ALTER_CONFIGS on SUBJECT for subject

    CheckCompatibility      READ on SUBJECT for subject

    GetSchemaById           READ on SUBJECT for subject

To get this information with rpk, run:

rpk security acl --help-operations

In flag form to set up a general producing/consuming client, you can invoke rpk security acl create up to three times with the following (including your --allow-principal):

--operation write,read,describe --topic [topics]
--operation describe,read --group [group.id]
--operation describe,write --transactional-id [transactional.id]

Permissions

A client can be allowed access or denied access. By default, all permissions are denied. You only need to specifically deny a permission if you allow a wide set of permissions and then want to deny a specific permission in that set. You could allow all operations, and then specifically deny writing to topics.

Management

Commands for managing users and ACLs work on a specific ACL basis, but listing and deleting ACLs works on filters. Filters allow matching many ACLs to be printed, listed, and deleted at the same time. Because this can be risky for deleting, the delete command prompts for confirmation by default.

ACLs best practices

Follow these recommendations for secure and manageable ACL configurations.

Security best practices:

  • Principle of least privilege: Grant only the minimum permissions required for each user or role

  • Avoid wildcards: Use specific resource names instead of * whenever possible

  • Separate environments: Use different principals for development, staging, and production

  • Regular audits: Periodically review and clean up unused ACLs

Management best practices:

  • Use descriptive names: Choose clear user and topic names that indicate their purpose

  • Group related permissions: Create roles for users with similar access patterns

  • Document ACL decisions: Keep records of why specific permissions were granted

Common pitfalls to avoid

  • Over-privileging: Granting ALL operations when specific ones would suffice

  • Forgetting consumer groups: Not granting necessary group permissions for consumers

  • Host restrictions: Accidentally blocking legitimate client connections with overly restrictive host rules

  • Pattern confusion: Mixing up literal vs. prefixed resource pattern types

  • Test ACLs: Verify permissions work as expected before deploying to production

Manage ACLs with rpk

Use rpk security acl to manage ACLs and SASL/SCRAM users from the command line.

Basic workflow

Follow this typical workflow when setting up ACLs:

  1. Create a user: rpk security user create <username> --password '<password>'

  2. Create ACLs: rpk security acl create --allow-principal <username> --operation <ops> --topic <topic>

  3. Verify access: rpk security acl list --allow-principal <username>

Example setup:

# 1. Create user
rpk security user create data-processor \
  --password 'secure-password' \
  -X admin.hosts=localhost:9644

# 2. Grant topic access
rpk security acl create --allow-principal data-processor \
  --operation read,write,describe --topic 'data-*' \
  --resource-pattern-type prefixed

# 3. Grant consumer group access
rpk security acl create --allow-principal data-processor \
  --operation read,describe --group data-processing-group

# 4. Verify the setup
rpk security acl list --allow-principal data-processor

Command overview

Here’s how rpk commands interact with Redpanda:

Command

Protocol

Default port

Purpose

list

Kafka API

9092

View existing ACLs

create

Kafka API

9092

Create new ACLs

delete

Kafka API

9092

Remove ACLs

Global flags

Every rpk security acl command can use these flags:

Flag

Description

-X brokers

Comma-separated list of broker ip:port pairs (for example, --brokers '192.168.78.34:9092,192.168.78.35:9092,192.179.23.54:9092' ). Alternatively, you can set the RPK_BROKERS environment variable with the comma-separated list of broker addresses.

--config

Redpanda configuration file. If not set, the file is searched in the default locations.

-h, --help

Help.

--password

SASL password to be used for authentication.

--sasl-mechanism

The authentication mechanism to use. Supported values: SCRAM-SHA-256, SCRAM-SHA-512.

--tls-cert

The certificate to be used for TLS authentication with the broker.

--tls-enabled

Enable TLS for the Kafka API (not necessary if specifying custom certificates). This is assumed to be true when passing other --tls flags.

--tls-key

The certificate key to be used for TLS authentication with the broker.

--tls-truststore

The truststore to be used for TLS communication with the broker.

--user

SASL user to be used for authentication.

Create ACLs

With the create command, every ACL combination is a created ACL. At least one principal, one host, one resource, and one operation are required to create a single ACL.

rpk security acl create/delete [globalACLFlags] [localFlags]

You can use the global flags and some other local flags. Following are the available local flags:

Flag Description

--allow-host

Host for which access will be granted (repeatable).

--allow-principal

Principals to which permissions will be granted (repeatable).

--allow-role

Role to which permissions will be granted (repeatable).

--cluster

Whether to grant ACLs to the cluster.

--deny-host

Host from which access will be denied (repeatable).

--deny-principal

Principal to which permissions will be denied (repeatable).

--deny-role

Role to which permissions will be denied (repeatable).

--group

Group to grant ACLs for (repeatable).

-h, --help

Help.

--name-pattern

The name pattern type to be used when matching the resource names.

--operation

Operation that the principal will be allowed or denied. Can be passed many times.

--resource-pattern-type

Pattern to use when matching resource names (literal or prefixed) (default "literal").

--topic

Topic to grant ACLs for (repeatable).

--transactional-id

Transactional IDs to grant ACLs for (repeatable).

--registry-subject

Schema Registry subject to grant ACLs for (repeatable).

--registry-global

Grants ACLs for global Schema Registry operations (no name required).

Examples:

To allow all permissions to user bar on topic "foo" and group "g", run:

rpk security acl create --allow-principal bar --operation all --topic foo --group g

To allow read permissions to all users on topics biz and baz, run:

rpk security acl create --allow-principal '*' --operation read --topic biz,baz

To allow write permissions to user buzz to transactional id "txn", run:

rpk security acl create --allow-principal User:buzz --operation write --transactional-id txn

List and delete ACLs

List and delete for ACLs have a multiplying effect (similar to create ACL), but delete is more advanced. List and delete work on a filter basis. Any unspecified flag defaults to matching everything (all operations, or all allowed principals, and so on).

To ensure that you don’t accidentally delete more than you intend, this command prints everything that matches your input filters and prompts for a confirmation before the delete request is issued. Anything matching more than 10 ACLs also asks for confirmation.

If no resources are specified, all resources are matched. If no operations are specified, all operations are matched.

You can opt in to matching everything. For example, --operation any matches any operation.

The --resource-pattern-type, defaulting to any, configures how to filter resource names:

  • any returns exact name matches of either prefixed or literal pattern type

  • match returns wildcard matches, prefix patterns that match your input, and literal matches

  • prefix returns prefix patterns that match your input (prefix "fo" matches "foo")

  • literal returns exact name matches

To list or delete ACLs, run:

rpk security acl list/delete [globalACLFlags] [localFlags]

You can use the global flags and some other local flags. Following are the available local flags:

Flag Description

--allow-host

Allowed host ACLs to list/remove. (repeatable)

--allow-principal

Allowed principal ACLs to list/remove. (repeatable)

--cluster

Whether to list/remove ACLs to the cluster.

--deny-host

Denied host ACLs to list/remove. (repeatable)

--deny-principal

Denied principal ACLs to list/remove. (repeatable)

-d, --dry

Dry run: validate what would be deleted.

--group

Group to list/remove ACLs for. (repeatable)

-h, --help

Help.

--no-confirm

Disable confirmation prompt.

--operation

Operation to list/remove. (repeatable)

-f, --print-filters

Print the filters that were requested. (failed filters are always printed)

--resource-pattern-type

Pattern to use when matching resource names. (any, match, literal, or prefixed) (default "any")

--topic

Topic to list/remove ACLs for. (repeatable)

--transactional-id

Transactional IDs to list/remove ACLs for. (repeatable)

--registry-subject

Schema Registry subject(s) to list/remove ACLs for. (repeatable)

--registry-global

Match ACLs for global Schema Registry operations.

User

This command manages the SCRAM users. If SASL is enabled, a SCRAM user talks to Redpanda, and ACLs control what your user has access to. Using SASL requires setting kafka_enable_authorization: true in the Redpanda section of your redpanda.yaml.

rpk security user [command] [globalACLFlags] [globalUserFlags]

Following are the available global user flags:

Flag

Description

Supported Value

-X admin.hosts

The comma-separated list of IP addresses (IP:port). You must specify one for each broker.

strings

-h, --help

-h, --help

Help.

User create

This command creates a single SASL/SCRAM user with the given password, and optionally with a custom mechanism. The mechanism determines which authentication flow the client uses for this user/password. Redpanda rpk supports the following mechanisms: SCRAM-SHA-256 (default) and SCRAM-SHA-512, which is the same flow but uses sha512.

Before a created SASL account can be used, you must also create ACLs to grant the account access to certain resources in your cluster.

To create a SASL/SCRAM user, run:

rpk security user create [user] -p [password] [globalACLFlags] [globalUserFlags] [localFlags]

Here are the local flags:

Flag Description

-h, --help

Help.

--mechanism

SASL mechanism to use: scram-sha-256 or scram-sha-512. Default is scram-sha-256.

User delete

This command deletes the specified SASL account from Redpanda. This does not delete any ACLs that may exist for this user. You may want to re-create the user later, as well, not all ACLs have users that they describe (instead they are for wildcard users).

rpk security user delete [USER] [globalACLFlags] [globalUserFlags]

User list

This command lists SASL users.

rpk security user list [globalACLFlags] [globalUserFlags]

You can also use the shortened version changing list to ls.