Encryption, Authorization, and Authentication

The superusers section in your redpanda.yaml is the user that you will use to bootstrap other users and ACLs. For example, if you used super user admin, Redpanda allows the admin user to do anything, but Redpanda does not create the admin user. You must now create this super user. Creating users happens through the Redpanda admin API, which defaults to localhost:9644. In the rpk commands below, if you have configured the admin API to use a different address/port, use the --api-urls <address:port> flag. The reason you need a super user is because creating ACLs for users uses the Kafka protocol (default of localhost:9092, mentioned above). Since no ACLs exist at the start, you need a super user to bypass the requirement of needing ACLs to create ACLs. You can create users and set passwords by running the following command:

You can use the newly created user to interact with Redpanda with the Kafka protocol:

Entities accessing the resources are called principals. A User:foo is the principal for user "foo".

You can decide whether to to allow or deny permissions to access to the resources.

You can also specify from which hosts they will be allowed or denied access.

This access is represented as operations, such as read, write, or describe, and said operations can be performed on resources, such as a topic. You can filter the resources by name.

ACL commands work on a multiplicative basis.

When you’re creating if you set up two principals and two permissions the result will be 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.

All ACLs require a principal.

A principal is composed of two parts: the type and the name.

Within Redpanda, currently only one type is supported, "User". In the future Redpanda might add support for authorizing by Group or anything else.

When you create user "bar", Redpanda expects you to add ACLs for "User:bar".

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

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

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.

If specifying hosts, you must pair the --allow-host flag with the --allow-principal flag

The same applies to 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, cluster, and transactionalid.

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.

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

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:

The following lists the operations needed for each individual client request, where resource corresponds to the resource flag, and "for xyz" corresponds to the resource name(s) in the request:

The following lists the operations needed for each individual client request, where "on RESOURCE" corresponds to the resource flag, and "for xyz" corresponds to the resource name(s) in the request:

You can also get this information at the CLI by running:

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

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.

Every rpk acl command can have these flags:

Following the multiplying effect of combining flags, the create command works on a straightforward basis: every ACL combination is a created ACL. At least one principal, one host, one resource, and one operation is required to create a single ACL. Here’s the general usage:

You can use the global flags that we saw before and some other local flags. Here’s the available local flags:

Examples:

List and Delete work in a similar multiplying effect as creating ACLs, but delete is more advanced.

They work on a filter basis. Any unspecified flag defaults to matching everything (all operations, or all allowed principals, etc).

To ensure that you do not 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 is going to ask again for confirmation.

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. --operation any matches any operation, for example.

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

Here’s the general usage:

You can use the global flags that we saw before and some other local flags. Here’s the available local flags:

Used to manage the SASL users.

If SASL is enabled, a SASL user is what you use to talk to Redpanda, and ACLs control what your user has access to. Using SASL requires setting "enable_sasl: true" in the redpanda section of your redpanda.yaml. Here’s the general usage:

For users you can use the global flags that we saw before and these global user flags. Here’s the available global user flags:

This command creates a single SASL user with the given password, optionally with a custom "mechanism".

SASL consists of three parts: a username, a password, and a mechanism. The mechanism determines which authentication flow the client will use for this user/pass.

Redpanda currently supports two mechanisms: SCRAM-SHA-256, the default, and SCRAM-SHA-512, which is the same flow but uses sha512 rather than sha256.

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

Here’s the local flags:

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 recreate the user later, as well, not all ACLs have users that they describe (instead they are for wildcard users).

Here’s the general usage:

Used to list SASL users.

Here’s the general usage:

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