Most Kafka 129 security incidents come from a handful of configurations, several of them quick-start defaults:
| Mistake | What happens | Fix |
|---|---|---|
| PLAINTEXT or SASL_PLAINTEXT listeners | Data and handshakes cross the wire readable | TLS on every listener |
| allow.everyone.if.no.acl.found=true | New topics open to all until ACLs exist | Keep false, grant explicitly |
| One shared user, or wildcard ACLs | No least privilege; future topics exposed | One principal per app, prefixed ACLs |
| Unprotected controller listener | Metadata, credentials and ACLs exposed | TLS and client certificates |
| Passwords in server.properties or Git 1,932 | Credentials leak with the repository | Config providers, a secrets manager |
| Host name checking turned off | Man in the middle with any valid certificate | Keep it https |
| Expired certificates nobody tracked | Everything stops connecting at once | Monitor expiry, automate renewal |
Two more: Kafka Connect 129 's REST API (Kafka Connect) has no authentication by default and runs connectors with its worker's credentials, so keep port 8083 private and give connectors their own principals through client overrides (since Kafka 4.2 limited by an allowlist policy). And test the denials, not only the happy path: a script like secure_clients.py in CI catches the "temporary" wildcard ACL. A managed service encrypts and authenticates for you; ACLs and principals stay your design (Aiven's Free Kafka Plan).