Security protects Kafka data and services from unauthorized access, tampering, disruption, and compromise. In an online store, neglected security could expose payment data, cause financial loss, or damage customer trust. section 13.0
A practical Kafka security posture combines:
- Authentication, so brokers can verify client identities. section 13.0
- Authorization through access control lists (ACLs), so users can access or modify only permitted resources. section 13.0
- Encryption with TLS to protect data in transit and support secure broker and client connections. section 13.2.7 section 15.5.6
- Monitoring for failed authentication attempts, unauthorized access, and encryption overhead. section 15.5.6
Migrating an unsecured cluster
Add a TLS listener and authentication mechanism to every broker, restarting brokers one at a time. Move inter-broker communication to the new listener, then reconfigure clients with TLS and credentials or new key pairs. After verifying every client, disable the old listener. Finally, create and test ACLs before enforcing them; temporary allow-by-default settings reduce disruption but risk being left enabled. section 13.2.7
Figure 13.5 Required steps to secure an unsecured Kafka cluster
Use the migration sequence as a visual checklist for introducing secure listeners, moving clients, disabling the legacy path, and enforcing ACLs. section 13.2.7
