ACL Overview

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.

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.

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:

# 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:

confluent login

# Or use API key authentication
confluent api-key store <api-key> <api-secret> --resource lkc-xxxxx

Set your environment and cluster context:

# List your environments
confluent environment list

# Set your environment
confluent environment use <environment-id>

# List your clusters
confluent kafka cluster list

# Set your cluster context
confluent kafka cluster use <cluster-id>

Note

You need appropriate permissions to manage ACLs. The following RBAC roles can create, modify, and delete ACLs:

Role bindings on Kafka resources (including ACL management) are only available on Standard, Enterprise, and Dedicated clusters, not Basic clusters. For more information about cluster type limitations, see Kafka Cluster Types in Confluent Cloud.

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:<principal-id>.

Resources

ACLs control access to Kafka resources only. These are the Kafka entities that principals can access:

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.

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.

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 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 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 for ACL management events and Kafka Cluster Authentication and Authorization Auditable Event Methods on Confluent Cloud 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.
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.

Related content