ReviseAlgo Logo

Security & Multi-Cluster Deployments

Kafka Security — TLS, SASL, and ACLs

Encryption in transit, client authentication, and topic access controls.

Introduction

In distributed systems running at scale, data security cannot be an afterthought. By default, Kafka clusters transmit messages in plaintext and allow any client to read from or write to any topic. Kafka Security layers robust protection using TLS for encryption in transit, SASL for client authentication, and ACLs (Access Control Lists) for granular authorization.

Why It Matters

Without encryption, sensitive data (like user credentials or financial records) can be intercepted on the network wire. Furthermore, without client authentication and access controls, rogue or misconfigured services can connect to the broker, consume confidential topics, or delete critical partitions, causing data breaches and system outages.

Real-World Analogy

Think of Kafka security like a secure government vault. TLS encryption is like transporting documents in a bulletproof, windowless armored truck (preventing snooping during transport). SASL authentication is the ID badge check at the vault door (proving who you are). ACL authorization is the permission list checking if your specific badge is allowed to enter Vault Room B to write documents (topic-level read/write permissions).

How It Works

A secure Kafka deployment enforces the three pillars of security:

  1. Encryption in Transit (TLS): Brokers and clients verify each other's certificates. TLS encrypts all TCP packet payloads, preventing man-in-the-middle sniffing.
  2. Client Authentication (SASL): Clients verify identity using mechanisms like SCRAM (salted challenge-response with passwords), GSSAPI (Kerberos integration), or client certificates (mTLS).
  3. Authorization (ACLs): The authorizer plugin evaluates access requests matching rules: (Principal, Operation, Host, Resource Type, Resource Name, Pattern Type, Permission Type).

Internal Architecture

Kafka brokers run an Authorizer plugin (e.g. the standard AclAuthorizer). When a client requests an operation (e.g. producing to a topic), the broker intercepts the request and verifies the client principal against stored ACL rules in the metadata store (KRaft or ZooKeeper). If no ACL matches and allow.everyone.if.no.acl.found is false, the request is denied.

Visual Explanation

Below is an ASCII representation of the security flow from client authentication to authorizer approval: 

[Client App] ──(TLS Handshake)──> [Broker Listener: SASL_SSL]
     │                                     │
     ▼ (SASL/SCRAM Authentication)         ▼ (Verifies Credentials)
[Authenticated Principal: user_alice] ───> [AclAuthorizer Plugin]
                                           │
                                           ▼ (Check ACL: Allow Write topic_orders)
                                     [Write Approved] ───> [Topic Log Partition]

Practical Example

Here is a Java client configuration for a secure connection using SASL_SSL and SCRAM-SHA-512, followed by a CLI command to grant produce permission:

Create an ACL rule allowing user alice to write to the topic orders:

Common Mistakes

  • Using SASL/PLAIN in production without TLS encryption: Sending cleartext passwords over the wire. PLAIN authentication must always be layered with SSL/TLS (using SASL_SSL protocol) to protect credentials.
  • Broad wildcard ACL rules: Granting All operations on topic * to user groups. This violates the principle of least privilege and increases vulnerability scope.

Quick Quiz

Q1: What is the difference between SSL and SASL in a Kafka deployment?

SSL (TLS) handles connection encryption (privacy) and certificate validation. SASL handles application-level client authentication (username/password or tickets verification).

Q2: What happens if a client attempts to connect and write to a topic but no matching ACL rules exist?

The authorizer denies access by default (unless allow.everyone.if.no.acl.found is explicitly configured to true).

Scenario-Based Challenge

The Challenge: Rotating TLS certificates without cluster downtime

Your company policy dictates that TLS certificates on brokers must be rotated every 90 days. If you restart the entire cluster to load the new certificates, clients encounter socket exceptions. How do you execute this rotation with zero client disruption?

Solution Tip: Load new certificate keys into the broker keystore file, then run the administrative command: kafka-configs.sh --bootstrap-server broker1:9093 --entity-type brokers --entity-name <broker-id> --alter --add-config "listener.name.external.ssl.keystore.location=/path/to/new.keystore". This triggers the broker dynamically to reload the keys on the specific socket listener without restart.

Debugging Exercise

A newly deployed consumer microservice fails to connect, logging: org.apache.kafka.common.errors.SslHandshakeException: General OpenSslEngine problem: PKIX path building failed: unable to find valid certification path to requested target.

The Fix: The client does not trust the certificate authority (CA) that signed the broker's certificate. Import the broker CA root certificate into the client's Java Truststore using the JDK keytool utility, and ensure the client properties point to the correct truststore path and password.

Interview Questions

1. What is SASL/SCRAM and why is it preferred over SASL/PLAIN?

SASL/SCRAM stores credentials hashed with salt (salted challenge-response) in the metadata database, avoiding storing or sending raw plain passwords and mitigating credential theft risks.

2. Can you enforce authorization rules on Kafka consumer groups using ACLs?

Yes. To consume messages, the client principal must have a Read ACL operation on the Topic resource AND a Read operation on the specific Group resource in the ACL database.

Production Considerations

Use a centralized credential provider (like HashiCorp Vault or Kubernetes Secrets) and configure Kafka to dynamically resolve passwords. Always enable host-name verification on client TLS configs to block spoofing attacks.