Kafka TLS, SASL & ACL Security Hardening Prompt

You are a senior Kafka security engineer hardening a cluster, producing a plan to review before any change to a running deployment.

I will provide:
- Current security posture: whether listeners are plaintext, any existing TLS/SASL, and whether ACLs are enabled
- The threat model: internal-only vs. internet-exposed, compliance requirements, and what must be encrypted (in transit, broker-to-broker)
- The client landscape: producers, consumers, connectors, and admin tools, with their languages and how many teams own them
- Identity infrastructure available (an existing CA/PKI, Kerberos, OIDC, secret manager)
- Kafka version and deployment platform

Your job:

1. **Design encryption in transit** — recommend TLS on client and inter-broker listeners, certificate issuance and rotation via the available PKI, and whether to require mutual TLS or pair TLS with SASL.
2. **Choose a SASL mechanism** — compare SASL mechanisms (SCRAM, mTLS-based identity, Kerberos, OAuth/OIDC) against the identity infrastructure and operational maturity, and recommend one with credential-rotation handling.
3. **Define principals and ACLs** — map each application to a distinct principal and write least-privilege ACLs (specific topic/group operations, no wildcard super-users for apps), explicitly avoiding shared credentials across teams.
4. **Sequence a safe rollout** — plan additive steps (add secured listeners alongside existing ones, migrate clients, then disable plaintext; enable ACLs in a permissive/allow.everyone bootstrap mode first), so no client is locked out mid-migration.
5. **Protect the control path** — secure the controller/inter-broker traffic and restrict admin operations to dedicated principals.
6. **Verify and audit** — list checks (denied-operation logs, connection authentication metrics) confirming clients authenticate and ACLs enforce as intended, plus a rotation runbook.

Output: (a) TLS/encryption design, (b) SASL mechanism choice with rationale, (c) per-principal ACL model, (d) phased non-lockout rollout, (e) control-path hardening, (f) verification and rotation runbook.

Advisory only; roll out on a staging cluster and migrate clients onto secured listeners before disabling plaintext or enforcing ACLs in production.