Learn Labs
11. Securing Kafka

11.11 The security decision guide

Choosing a security protocol per listener

SituationProtocol
Internal, physically protected, non-sensitivePLAINTEXT — rarely OK
Internal, need identity, network is trustedSASL_PLAINTEXT — careful
Certificate-based identity, insecure networkSSL + ssl.client.auth
Any external / internet-facing listenerSASL_SSL — the default

Choosing a SASL mechanism

SituationMechanism
You already run Kerberos (AD / OpenLDAP)GSSAPI
Want built-in, no extra servers, secure ZooKeeperSCRAM-SHA-512 — good default
Have an OAuth 2.0 providerOAUTHBEARER + custom callbacks — not the built-in
Must integrate an existing password storePLAIN + custom server callback — never the built-in
Distributing credentials to many workers is hardDelegation tokens

Encryption — pick based on who you're defending against

AdversaryEncryption
Network eavesdropperTLS (SSL / SASL_SSL)
Someone who steals a diskWhole-disk / volume encryption
Platform admin, cloud provider, heap dumps, broker logsEnd-to-end encryption (serializer + KMS)

Production hardening checklist

Authentication

  • SASL_SSL (or SSL) on every non-trivial listener; no bare PLAINTEXT
  • Hostname verification enabled (never disabled)
  • TLSv1.2/1.3 only; cipher suites restricted (≥256-bit)
  • connections.max.reauth.ms set — or compromised credentials live forever
  • Certificate/keytab/token lifetimes short; rotation rehearsed
  • Filesystem permissions on all key stores, trust stores, keytabs
  • Passwords externalized (ConfigProvider) or encrypted (password.encoder.secret); PASSWORD config type used

Authorization

  • authorizer.class.name=kafka.security.authorizer.AclAuthorizer
  • allow.everyone.if.no.acl.found = false
  • super.users empty — or minimal, understood to be unrevocable
  • Broker ACL: Cluster:ClusterAction — brokers only
  • Least privilege; prefixed ACLs per department; group/role authorizer
  • Service principals for long-running apps, not personal ones
  • Deny-ACL incident procedure documented and practised

Encryption

  • Disk/volume encryption on broker log dirs and ZooKeeper dataDir
  • End-to-end encryption for PII/regulated data, plus signatures
  • Kafka compression disabled if encrypting in the serializer
  • Key encryption, if required, uses a hash as the Kafka key

Auditing

  • kafka.authorizer.logger + kafka.request.logger shipped to a log platform
  • Authentication-failure metrics alerted on
  • DEBUG enabled if a full allow-trail is required

ZooKeeper and platform

  • ZK: TLS (3.5.0+) and/or SASL/GSSAPI — never DIGEST-MD5 in production
  • kerberos.removeHostFromPrincipal / removeRealmFromPrincipal = true
  • zookeeper.set.acl = true
  • Network firewalls; restricted config-file access
  • A written threat model covering external and insider threats
  • Quotas configured (Ch. 3) to bound DoS

How the chapter's guarantees map to mechanisms

GuaranteeMechanisms
Client authenticitySASL, or SSL with client auth; reauthentication to limit compromise exposure
Server authenticitySSL with hostname validation, or mutual-auth SASL (Kerberos, SCRAM)
Data privacyTLS in transit; disk/volume encryption at rest; end-to-end for fine-grained control against admins/cloud providers
Data integrityTLS detects tampering; digital signatures in messages under end-to-end encryption
Access controlCustomizable authorizer; built-in AclAuthorizer with fine-grained ACLs
AuditabilityAuthorizer logs + request logs; message-header audit metadata
AvailabilityQuotas + connection management against DoS; ZooKeeper secured with SSL, SASL, and ACLs

On this page