Access Control Lists

When a cluster has an authorizer, its access control lists (ACLs) decide which users and applications may read, write, create or change which topics, consumer groups and other resources. The ACL section lists every ACL on the cluster and lets you add new ones, by hand or with helpers that grant what a typical consumer, producer or Kafka Streams application needs, and delete the ones you no longer want.

To open it, connect the cluster and click ACL under its name in the Kafka Clusters pane. The entry is greyed out when the cluster has no authorizer, or your login may not list its ACLs: the Overview then shows ACL View as No. To create and delete ACLs you also need ACL Edit, which takes Alter permission on the cluster.

1 2 3 4 5 6 7 8

1. Filter ACLs...: show only the ACLs that match (below).
2. Create ACL: add one or more ACLs (below).
3. Delete ACL Entry: delete the selected ACLs (below). Greyed out until you select a row.
4. Refresh All ACL(s): read the ACLs from the cluster again.
5. The selected ACL's principal and resource name. Click it to copy them to the clipboard. It's shown only while exactly one row is selected.
6. The Permission column: ALLOW or DENY.
7. How many ACLs are listed (after filtering).
8. Duplicate Tab: open the ACL section in a tab of its own, as was done here for Topics, so you can check a user's ACLs while you look at the topics they use (Duplicating a tab).

ACL concepts

Each row in the list is one ACL entry: it allows or denies one principal one operation on one resource (or set of resources), from one host. KafkIO shows Kafka's own names for each part, in these columns:

Principal

Who the entry is for, as type:name, nearly always User: followed by the name the client authenticates as: the SASL username, or the certificate's distinguished name with mutual TLS (Security). User:* means every user.

Host

The IP address the client must connect from, or * for any host. Most ACLs use *.

Resource Type

What kind of thing the entry protects: TOPIC, GROUP (consumer group), CLUSTER (cluster-wide actions; its resource name is always kafka-cluster), TRANSACTIONAL_ID (transactional producers), DELEGATION_TOKEN or USER.

Resource Name and Pattern

Which resources of that type: with LITERAL, the one resource with exactly that name (or every resource, if the name is *); with PREFIXED, every resource whose name starts with it, so alice- covers alice-reports and alice-test.

Operation

What may be done: READ, WRITE, CREATE, DELETE, ALTER, DESCRIBE, DESCRIBE_CONFIGS, ALTER_CONFIGS, CLUSTER_ACTION, IDEMPOTENT_WRITE, CREATE_TOKENS, DESCRIBE_TOKENS, TWO_PHASE_COMMIT, or ALL. Kafka counts READ, WRITE, DELETE and ALTER as including DESCRIBE.

Permission

ALLOW or DENY. A matching DENY always wins over an ALLOW, which makes it useful for carving an exception out of a broad grant, like alice's DENY on audit-log above, which overrides her ALLOW on the same topic.

Kafka refuses anything no ACL allows, unless the broker is configured otherwise (allow.everyone.if.no.acl.found), and super users defined on the brokers (super.users) bypass ACLs altogether. Neither setting appears in this list.

Viewing and filtering ACLs

KafkIO reads every ACL on the cluster when you open the section, grouped by resource type and then resource name. Click a column header to sort by it instead. If the list is empty and says No ACLs to display; do you have access to retrieve the ACLs?, either the cluster has no ACLs yet or your login isn't allowed to describe them.

Type in Filter ACLs... to narrow the list. The text is matched against every column at once, so a principal, a topic name, DENY or PREFIXED all work. Turn on the .* toggle at the end of the field to use a regular expression (Filtering). Filtering by principal is the quickest way to answer "what may this user do?", for example when an application, or your own login, gets an authorization error (Limited permissions):

1 2

1. The filter text, matched against all columns.
2. The regular expression toggle. The × beside it clears the filter.

Select rows with a click, Ctrl+click or Shift+click (⌘+click on macOS), or Ctrl+A for every listed row. Right-click a row for Delete ACL Entry, Copy of the value you clicked, Copy Summary (the row) and Copy All Summaries (every listed row), handy for pasting a user's ACLs into a ticket.

Creating ACLs

Click Create ACL to open the Create ACL Entries window. Pick an ACL helper type first: Custom / manual for full control, or one of the helpers that create the usual set of ACLs for a consumer, a producer or a Kafka Streams application. Every type starts with the same two fields:

• Principal: who the ACLs are for, as type:name (it must contain a colon). It starts as User:my_user: replace it.
• Host: an IP address, or * (the default) for any host.

Create ACL(s), at the bottom right, stays greyed out until the form is complete; a red mark shows what's missing. When the ACLs have been created, KafkIO says The ACLs were successfully updated! and refreshes the list. The window stays open with your entries, so you can change the principal or a resource and create the next set. It isn't modal: you can keep using the main window meanwhile.

If the cluster refuses, KafkIO shows Error updating ACLs with Kafka's reason. A ClusterAuthorizationException means your login lacks Alter on the cluster (the ACL Edit feature): KafkIO still offers Create ACL in that case, but the cluster rejects the request.

Custom entries

Use Custom / manual for anything the helpers don't cover: a DENY, cluster or transactional ID permissions on their own, or operations such as ALTER_CONFIGS. You choose one resource and one or more operations, and KafkIO creates one ACL per operation.

1 2 3 4 5 6 7 8

1. ACL helper type: Custom / manual.
2. Principal.
3. Host.
4. Resource type: TOPIC by default.
5. ALLOW or DENY (the darker button is the one selected).
6. The operations. Open the list and tick as many as you need; at least one stays ticked (CREATE at first).
7. Matching pattern: LITERAL or PREFIXED.
8. The resource name, or the prefix (required). For CLUSTER, use LITERAL and kafka-cluster; for every resource of the type, use LITERAL and *.

Consumer helper

For Consumer grants an application what it needs to consume: READ and DESCRIBE on the topics it reads, and READ on the consumer groups it uses. Fill in either part, or both. For each, choose LITERAL to pick existing topics or groups from a list, or PREFIXED to type a prefix.

1 2 3 4 5

1. For Consumer.
2. Consume Topic(s): LITERAL or PREFIXED.
3. With LITERAL, move topics from Available Topic(s) to Give READ & DESCRIBE Access To with the arrow buttons (» moves them all). Filter topics... narrows a long list.
4. Consumer Group(s): LITERAL or PREFIXED.
5. With PREFIXED, the prefix. Here every group starting with fulfilment-.

The lists only offer topics and groups that exist now. A new application's consumer group usually doesn't exist until it first runs, so use PREFIXED with its group.id (which also matches longer names that start with it), or create a LITERAL GROUP ACL with Custom / manual.

Producer helper

For Producer grants what an application needs to produce. Fill in any of the three parts:

• Produce Topic(s): CREATE, WRITE and DESCRIBE on the topics, by list (LITERAL) or prefix (PREFIXED). CREATE lets the producer create a topic that doesn't exist yet, if the brokers allow auto-creation.
• Transaction ID: WRITE and DESCRIBE on a TRANSACTIONAL_ID, for producers that use transactions (transactional.id). Type the exact ID or, with PREFIXED, a prefix shared by all the application's instances.
• Idempotency: tick it to add IDEMPOTENT_WRITE on the cluster, for idempotent producers on clusters that still ask for this permission.

1 2 3 4 5

1. Produce Topic(s), here PREFIXED.
2. The topic prefix.
3. Transaction ID: LITERAL or PREFIXED.
4. The transactional ID, or its prefix.
5. Idempotency.

Kafka Streams helper

A Kafka Streams application reads input topics, writes output topics, and creates its own internal topics and consumer group, all named after its application.id. For Kafka Stream Apps grants all of that:

1 2 3

1. Consume Topic(s): READ on each input topic you move to the right.
2. Produce Topic(s): WRITE on each output topic you move to the right.
3. Application ID: ALL on every TOPIC and every GROUP whose name starts with it (PREFIXED), which covers the application's consumer group and its internal changelog and repartition topics.

The two topic lists offer existing topics only, by name (there is no prefix option). Their right-hand headings are currently the wrong way round: the list under Consume Topic(s) says Give WRITE Access To, yet KafkIO grants READ on those topics, and the list under Produce Topic(s) gets WRITE, as the descriptions on the left say. If the application uses exactly-once processing, also grant it a transactional ID with the producer helper or Custom / manual.

Deleting ACLs

Select the ACLs to delete, then click Delete ACL Entry at the end of the filter field (with several rows selected its tooltip reads Delete N ACL Entries), or right-click a row. To remove everything a user or application was granted, filter by its principal and press Ctrl+A first:

1

1. Delete ACL Entry, for the four selected rows.

Confirm with Delete (Delete (4) for several). The rows disappear from the list as each is deleted, and a notification confirms it.

Refreshing

The list is read when you open the section and again after you create ACLs in KafkIO. ACLs added or removed elsewhere (by kafka-acls, Terraform, another KafkIO) don't appear until you click Refresh All ACL(s), which reads them all again and reports Found N ACLs.

Related

• Cluster Overview: the ACL View and ACL Edit cards.
• Troubleshooting: limited permissions: what KafkIO shows when your own login's ACLs are restrictive.
• Security: the logins that principals come from.
• Consumers: the consumer groups that GROUP ACLs protect.