Kafka provides a layered set of security mechanisms covering encryption, authentication, and authorization, so clusters can be locked down against unauthorized access and eavesdropping.
Key Points: • SSL/TLS encrypts data in transit between clients and brokers, and between brokers themselves. • SASL mechanisms (PLAIN, SCRAM, GSSAPI/Kerberos, OAUTHBEARER) authenticate the identity of clients and brokers before allowing a connection. • Access Control Lists (ACLs) authorize what an authenticated principal is allowed to do — for example, produce to a topic, consume from a topic, or manage cluster configuration. • Kerberos integration via SASL/GSSAPI supports enterprise environments already standardized on Kerberos-based authentication. • ZooKeeper (or the KRaft controller quorum) communication can also be secured with authentication and encryption, closing a commonly overlooked gap. • Data at rest can be encrypted at the disk/filesystem level, since Kafka itself doesn't natively encrypt data on disk.
Example: A regulated financial services company might combine TLS encryption, SASL/SCRAM authentication, and per-team ACLs so that only the "fraud-detection" service account can consume from a sensitive "transactions" topic, with every access attempt logged for audit purposes.
Interview Tip: A concise interview answer is:
"Kafka's security mechanisms cover encryption with SSL/TLS, authentication with SASL — including Kerberos — and fine-grained authorization with ACLs, and a complete setup also secures the ZooKeeper or KRaft metadata layer and encrypts data at rest at the storage level, since Kafka doesn't do that natively."