rpk acl

All ACLs require a principal. A principal is composed of two parts: the type and the name. Within Redpanda, only one type is supported, User. The reason for the prefix is that a potential future authorizer may add support for authorizing by Group or anything else.

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 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.

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

Pairing with resources, operations are the actions that are allowed or denied. Redpanda has the following operations:

You can run rpk 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 acl create three times with the following (including your --allow-principal):

`rpk acl create --operation write,read,describe --topic [topics] `

rpk acl create --operation describe,read --group [group.id]

rpk acl create --operation describe,write --transactional-id [transactional.id]

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.

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.

The matching rules are only applied to commands that have filters, such as rpk acl delete and rpk acl list.

Not specifying flags matches everything. If no resources are specified, all resources are matched. If no operations are specified, all operations are matched. You can also opt in to matching everything with any: --operation matches any operation.

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

Every rpk acl can have these flags attached to them:

Every rpk acl can have these flags attached to them: