The ACL (Access Control List) policy manages authorization for your virtual cluster by defining which actions principals can perform on specific resources.

By default, when ACLs are enabled, principals have no access. You must explicitly define access rules through ACL policies.

Use cases

Common use cases for the ACLs policy:

Use case

Description

Example: Allow read-only access to a topic Allow the principal to consume messages for a specific topic.
Example: Allow consumer group management Allow the principal to create and delete consumer groups.
How-to: Productize Kafka topics with namespaces and ACLs If your Kafka topics follow a naming convention with prefixes, you can easily organize them into categories with Kong Event Gateway by using a combination of namespaces, forwarding policies, and ACL policies.
How-to: Secure Kafka traffic in Event Gateway with Kong Identity and ACLs Using Kong Identity as an auth server, verify client OAuth tokens through a virtual cluster, and apply an ACL policy to restrict access to a specific client.

How it works

This policy runs in the cluster phase.

  1. A Kafka client produces a message and sends it to Event Gateway.
  2. Event Gateway checks the client’s action against the configured ACL.
    • If the action is allowed, it passes the message onward.
    • If the action isn’t allowed, the message is dropped.
 
sequenceDiagram
  autonumber
  participant client as Client
  participant egw as Event Gateway
  participant broker as Event broker

  client->>egw: message
  egw->>egw: check action against ACL
  
  alt If action allowed

  egw->>broker: send message

  else If action blocked
  egw -x client: forbidden
  end

  

Security considerations

When resource_names uses an expression that interpolates an identity into a glob pattern (for example [context.auth.principal.name + "-*"] or [context.auth.token.claims.topic_prefix + "*"]), the interpolated value is matched as a glob and is not escaped. If the value can contain glob metacharacters (*, ?, [, ]), they act as wildcards and can widen the set of matched resources beyond what you intend.

For example, with resource_names: '[context.auth.principal.name + "-*"]', a principal named ali* produces the pattern ali*-*, which matches topics such as alibob-secrets and ali-data, not just that principal’s own topics.

Only interpolate identity values into resource_names patterns when those values are guaranteed not to contain glob metacharacters.

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!