Design a secure multi-tenant Kafka platform where teams cannot access each other's topics.

A secure multi-tenant Kafka platform requires defense in depth across five layers: authentication, authorization, isolation, quotas, and governance. The goal is that a client authenticated as team A cannot read or write team B's topics, cannot exhaust shared resources, and cannot even discover team B's topics if that is a requirement. The first layer is authentication: every client must authenticate with a distinct principal per application, using SASL/SCRAM, mTLS, or Kerberos. Anonymous access must be disabled, and allow.everyone.if.no.acl.found must be false. The second layer is authorization: ACLs must be scoped to the specific topics and groups each application needs, with no wildcards. For stronger isolation, consider using a naming convention where each team's topics are prefixed with the team name (e.g., teamA.orders.created), and use prefixed ACLs to grant each team access only to its prefix. This gives a namespace-like isolation without requiring separate clusters.

The third layer is resource isolation. Even with correct ACLs, one tenant can degrade another tenant's experience by consuming all broker I/O, network bandwidth, or disk. Kafka quotas address this: client quotas limit produce and consume byte rates per principal or client ID, and request quotas limit the percentage of broker threads a client can use. Set quotas per tenant based on their expected load, and monitor for quota violations. The fourth layer is governance: naming conventions, schema registry ownership, and topic lifecycle management. Each topic should have an owning team, and the naming convention should make ownership clear. The schema registry should enforce per-subject compatibility, and teams should not be able to register schemas for other teams' subjects. The fifth layer is monitoring and auditing: log all authentication and authorization decisions, monitor for denied requests, and alert on anomalies. This is essential for detecting misconfigurations and attempted access violations.

A common mistake is to rely on a single cluster with ACLs and assume that is sufficient for multi-tenancy. ACLs prevent unauthorized access, but they do not prevent a tenant from overwhelming the cluster with high throughput. Quotas are essential. Another mistake is to use a shared principal for a team's applications; this makes it impossible to distinguish one application from another and to apply least privilege. Each application should have its own principal. A third mistake is to ignore topic metadata leakage: by default, any authenticated client can list all topics and see their metadata. If tenant isolation requires that teams cannot even see each other's topic names, you need to restrict Describe permissions and consider separate clusters or a custom authorizer. The trade-off is between isolation and operational cost. Separate clusters give the strongest isolation but multiply operational overhead. A single cluster with ACLs, quotas, and naming conventions is cheaper but requires more discipline. Version note: Kafka's authorizer interface is pluggable; if the built-in AclAuthorizer does not meet your needs, you can implement a custom authorizer. In KRaft mode (Kafka 3.x), ACLs are stored in the metadata log, and the authorizer behavior is unchanged. Also consider Confluent's RBAC if you are on Confluent Platform or Cloud, which provides role-based access control at a higher level.