Use Access Control Lists (ACLs) for Confluent Cloud¶
Access control lists (ACLs) provide secure access to your Confluent Cloud Apache Kafka® resources and data. Principals, including both user and service accounts, have 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¶
Important
Non-breaking change being rolled out
[March 29, 2023] Support for the Resource ID (resourceId) format in Kafka
ACLs is currently rolling out to Confluent Cloud customers and will be completed
in the coming weeks.
These non-breaking changes do not affect existing ACLs. The new behavior
of ACL operations for Resource ID (resourceId) format and the deprecated
Integer ID (userIntegerId) are described in the following sections.
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 (user or service account) 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.