# ACL Overview Access control lists (ACLs) provide secure access to your Confluent Cloud Apache Kafka® resources and data. A [principal](../../../_glossary.md#term-principal) has permissions only for the Confluent Cloud resources granted to them. 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. #### NOTE Role-based access control (RBAC) is preferred over ACLs because it provides predefined roles with standardized permissions, making access management simpler and more consistent across your organization. While ACLs offer fine- grained control at the individual resource level, RBAC provides better scalability and reduces administrative overhead through role-based templates. For more information, see [Role-based Access Control (RBAC) on Confluent Cloud](../rbac/overview.md#cloud-rbac). #### 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. ## Prerequisites Before you can create and manage ACLs in Confluent Cloud, you need to set up the required tools and authentication. ### Install Confluent CLI Install the Confluent CLI to manage ACLs from the command line: ```shell # Install using curl (macOS/Linux) curl -L --http1.1 https://cnfl.io/cli | sh -s -- -b /usr/local/bin # Or install using Homebrew (macOS) brew install confluentinc/tap/cli # Or install using package managers # For more installation options, see: https://docs.confluent.io/confluent-cli/current/install.html ``` ### Authenticate with Confluent Cloud Sign in to your Confluent Cloud account: ```shell confluent login # Or use API key authentication confluent api-key store --resource lkc-xxxxx ``` Set your environment and cluster context: ```shell # List your environments confluent environment list # Set your environment confluent environment use # List your clusters confluent kafka cluster list # Set your cluster context confluent kafka cluster use ``` #### NOTE You need appropriate permissions to manage ACLs. The following RBAC roles can create, modify, and delete ACLs: - [CloudClusterAdmin](../rbac/predefined-rbac-roles.md#cloudclusteradmin-role): Can manage ACLs for a specific cluster. - [EnvironmentAdmin](../rbac/predefined-rbac-roles.md#environmentadmin-role): Can manage ACLs for all clusters within an environment. - [OrganizationAdmin](../rbac/predefined-rbac-roles.md#organizationadmin-role): Can manage ACLs across the entire organization. ## ACL concepts Review the following concepts related to how ACLs work in Confluent Cloud. ### Principals A principal is an entity that can be authenticated and granted permissions based on roles to access resources and perform operations. An entity can be a user account, service account, group mapping, or identity pool. In Confluent Cloud, principals are identified using the format `User:`. ### Resources ACLs control access to Kafka resources only. These are the Kafka entities that principals can access: - **Topics**: For information about managing topics, see [Manage Topics in Confluent Cloud](../../../topics/overview.md#cloud-topics). - **Consumer groups**: For information about consumer groups, see [Kafka Consumer for Confluent Cloud](../../../client-apps/consumer.md#kafka-consumer-cc). - **Clusters**: For information about cluster management, see [Create a Kafka Cluster](../../../clusters/create-cluster.md#cloud-create-cluster). - **Transactional IDs**: For information about transactions and exactly-once semantics, see [Optimize Confluent Cloud Clients for Durability](../../../client-apps/optimizing/durability.md#optimizing-for-durability). ### Operations Operations define what actions a principal can perform on resources: - **READ**: Consume messages from topics - **WRITE**: Produce messages to topics - **CREATE**: Create new resources - **DELETE**: Remove resources - **DESCRIBE**: View metadata about resources - **ALTER**: Modify resource configurations - **DESCRIBE_CONFIGS**: View configuration settings - **ALTER_CONFIGS**: Modify configuration settings For more information about operations, see [ACL Operations](operations.md#acl-operations). ### Permissions ACLs specify whether to allow or deny access: - **ALLOW**: Grants permission to perform the specified operation - **DENY**: Explicitly blocks permission to perform the specified operation ### Pattern types ACLs support different pattern types for resource matching: - **LITERAL**: Exact match for resource names - **PREFIXED**: Matches resources that start with the specified prefix ### Host restrictions ACLs can specify host restrictions to control which hosts can access resources: - **Wildcard**: `/*` allows access from any host (default). - **Specific IP addresses**: Restrict access to specific IP addresses. - **IP ranges**: Restrict access to specific IP ranges. Host restrictions provide an additional layer of security by controlling network-level access to Kafka resources. #### NOTE In Confluent Cloud, ACLs work in conjunction with RBAC role bindings. For details on how ACLs and RBAC interact, including precedence rules, see [Use ACLs with RBAC on Confluent Cloud](../rbac/use-acls-with-rbac.md#using-acls-with-rbac). ## ACL best practices Follow these best practices when implementing ACLs in Confluent Cloud: Consider RBAC first : RBAC is preferred over ACLs because it provides predefined roles with standardized permissions, making access management simpler and more consistent across your organization. While ACLs offer fine-grained control at the individual resource level, RBAC provides better scalability and reduces administrative overhead through role-based templates. See [Role-based Access Control (RBAC) on Confluent Cloud](../rbac/overview.md#cloud-rbac) for more information. Principle of least privilege : Grant only the minimum permissions necessary for principals to perform their required operations. Avoid granting overly broad permissions. Use specific resource names : Prefer specific topic and consumer group names over wildcards when possible. This provides better security control and auditability. Regular ACL audits : Periodically review and clean up unused ACLs to maintain security hygiene. Document ACL purposes : Use descriptive comments or documentation to explain why specific ACLs exist and what they enable. Test ACL changes : Use the `--dry-run` option when creating ACLs to preview the impact before applying changes. Monitor access patterns : Use [audit logs](../../../monitoring/audit-logging/cloud-audit-log-concepts.md#cloud-audit-logs) to monitor how ACLs are being used and identify potential security issues. For information about ACL events in audit logs, see [Kafka Cluster Management and Operations Auditable Event Methods on Confluent Cloud](../../../monitoring/audit-logging/event-methods/kafka-management.md#kafka-management-auditable-events) for ACL management events and [Kafka Cluster Authentication and Authorization Auditable Event Methods on Confluent Cloud](../../../monitoring/audit-logging/event-methods/authorization-authentication-events.md#authentication-authorization-auditable-events) for ACL authorization events. Coordinate with RBAC : Since ACLs work alongside RBAC in Confluent Cloud, ensure your ACL strategy complements your RBAC role assignments. For detailed guidance on using ACLs with RBAC, including precedence rules and best practices, see [Use ACLs with RBAC on Confluent Cloud](../rbac/use-acls-with-rbac.md#using-acls-with-rbac). Consider performance impact : Each ACL adds overhead to authorization checks. Monitor ACL count and consider consolidating similar ACLs to maintain optimal performance. For ACL limits by cluster type, see [Kafka Cluster Types in Confluent Cloud](../../../clusters/cluster-types.md#cloud-cluster-types). ## Related content - [ACL Operations](operations.md#acl-operations) - ACL operations and implementation details - [ACL Examples and Use Cases](examples.md#acl-examples) - ACL examples and use cases - [Troubleshoot ACL Issues](troubleshooting.md#acl-troubleshooting) - Troubleshooting ACL issues - [ACL Reference](reference.md#acl-reference) - ACL reference information