Looking for Confluent Platform Cluster Linking docs? This page describes Cluster Linking on Confluent Cloud. If you are looking for Confluent Platform documentation, check out Cluster Linking on Confluent Platform.

Security for Cluster Linking on Confluent Cloud

Security Model

The Cluster Linking security model separates the permissions and credentials needed for each step of its lifecycle. This paradigm enables many teams to use cluster link operations on the topics that they already own. It also allows the owner of one cluster to share data over a cluster link with another team or organization, while only giving that team or organization READ access to the shareable, mirror topics.


The advantages of this model are:

  • The access control lists (ACLs) needed to create a cluster link and mirror topics can be managed by the owner of the destination cluster. If you use role-based access control (RBAC), you can simply enable ClusterAdmin, EnvAdmin, or OrgAdmin roles to give users or applications permissions on the destination cluster. These roles are described in Confluent Cloud Cluster Authorization using Role-based Access Control (RBAC). Operations performed on a cluster link and a mirror topic are available in Confluent Cloud Audit Logs. Alternatively, you can simply specify the ACLs.
  • The cluster link has its own credentials and ACLs on the source cluster. You can manage its READ access to the source cluster just like any other Apache Kafka® consumer. So, you can use your existing security workflows with cluster links.
    • If the source cluster is a Confluent Cloud cluster, it’s best to create a service account for the cluster link. You will issue source cluster credentials (API key and secret) to the cluster link’s service account.
    • If your source cluster is a Confluent Platform or open-source Apache Kafka cluster, the cluster link can use SASL/PLAIN or SASL/SCRAM. It cannot use Kerberos or OAuth.
  • The cluster link itself requires only read ACLs on the source cluster. No ACLs or credentials are required on the destination cluster in Confluent Cloud. This simplifies management.
  • When sharing data between teams, the owner of the source cluster can limit READ access to the mirror topics on the destination cluster on a topic-by-topic basis.

When sending data between the source and destination clusters, Cluster Linking uses Transport Layer Security (TLS) to encrypt data in transit.

If configured as such, Cluster Linking can also sync all client ACLs, or a configurable subset, from the source cluster to the destination cluster.

Building Blocks

The building blocks of Cluster Linking are:

  • A cluster link, which connects a source cluster to a destination cluster
  • A mirror topic, which exists on the destination cluster, and receives a copy of all messages that go to its source topic
  • A source topic, which is a regular topic that exists on the source cluster and is the source of data for the mirror topic

Cluster Linking Lifecycle and Permissions

Each phase of the Cluster Linking lifecycle requires different permissions. The phases are:

  • A user or client application creates a cluster link.
  • A user or client application creates a mirror topic using the cluster link.
  • The cluster link reads topic data, consumer offsets, and ACLs from the source cluster.
  • The cluster link writes topic data, consumer offsets, and ACLs to the destination cluster.
  • A user or client application modifies, promotes, or deletes the mirror topic.
  • A user or client application modifies or deletes the cluster link.

Creating or modifying a mirror topic

To create or modify a cluster link, a user must be authenticated and authorized by either a service account or a Confluent Cloud user account.

If the user is authenticated with a Confluent Cloud user account, they must have the ClusterAdmin, EnvAdmin, or OrgAdmin RBAC role over the destination cluster in order to be authorized to create or modify mirror topics.

If the user or client application is authenticated with a service account, then their service account needs two ACLs on the destination cluster:

  • An ACL to allow them to ALTER the destination cluster.
  • An ACL to allow them to ALTERCONFIGS on the destination cluster.
  • An ACL to allow them to CREATE the mirror topic. This ACL can be one that allows them to create all topics, or it can be scoped by topic name(s).

ACLs required to list and describe mirror topics

The list mirrors command lists the mirror topics on a cluster and/or a cluster link. You can call this command through the Confluent Cloud API for Cluster Linking with `REST`: `GET /kafka/v3/clusters/<cluster-id>/links/<link-name>/mirrors` or from the unified Confluent CLI with confluent kafka mirror list.

The describe mirror command gives information about a specific mirror topic. You can call this command through the Confluent Cloud API with `REST`: `GET /kafka/v3/clusters/<cluster-id>/links/<link-name>/mirrors/<mirror-topic>` or from the Confluent CLI with confluent kafka mirror describe <mirror-topic>.

To list and describe mirror topics, you need one of the following ACLs:

  • The DESCRIBE ACL on a Cluster resource, which provides access to both list and describe for all topics on the cluster.
  • The DESCRIBE ACL on specific Topic(s), which provides access to both list and describe for the specified topics only.

Writing to the destination cluster

On Confluent Cloud, cluster links don’t need any extra permissions to write data to the destination cluster. Because they exist on the destination cluster, they already have the appropriate permissions.

Transport Layer Security

For a cluster link between two Confluent Cloud clusters, data in transit is encrypted through one-way TLS V1.2 (in the Java community, this is referred to as one-way SSL).

For a cluster link from a Confluent Platform or Apache Kafka cluster to a Confluent Cloud cluster, data-in-transit must use one-way TLS (in the Java community, this is referred to as one-way SSL). It will default to the latest version of TLS that both clusters have enabled. TLS 1.2 and 1.3 are enabled by default in Apache Kafka.

Older versions of SSL can be enabled, but this is discouraged due to known security vulnerabilities.

Practical Examples

To see practical examples of how you might model security for different Cluster Linking deployments, refer to these use case tutorials:

Audit Logs

Whenever a user or application tries to create or delete a cluster link or a mirror topic, authentication and authorization events are created in Confluent Cloud Audit Logs. This allows you to monitor Cluster Linking access and activity throughout Confluent Cloud.