Security should be at the heart of the design of any software project, and Redpanda is no exception. Here we’ll dive into authorization, one of the baked-in mechanisms that helps you make your Redpanda cluster more secure. If want to know about authentication with mTLS and SASL, check out our docs on security. But, if you want a demonstration ACLs, follow along.
Note: System security requires attention to many domains, such as network configuration and organization-wide roles management. Here we only address security of client access to data. Make sure to review all of your other security requirements on a regular basis.
Access control lists (ACLs) make sure your data is protected by granular, least-privilege policies. By following this guide, you will get to know how to set up Redpanda with ACLs, both on a conceptual level and on a technical level, through hands-on examples.
While authentication is about making sure that whatever client connects to your cluster is verified as a trusted client, authorization is about making sure that each client has access to exactly the data it should. ACLs are the main mechanism supported by Redpanda to manage permissions. Our implementation of ACLs is Kafka-compatible, too!
At a high level, ACLs specify what authenticated users can or cannot do.
ACLs are all about who from where can or cannot do what action to what object.
In ACL terminology, the entities accessing the resources are called principals.
Principals can be either users (
user) or consumer groups (
An ACL allows or denies the specified principals access to resources.
You can also specify from which hosts the principals are allowed or denied.
For more granular ACLs, you can allow or deny principals access to specific resources, such as specific topics, and for specific operations, such as “read”, “write”, or “describe”. These ACLs really lock down access to your data so you can rest assured that no one is getting unauthorized access.
The fields and values you can use are:
|Principal (who)||User name, consumer group name|
|Host (from where)||Host IP address|
|Resource type (objects)|
|Resource name (object)||Name of a specific resource|
In addition to other Kafka-compatible tools, ACLs are managed with the Redpanda rpk utility with the commands:
- Creating ACLs -
rpk acl create
- Listing ACLs -
rpk acl list
- Deleting ACLs -
rpk acl delete
- Create an ACL allowing a user to perform all operations from all hosts to a topic named “pings”:
rpk acl create \--allow-principal 'User:Charlie' \--allow-hosts '*' \--operation all \--resource topic \--resource-name pings
rpk confirms that you created the ACL:
Created ACL for principal 'User:Charlie' with host '*', operation 'All' and permission 'Allow'
You can also use a single command to create multiple ACLs, including ACLs that deny certain principals access to a resource and allow other principals access to the same resource:
rpk acl create \--resource cluster \--allow-host 220.127.116.11 \--deny-host 18.104.22.168 \--deny-principal 'User:david' \--allow-principal 'User:Alex' \--allow-principal 'User:Ben'
rpk confirms that you created multiple ACLs:
Created ACL for principal 'User:david' with host '22.214.171.124', operation 'All' and permission 'Deny'Created ACL for principal 'User:Alex' with host '126.96.36.199', operation 'All' and permission 'Allow'Created ACL for principal 'User:Ben' with host '188.8.131.52', operation 'All' and permission 'Allow'
Now let’s see what the ACLs look like for a specific user:
rpk acl list --principal 'User:Ben'
This list of ACLs is shown with all of their parameters:
PRINCIPAL HOST OPERATION PERMISSION TYPE RESOURCE TYPE RESOURCE NAMEUser:Ben 184.108.40.206 All Allow Cluster kafka-cluster
Of course, you can list ACLs with other filters, like host, permission and resource, or just see all of the ACLs with
rpk acl list.
rpk acl delete allows you to delete ACLs.
It’s important to note, however, that wildcard values such as
any for operations and permissions, as well as
* for hosts and resources may result in the deletion filters matching more than one ACL.
Delete all ACLs for a specific user targeting a specific resource:rpk acl delete --deny-principal 'User:david' --resource cluster
All of the related ACLs are listed as deleted:DELETED PRINCIPAL HOST OPERATION PERMISSION TYPE RESOURCE TYPE RESOURCE NAME ERROR MESSAGEyes User:david 220.127.116.11 All Deny Cluster kafka-cluster None
Delete all ACLs granting a principal permissions to all operations from a host:rpk acl delete \--allow-principal 'User:Ben' \--allow-host 18.104.22.168 \--operation all
We are moving fast to keep up with the demand for Redpanda, the intelligent data API, and security with ACLs is only one of the many features that we’re working on. Join our Slack community to stay up on the latest developments.