# rpk security acl > 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: rpk security acl latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "true" page-eol-date: April 30, 2025 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 docname: rpk/rpk-security/rpk-security-acl page-component-name: streaming page-version: "24.1" page-component-version: "24.1" page-component-title: Streaming page-relative-src-path: rpk/rpk-security/rpk-security-acl.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/24.1/modules/reference/pages/rpk/rpk-security/rpk-security-acl.adoc description: These commands let you create SASL users and create, list, and delete ACLs. page-git-created-date: "2024-04-30" page-git-modified-date: "2024-07-24" support-status: past end-of-life --- Manage ACLs and SASL users. These commands let you create SASL users and create, list, and delete ACLs. The help text below is specific to ACLs. To learn about SASL users, see the help text under the `user` command. When using SASL, ACLs allow or deny you access to certain requests. The `create`, `delete`, and `list` commands help you manage your ACLs. An ACL is made up of five components: - a principal (the user) or role - a host, which the principal (or role) is allowed or denied requests from - what resource to access (such as topic name, group ID) - the operation (such as read, write) - the permission (whether to allow or deny the above) ACL commands work on a multiplicative basis. If creating, specifying two principals and two permissions creates four ACLs: both permissions for the first principal, as well as both permissions for the second principal. Adding two resources further doubles the ACLs created. It is recommended to be as specific as possible when granting ACLs. Granting more ACLs than necessary per principal may inadvertently allow clients to do things they should not, such as deleting topics or joining the wrong consumer group. > 💡 **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"' > ``` ## [](#principals)Principals All ACLs require a principal or a role. A principal is composed of a user and a type. Within Redpanda, only the "User" type is supported. Having prefixes for new types ensures that potential future authorizers can add authorization using other types, such as "Group". When you create a user, you need to add ACLs for it before it can be used. You can create/delete/list ACLs for that user with either `User:bar` or `bar` in the `--allow-principal` and `--deny-principal` flags. This command will add the `User:` prefix for you if it is missing. The wildcard `*` matches any user. Creating an ACL with user `*` grants or denies the permission for all users. ## [](#hosts)Hosts Hosts can be seen as an extension of the principal, and 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 (where allow & deny are based on whether `--allow-principal` or `--deny-principal` is used). If specifying hosts, you must pair the `--allow-host` flag with the `--allow-principal` flag, and the `--deny-host` flag with the `--deny-principal` flag. ## [](#roles)Roles You can bind ACLs to a role. A role has only one part: the name. In contrast to principals, there is no need to supply the type. If a type-like prefix is present, it is treated as text rather than as principal type information. When you create a role, you must bind or associate ACLs to it before it can be used. You can create / delete / list ACLs for that role with "" in the `--allow-role` and `--deny-role` flags. Note that the wildcard role name **is not permitted here. For example `rpk security acl create --allow-role '`**`' …​` will produce an error. ## [](#resources)Resources A resource is what an ACL allows or denies access to. There are four resources within Redpanda: topics, groups, the cluster itself, and transactional IDs. Names for each of these resources can be specified with their respective flags. Resources combine with the operation that is allowed or denied on that resource. The next section describes which operations are required for which requests, and further fleshes out the concept of a resource. By default, resources are specified on an exact name match (a `literal` match). The --resource-pattern-type flag can be used to specify that a resource name is `prefixed`, meaning to allow anything with the given prefix. A literal name of `foo` will match only the topic `foo`, while the prefixed name of `foo-` will match both `foo-bar` and `foo-baz`. The special wildcard resource name `*` matches any name of the given resource type (--topic `*` matches all topics). ## [](#operations)Operations Pairing with resources, operations are the actions that are allowed or denied. Redpanda has the following operations: | Operation | Description | | --- | --- | | all | Allows all operations below. | | read | Allows reading a given resource. | | write | Allows writing to a given resource. | | create | Allows creating a given resource. | | delete | Allows deleting a given resource. | | alter | Allows altering non-configurations. | | describe | Allows querying non-configurations. | | describe_configs | Allows describing configurations. | | alter_configs | Allows altering configurations. | You can run `rpk security acl --help-operations` to see which operations are required for which requests. In flag form to set up a general producing/consuming client, you can invoke `rpk security acl create` three times with the following (including your `--allow-principal`): `rpk security acl create --operation write,read,describe --topic [topics]` `rpk security acl create --operation describe,read --group [group.id]` `rpk security acl create --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 Creating ACLs works 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 once. Because this can be risky for deleting, the delete command prompts for confirmation by default. More details and examples for creating, listing, and deleting can be seen in each of the commands. Using SASL requires setting `enable_sasl: true` in the redpanda section of your `redpanda.yaml`. User management is a separate, simpler concept that is described in the user command. ## [](#usage)Usage ```bash rpk security acl [command] [flags] ``` ## [](#flags)Flags | Value | Type | Description | | --- | --- | --- | | -h, --help | - | Help for acl. | | --help-operations | - | Print more help about ACL operations. | | --config | string | Redpanda or rpk config file; default search paths are /var/lib/redpanda/.config/rpk/rpk.yaml, $PWD/redpanda.yaml, and /etc/redpanda/redpanda.yaml. | | -X, --config-opt | stringArray | Override rpk configuration settings. See rpk -X or execute rpk -X help for inline detail or rpk -X list for terser detail. | | --profile | string | Profile to use. See rpk profile for more details. | | -v, --verbose | - | Enable verbose logging. |