Kafka uses ACLs (Access Control Lists) in order to determine what users are having access to what resources. In theory managing ACLs should be easy, but as it allows you to configure the access levels on a very granular level, it is easy to get confused as the rules can quickly become complex.
A single entry/configuration of Kafkas ACLs structure looks like the following, and consists of a few different parts, let’s break them down.
ResourcePattern(
resourceType=
TOPIC, name=*,
patternType=
LITERAL)`:
(principal=
User:chmjrybk,
host=*, operation=
ALL,
permissionType=
ALLOW)
resourceType
The resource type determines what kind of resources the ACL entry in question can manage. The possible options for this configuration are:
- Topic - Access to a topic actions such as producing, consuming, changing topic specific configs
- Cluster - Access to cluster actions such as adding replicas, creating topics, managing ACLs
- Group - Access to group actions, reading and writing consumer group data ( e.g to manage offset within multiple consumers)
Operation
Just because you have set the access to the specific resourceType, doesn’t mean you are allowed to perform all actions on it, you can also define what kind of operations you are allowed to do on the specific resource type. Possible values differ depending on what resourceType you are managing, but the baseline is that you can give either READ, WRITE or ALL permissions to the resourceType. If you want to see the exact options, have a look at Authorization in Confluent Platform using ACLs
permissionType
By default Kafka has a deny-all mindset, unless you allow actions on the resources, only the precreated superuser are able to do any actions on the cluster. This is why we have this option, to specifically ALLOW access to resources following the least privilege principle. If you want, you could reverse the behavior, and deny access to certain resources by using the DENY keyword for this ACL option.
patternType
At last, you can instead of allowing access to ALL resources defined by the resourceType for the user, also narrow down to matching by the resource names. Possible values are:
- ANY - Gives access to all resources
- MATCH - Resources matching either the literal, wildcard or prefixed anme
- LITERAL - Resource matching the exact name provided
- PREFIXED - Resources prefixed with the provided string
Host
Defines from which systems/addresses your clients are allowed to connect. Default is allow all (*), but in case you only want to allow certain IP addresses to access this user, you can specify those. Often this is handled at a server/network level by blocking traffic with a firewall instead.
Principal
To whom the provided entry should apply, commonly used a plaintext user, such as alice or admin. But the value can also be applied to more complex names, for example when authenticating with client certificates, the principals name will come from the SSL certificates common name.
At Cloudkarafka
We are having access to the superuser, which allows all operations. This is needed in order to operate the system and to always allow us to support and recover a cluster if there is any issues. This one is also used by our internal monitoring systems, to provide metrics, stats and alarms features. Dedicated plans can manage their Users and ACL rules fully (except for that one superuser user mentioned above), shared users are limited to read and write to groups/topics that are prefixed with username.
We hope you found this inforamtion useful. If you have any queries or problems, our support team are on hand 24/7 to help you. Just send an email to support@cloudkarafka.com.
All the best, CloudKarafka team
