Introduction

In Kafka, ACLs are attached to principals and resources, not to some separate “consumer group object” that you manually create in advance. That distinction matters because creating a Kafka user depends on your authentication mechanism, while a consumer group usually comes into existence automatically when consumers start using a chosen group.id.

So the real workflow is: make sure authentication is enabled, create or identify the user principal, then add ACLs for the topic and the consumer group name that client will use.

Understand What Actually Gets Created

There are two different things in the question:

• a user or principal
• a consumer group identifier

A Kafka user is only "created" in Kafka when the auth mechanism stores credentials in Kafka itself, such as SASL/SCRAM. With mutual TLS, the principal may come from the certificate identity instead.

A consumer group is different. You normally do not pre-create it as a standalone resource. You pick a group.id, and Kafka recognizes that group when consumers join with that id. ACLs can be granted to that group name ahead of time.

Create a SCRAM User on a Running Cluster

If the cluster is using SASL/SCRAM, create credentials with kafka-configs.sh.

kafka-configs.sh   --bootstrap-server broker1:9092   --alter   --add-config 'SCRAM-SHA-256=[password=app-secret]'   --entity-type users   --entity-name app1

That command adds credentials for the principal User:app1.

If your cluster uses SASL/PLAIN, LDAP, Kerberos, or TLS client certificates, the procedure is different because Kafka itself may not be the system storing the credentials. The ACL principal still matters, but the way it becomes valid depends on the authentication backend.

Grant ACLs to the User and Group

To consume from a topic, a client generally needs permission on both the topic and the consumer group.

kafka-acls.sh   --bootstrap-server broker1:9092   --add   --allow-principal User:app1   --operation Read   --topic orders

And then grant group access:

kafka-acls.sh   --bootstrap-server broker1:9092   --add   --allow-principal User:app1   --operation Read   --group orders-consumer

If the client also produces, add a write ACL on the topic:

kafka-acls.sh   --bootstrap-server broker1:9092   --add   --allow-principal User:app1   --operation Write   --topic orders

The --group orders-consumer part does not create a live consumer group session. It creates an ACL rule for that group name.

Client Configuration Example

The user must also authenticate with matching client settings.

1bootstrap.servers=broker1:9092
2security.protocol=SASL_SSL
3sasl.mechanism=SCRAM-SHA-256
4sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="app1" password="app-secret";
5group.id=orders-consumer

That group.id is the name referenced in the ACL command. When the consumer starts, Kafka checks whether User:app1 is allowed to read using that group.

Verify the ACLs

After adding rules, list them back to confirm what the cluster actually stored.

kafka-acls.sh   --bootstrap-server broker1:9092   --list   --principal User:app1

Also check the broker logs if the client still gets authorization failures. Kafka error messages usually tell you whether the denial was for the topic, the group, or another resource.

Running Cluster Considerations

On an already running cluster, the main operational concern is using the correct admin command style for your deployment.

Modern clusters commonly use --bootstrap-server for admin operations. Older examples on the internet may show ZooKeeper-based authorizer commands. Those can be misleading if you copy them into a newer environment.

You also need the authorizer enabled on the brokers. If ACL enforcement is not configured, adding ACL commands will not give you the security model you think you have.

Common Pitfalls

The biggest mistake is trying to "create a consumer group" as if it were a separate Kafka object. Usually you do not do that. You choose group.id and grant ACLs for that name.

Another common issue is granting topic access but forgetting group access. Consumers may then authenticate successfully but still fail when joining the group.

People also copy old ZooKeeper-based ACL commands into clusters where the supported admin path is --bootstrap-server. That causes confusion during setup.

Finally, remember that user creation is auth-mechanism specific. Kafka can store SCRAM credentials, but not every authentication mode creates users in the same way.

Summary

• Kafka ACLs apply to principals and resource names such as topics and groups.
• Consumer groups usually are not pre-created manually.
• With SASL/SCRAM, create a user using kafka-configs.sh.
• Grant ACLs separately for the topic and the consumer group name.
• Match the client group.id to the ACL rule you created.
• Use kafka-acls.sh --list and broker logs to verify the result.