Use Access Control Lists (ACLs) for Confluent Cloud

Access control lists (ACLs) provide secure access to your Confluent Cloud Apache Kafka® resources and data. A principal has permissions only for the Confluent Cloud resources granted to them.

Important

Confluent Cloud ACLs are similar to Kafka ACLs. Before attempting to create and use ACLs, you should familiarize yourself with ACL concepts. Doing so can help you avoid common pitfalls that can occur when creating and using ACLs to manage access to components and cluster data.

The operations available to a principal depend on which resources they have permission to access. When defining an ACL, carefully consider which resources your principals have access to and the operations they can perform. Depending on the data and resources that specific principals need access to, you might need to define more than one ACL to meet your requirements.

Important

When a principal is deleted, the associated ACLs are not cleaned up automatically. Your administrator should ensure that the ACLs associated with the principal are deleted.

ACL resources and operations for Confluent Cloud (summary)

Note

The ACL resources and operations listed below are a subset of the Kafka ACL resources and operations for Confluent Platform.

Resource	Operation
Cluster	Create (allows creating topics) Describe: DescribeConfigs, DescribeCluster, other meta-data IdempotentWrite: for producers in Idempotent mode, InitProducerId(idempotent): To initialize the producer Alter (CreateAcls, DeleteAcls)
Consumer Groups	Delete Describe Read
Topic	Alter AlterConfigs Create Delete Describe (for example, number of partitions) DescribeConfigs Read Write
TransactionalID	Describe Write

ACL operation details

Create ACL

Supports both Resource ID (resourceId) and the Integer ID (userIntegerId) as principal.

Example:

• Resource ID (resourceId): User:sa-1234
• Integer ID (userIntegerId): User:1234

Describe ACL

Describe ACL principal format	Describes ACLs for	Returns using this format
Integer ID: User:1234	User:1234 and User:sa-1234	Integer ID
Resource ID: User:sa-1234	User:1234 and User:sa-1234	Resource ID: User:sa-1234
None	All	Integer ID: User:1234
Resource ID: UserV2:*	All	Resource ID: User:sa-1234

Delete ACL

ACL principal format	Deletes ACLs for	Returns using this format
Integer ID: User:1234	User:1234 and User:sa-1234	Integer ID: User:1234
Resource ID: User:sa-1234	User:1234 and User:sa-1234	Resource ID: User:sa-1234
None	All	Integer ID: User:1234
Resource ID: UserV2:*	All	Resource ID: User:sa-1234

Important

If you delete a user, and have ACLs created using both formats (Integer ID and Resource ID), then you must delete ACLs for both the Integer ID and Resource ID formats.

Cluster Linking

If you use cluster linking to replicate data between two Confluent Cloud Kafka clusters, the same principal must be used for both clusters, but your ACLs can include either the Resource ID or Integer ID to specify your resources.

For example, if you are using cluster linking to migrate data between two Confluent Cloud clusters, you could have ACLs that use the deprecated Integer ID format on the source cluster and the Resource ID format for ACLs on the destination cluster.

For details, see ACL syncing.

Related content

You can create Kafka ACLs that are easier to manage by using wildcards and prefix matching instead of specifying every topic or resource. For more details, see Prefixed ACLs.

To manage ACLs using the Confluent CLI, see the following:

• Tutorial: Confluent CLI
• confluent kafka acl.

As an alternative to using ACLs, you can use Role-based Access Control (RBAC) in Confluent Cloud to control access to an organization, environment, cluster, or granular Kafka resources (topics, consumer groups, and transactional IDs) based on predefined roles and access permissions.

RBAC and ACLs can be used together to provide complementary access controls on your Confluent Cloud resources and data. For more information, see Use ACLs with RBAC.