To secure Kafka you need four controls a default installation leaves switched off: authentication, so the cluster knows who is connecting; authorization through ACLs, which limits access to Kafka resources per principal; TLS for data in transit; and volume encryption at rest. Add audit logging and scheduled review, then close every listener, JMX port and legacy ZooKeeper endpoint that lets a client bypass them. An unconfigured cluster lets anyone who can reach port 9092 connect to your Kafka cluster anonymously and unencrypted, which is why most security incidents are misconfigurations, not exploited defects.
What Security Protocols Are Available in Kafka for Authentication and Authorization?
The security architecture is layered: authentication at the listener, authorization at the authorizer, encryption on the wire and on the disk. Every listener binds to a security protocol — PLAINTEXT, SSL, SASL_PLAINTEXT or SASL_SSL — and that setting alone decides whether traffic is encrypted and whether clients must identify themselves. Apache Kafka supports two families of client authentication.
Mutual TLS (mTLS). Both sides present X.509 certificates, so the Kafka broker can verify the client and the client can verify the broker. The principal comes from the certificate's distinguished name and feeds authorization, delivering authentication and encryption in one step — at the cost of running a certificate authority and a rotation process.
SASL. The Simple Authentication and Security Layer is a pluggable framework offering four authentication mechanisms:
- PLAIN — username and password against a server-side credential store, acceptable only over TLS.
- SCRAM-SHA-256/512 — salted challenge-response with credentials in cluster metadata, so rotation needs no restart. The pragmatic default where no directory service exists.
- GSSAPI (Kerberos) — correct where Active Directory or MIT Kerberos already governs identity, giving centralized security.
- OAUTHBEARER — OIDC tokens from your identity provider, suited to containerized, short-lived workloads.
Authorization is separate. Kafka's access control lists are evaluated by an authorizer (StandardAuthorizer under KRaft, AclAuthorizer on legacy ZooKeeper clusters). Each rule binds a principal, operation, resource and host into allow or deny, so a permission can be as narrow as "this service may Read this topic prefix from this subnet", and deny always wins. Those rules are what decides which principals can access Kafka topics, consumer groups and transactional IDs. Role-based access control, mapping groups to reusable bindings rather than thousands of individual ACLs, is not in the open-source project — it comes from commercial distributions or a Kafka proxy.
What Are the Best Practices for Securing Kafka?
The Kafka security best practices below are ordered by what they prevent, not by how hard they are to implement.
Securing your Kafka cluster comes down to a handful of robust security measures, roughly ordered by payoff:
1. Terminate every client and inter-broker listener on TLS, and delete PLAINTEXT listeners entirely.
2. Set allow.everyone.if.no.acl.found=false and grant explicit ACLs per principal.
3. Give each application its own identity; shared credentials make an audit log unusable.
4. Apply least privilege across topics, consumer groups and transactional IDs, using prefixed ACLs so new topics inherit the permission model, and keep ClusterAction, AlterConfigs and DeleteTopics with operators.
5. Encrypt at rest at the volume layer, keep brokers on a private segment reachable only from known clients, and require authentication on JMX and metrics endpoints.
6. Extend the same controls to Kafka Connect workers, REST proxies, Schema Registry and Kafka Streams applications, which all hold credentials; a comprehensive security strategy covers everything holding a credential, not only the brokers.
7. Review and update your security configuration on a schedule, because nothing erodes a security posture faster than expiring certificates and orphaned rules, and both cause outages as well.
Item one is the best practice that pays for itself immediately. The rest matter, but an open listener makes them irrelevant.
How Do I Encrypt Kafka Traffic and Data at Rest?
TLS and volume encryption are the two data security controls most teams reach for first, and neither substitutes for authorization. Encryption in transit means TLS on every hop: between clients and brokers, between cluster members, and out to the controller quorum. Configure keystores and truststores on each node, move inter-broker traffic to an SSL-bearing protocol, and enable hostname verification so a certificate from the wrong host is rejected.
Kafka has no native message encryption, so encryption at rest sits underneath it — LUKS, dm-crypt or cloud volume encryption with keys in a KMS. That adds a layer of security that survives disk disposal, but encryption protects data on decommissioned disks and in stolen snapshots, not against an authorized client reading a topic. Where the data itself is genuinely sensitive, encrypt payloads in the producer and decrypt in the consumer, accepting that the cluster can no longer inspect those fields.
What Are Common Kafka Security Vulnerabilities and Misconfigurations?
The common security challenges in production are configuration errors, not exotic exploits. Almost every security breach of a Kafka cluster starts with one of these:
- An open PLAINTEXT listener left from a proof of concept, reachable from the wider network, allowing unauthenticated read and write.
allow.everyone.if.no.acl.found=true, where authentication is enabled and the authorizer still lets any caller do anything.- Unauthenticated JMX, which exposes internals and, in some configurations, remote code execution paths.
- Wildcard ACLs —
User:*on a topic prefix, added during an incident and never removed. - Unpatched versions, since end-of-life releases stop receiving fixes for Kafka and dependency CVEs, leaving potential security defects in place.
How Do I Secure ZooKeeper in an Apache Kafka Deployment?
ZooKeeper is removed in Kafka 4.0 in favour of KRaft, so this is purely a legacy concern — but a live one, because many enterprise clusters have not migrated. Where ZooKeeper still holds your ACLs and topic metadata, treat it as a control plane: enable authentication between the cluster and the ensemble (Kerberos or DIGEST-MD5), set zookeeper.set.acl=true so znodes carry restrictive permissions rather than world-readable ones, enable TLS on the client and quorum ports, and firewall ports 2181, 2888 and 3888. An unsecured ensemble undoes an otherwise secure cluster: whoever can rewrite metadata can rewrite authorization. It is a second set of security considerations that a KRaft cluster simply does not have.
Is ZooKeeper outdated? For Kafka, yes. KRaft became production-ready in 3.3 and is the only supported mode in 4.0, removing an external system from your infrastructure and shrinking the attack surface. ZooKeeper is still maintained for other projects, but is no longer part of Kafka.
What Is the Best Monitoring and Auditing Tool for Kafka Security?
There is no single answer, because open-source Kafka ships no dedicated audit product. The closest thing is kafka-authorizer-logger, which writes a log line for every authorization decision, denials included. Raise it to INFO so permitted operations are captured alongside rejected ones, ship those security events to your SIEM, and alert on denial spikes, rule changes and unseen principals. Any SIEM will ingest that log; the tooling matters less than correlating events estate-wide. Pair it with security monitoring of authentication failure rates per listener and certificate expiry — Kafka systems that log nothing cannot be investigated after the fact. If you need help getting from an untrusted cluster to a defensible one, AceMQ's 24/7 Kafka support puts senior engineers on it under a 15-minute emergency SLA.
Is Apache Kafka Secure by Default?
No. Deploy Kafka with the shipped configuration and you get a broker that listens on PLAINTEXT, identifies nobody, authorizes everything and encrypts nothing. The built-in security features are mature, but every one is opt-in. Treat the default configuration as a development convenience, and assume any environment nobody hardened is open.
What Is the Role of Confluent in Kafka Security?
Confluent, founded by Kafka's original creators, distributes a commercial platform built on the open-source project. Its distribution adds RBAC, centralized audit logging, secret protection and Schema Registry security on top of the mechanisms already in Apache Kafka, and publishes widely referenced security documentation. None of it is required to secure your estate, but it reduces how much security management you build yourself — a procurement decision more than a technical one.
Do Netflix Use Kafka?
Yes. Netflix has publicly documented Kafka as the backbone of its Keystone pipeline, moving trillions of events per day of real-time data. At that volume data streaming is core infrastructure, and securing Kafka deployments of that size means running with authentication, authorization and encryption enabled as a baseline. AceMQ supports enterprise estates for 130+ customers across 26+ countries with 11+ senior subject matter experts — see our enterprise Kafka services.
