When you replicate data between two Kafka clusters with MirrorMaker 2, what does it mean to 'secure the replication link', and what are the two layers involved?
answer
- MM2 = Connect = ordinary clients
- Layer1 encrypt = security.protocol SSL/SASL_SSL
- Layer2 authn = mTLS cert OR SASL
- Layer3 authz = ACLs
- source.* vs target.* prefixes
basics
~20 sMirrorMaker 2 is just a Kafka client. Securing the link means: (1) encrypt traffic in transit with TLS, and (2) authenticate MM2 to each cluster (mTLS or SASL) so only an authorized identity can read the source and write the target.
solid answer
~40 sMirrorMaker 2 (MM2) runs on Kafka Connect and acts as a normal consumer on the source cluster and a normal producer on the target cluster. 'Securing the link' has two independent layers. First, encryption-in-transit: set security.protocol to SSL or SASL_SSL so the TCP connection is TLS-wrapped and nobody can sniff the records. Second, authentication: MM2 must prove an identity to each broker, either via mutual TLS (a client certificate) or SASL (SCRAM, PLAIN, GSSAPI/Kerberos, or OAUTHBEARER). On top of authentication sits authorization (ACLs): the authenticated principal needs Read on source topics and consumer groups, and Write/Create on the target. You configure source and target separately with prefixed properties (e.g. <alias>.security.protocol), because the two clusters can use entirely different mechanisms and credentials.
go deeper
Know MM2 is a Kafka client and securing the link = TLS encryption + authentication (mTLS or SASL).
Configure source./target. prefixes and pick SASL_SSL; know truststore vs keystore roles.
Reason about the three layers independently and secure Connect's internal topics too; avoid SASL_PLAINTEXT cross-WAN.
Design a consistent authn/authz posture across heterogeneous clusters and mandate hostname verification + per-environment trust roots.
## The setup Kafka clusters do not replicate to each other natively at the broker level. Instead a separate application reads from one cluster and writes to another. The standard tool is **MirrorMaker 2 (MM2)**, which is built on **Kafka Connect**. Internally MM2 is just a set of Kafka **clients**: a `MirrorSourceConnector` consumes records from the *source* cluster and produces them to the *target* cluster, plus connectors that mirror consumer-group offsets and topic configs. Because MM2 is an ordinary client, securing the 'replication link' means securing those client-to-broker connections — there is no special cross-cluster protocol to secure. ## Layer 1 — Encryption in transit (TLS/SSL) By default Kafka traffic is plaintext on the wire. To encrypt it you point clients at a listener that speaks TLS and set `security.protocol`: - `PLAINTEXT` — no encryption, no auth. - `SSL` — TLS encryption; optionally mutual TLS for auth. - `SASL_PLAINTEXT` — SASL auth but **no** encryption (avoid across clusters/networks). - `SASL_SSL` — SASL auth **and** TLS encryption (the common production choice). TLS uses a **truststore** (the CA certs the client trusts, so it can verify the broker's certificate) and, for mutual TLS, a **keystore** (the client's own certificate + private key). ## Layer 2 — Authentication (who is MM2?) The broker needs to know which identity is connecting. Two families: - **mTLS (mutual TLS):** MM2 presents a client certificate; the broker derives a **principal** from the certificate's Distinguished Name (DN). - **SASL:** a challenge/response mechanism — `SCRAM-SHA-256/512` (salted password), `PLAIN` (username/password), `GSSAPI` (Kerberos), or `OAUTHBEARER` (OAuth token). Configured via `sasl.mechanism` and `sasl.jaas.config`. ## Layer 3 — Authorization (what may MM2 do?) Authentication only establishes identity; **ACLs** decide what that identity can do. The MM2 principal needs `Read` on the source topics + its consumer group, and `Write`/`Create`/`DescribeConfigs` on the target. (Covered in depth in a separate question.) ## Source vs target are configured separately The two clusters may use different mechanisms entirely (e.g. mTLS on-prem source, SASL/SCRAM in the cloud target). In MM2 config you prefix properties with the cluster alias: `source.security.protocol`, `target.security.protocol`, `source.ssl.truststore.location`, `target.sasl.jaas.config`, and so on. Connect-level worker properties and `*.producer.*` / `*.consumer.*` overrides let you tune each side. ## Edge cases - Forgetting to secure the **internal** Connect topics (offsets/config/status) leaves MM2's own coordination unencrypted even if data flows are secured. - `SASL_PLAINTEXT` across a WAN sends SCRAM/PLAIN credentials with only the SASL handshake protecting them — never do this between clusters. - TLS hostname verification (`ssl.endpoint.identification.algorithm=https`) must stay on to prevent MITM; disabling it 'to make certs work' is a common security regression.
- Why is SASL_PLAINTEXT a bad choice for a cross-cluster link?It authenticates but does not encrypt, so records and (for SCRAM/PLAIN) the credential handshake travel exposed across the network between clusters. Use SASL_SSL or SSL with mTLS.
- Does MM2 need anything beyond authentication to actually replicate?Yes — authorization. The authenticated principal still needs ACLs: Read on source topics/groups and Write/Create on target topics. Authentication alone yields authorization failures.
saying these in an interview costs you the question
- Thinking Kafka has a native broker-to-broker replication protocol that you secure (MM2 is just clients)
- Conflating encryption with authentication — TLS encryption alone is not authentication unless it's mutual TLS
- Saying ACLs are unnecessary once mTLS is configured