# Configure Access Control Lists

> For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt)

---
title: Configure Access Control Lists
latest-redpanda-tag: v26.1.9
latest-console-tag: v3.7.3
latest-operator-version: v26.1.4
# EOL = End-of-Life (support lifecycle status)
page-is-nearing-eol: "false"
page-is-past-eol: "false"
page-eol-date: March 31, 2027
latest-connect-version: 4.93.0
docname: security/authorization/acl
page-component-name: streaming
page-version: "26.1"
page-component-version: "26.1"
page-component-title: Streaming
page-relative-src-path: security/authorization/acl.adoc
page-edit-url: https://github.com/redpanda-data/docs/edit/main/modules/manage/pages/security/authorization/acl.adoc
description: Learn how to use ACLs to configure fine-grained access to Redpanda resources.
page-git-created-date: "2024-04-30"
page-git-modified-date: "2026-04-07"
support-status: supported
---

<!-- Source: https://docs.redpanda.com/streaming/current/manage/security/authorization/acl.md -->

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](https://raft.github.io/) to provide the same consensus guarantees as your data.

After you enable authorization, access to Redpanda resources is limited to superusers. To follow [security best practices](#acls-best-practices), create standard users and use ACLs to grant only the permissions they need for specific resources.

> 📝 **NOTE**
>
> For complex organizational hierarchies or large numbers of users, consider using [role-based access control](https://docs.redpanda.com/streaming/current/manage/security/authorization/rbac/) for a more flexible and efficient way to manage user permissions.

## [](#acls-overview)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)Manage ACLs

You can create and manage ACLs in the following ways:

-   **Redpanda Console**: 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`:

    ```bash
    # 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)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)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 Group-Based Access Control](https://docs.redpanda.com/streaming/current/manage/security/authorization/gbac/).

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.

> 💡 **TIP**
>
> 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:
>
> ```bash
> rpk security acl create --allow-principal="\"C=UK,ST=London,L=London,O=Redpanda,OU=engineering,CN=__schema_registry\""
> ```
>
> Alternatively, use single quotes:
>
> ```bash
> rpk security acl create --allow-principal='"C=UK,ST=London,L=London,O=Redpanda,OU=engineering,CN=__schema_registry"'
> ```

### [](#hosts)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)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`.


> ❗ **IMPORTANT**
>
> ACLs for Schema Registry must be enabled for each cluster. See [Schema Registry Authorization](https://docs.redpanda.com/streaming/current/manage/schema-reg/schema-reg-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

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


### [](#producingconsuming)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 topicsREAD on consumer group |
| Transactional producer | WRITE + DESCRIBE on target topicsWRITE on transactional ID |
| Consumer group admin | READ + DESCRIBE on target topicsREAD + DESCRIBE + DELETE on consumer groups |

Command examples:

```bash
# 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:

```bash
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`):

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

### [](#permissions)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)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)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)Manage ACLs with rpk

Use [`rpk security acl`](https://docs.redpanda.com/streaming/current/reference/rpk/rpk-security/rpk-security-acl/) to manage ACLs and SASL/SCRAM users from the command line.

On Kubernetes, you can use `kubectl exec` to run `rpk` commands.

### [](#basic-workflow)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:

```bash
# 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)Command overview

Here’s how `rpk` commands interact with Redpanda:

| Command | Protocol | Default port | Purpose |
| --- | --- | --- | --- |
| user | Admin API | 9644 | Manage SASL/SCRAM users |
| list | Kafka API | 9092 | View existing ACLs |
| create | Kafka API | 9092 | Create new ACLs |
| delete | Kafka API | 9092 | Remove ACLs |

### [](#global-flags)Global flags

Every [`rpk security acl`](https://docs.redpanda.com/streaming/current/reference/rpk/rpk-security/rpk-security-acl/) command can use these flags:

| Flag | Description |
| --- | --- |
| --admin-api-tls-cert | The certificate to be used for TLS authentication with the Admin API. |
| --admin-api-tls-enabled | Enable TLS for the Admin API (not necessary if specifying custom certificates). This is assumed as true when passing other --admin-api-tls flags. |
| --admin-api-tls-key | The certificate key to be used for TLS authentication with the Admin API. |
| --admin-api-tls-truststore | The truststore to be used for TLS communication with the Admin API. |
| -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)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.

```bash
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:

```bash
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:

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

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

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

### [](#list-and-delete-acls)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:

```bash
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)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`.

```bash
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)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.

To use GSSAPI, see [Enable Kerberos](https://docs.redpanda.com/streaming/current/manage/security/authentication/#kerberos).

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:

```bash
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)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).

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

### [](#user-list)User list

This command lists SASL users.

```bash
rpk security user list [globalACLFlags] [globalUserFlags]
```

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

## [](#suggested-reading)Suggested reading

-   [How to use data security with ACLs](https://redpanda.com/blog/built-in-security-with-acls/)


## Suggested labs

-   [Enable Unified Identity with Azure Entra ID for Redpanda and Redpanda Console](https://docs.redpanda.com/labs/docker-compose/oidc/)
-   [Migrate Data with Redpanda Migrator](https://docs.redpanda.com/labs/docker-compose/redpanda-migrator/)

[Search all labs](https://docs.redpanda.com/labs)