11. Securing Kafka · Learn Labs

Source: Kafka: The Definitive Guide, 2nd Ed., Ch. 11 The framing, which mirrors Ch. 7's on reliability: "Like performance and reliability, security is an aspect of the system that must be addressed for the system AS A WHOLE, rather than component by component. THE SECURITY OF A SYSTEM IS ONLY AS STRONG AS THE WEAKEST LINK, and security processes and policies must be enforced across the system, including the underlying platform."

And the honest trade-off statement: "While it is always preferable to use the strongest and latest security features available, trade-offs are often necessary since INCREASED SECURITY IMPACTS PERFORMANCE, COST, AND USER EXPERIENCE."

Sections

11.12
The five security procedures, and the reference data flowNote that availability is a security concern here, not just an ops concern — and that it explicitly includes ZooKeeper.
11.21
Security protocols — the 2×2 matrixThat last point matters operationally: a client bootstrapping against the EXTERNAL port will only ever be told about EXTERNAL endpoints.
11.39
AuthenticationKafkaPrincipal is established during authentication based on the protocol (e.g. User:Alice) and can be customized via principal.builder.class.
11.41
Security updates without downtimeNote the shape: enable both → migrate clients → migrate inter-broker → remove the old.
11.54
EncryptionThat's a real operational cost of combining end-to-end encryption with compacted topics: key rotation becomes a maintenance window.
11.63
AuthorizationThat second failure mode is genuinely surprising: adding an ACL can revoke access for everyone else who was relying on the "no ACL found" fallback.
11.73
Auditing
11.83
Securing ZooKeeper
11.91
Securing the platform
11.10Failure catalog
What actually breaks in production — Ch. 11 consolidated
11.112
The security decision guide
11.12Self-test
Self-test