如何限制K8s应用仅访问指定Kafka主题？

方案1：SASL_SSL（PLAIN）+ 自定义回调处理器 #

原生Kafka的PLAIN认证默认依赖静态配置的kafka_server_jaas.conf，动态修改密码完全不生效，自定义sasl.server.callback.handler是可落地的生产级方案。

• 落地思路：将用户密码存储在K8s Secret中，自定义回调处理器实现AuthenticateCallbackHandler接口，处理NameCallback和PasswordCallback时直接读取挂载到Kafka容器内的Secret文件，或者通过K8s API实时拉取最新凭证。
• 动态更新：若用Secret挂载方式，K8s会自动更新容器内的文件，只要回调处理器每次认证时都读取最新文件内容，无需重启Kafka；若用API拉取，需给Kafka Pod配置访问K8s API的RBAC权限。应用端重启后即可加载新密码生效。
• 注意点：Kafka配置中需指定listener.name.sasl_ssl.plain.sasl.server.callback.handler.class为自定义类的全路径，同时要确保自定义Jar包放入Kafka的类路径（比如挂载到/opt/kafka/libs目录）。

方案2：K8s NetworkPolicy + Kafka多监听器+ ACLs #

该方案依靠网络隔离+Kafka原生ACL实现，无需修改应用代码，适合快速落地。

• 落地思路：给Kafka配置多个SSL监听器，每个监听器使用不同端口，比如9093分配给生产应用、9094分配给消费应用；在K8s中配置NetworkPolicy，仅允许指定应用Pod访问对应端口——比如生产应用所在Namespace只能连接9093，消费应用只能连接9094。
• Kafka端配置：给每个监听器自定义Principal，比如通过listener.name.ssl_prod.principal.builder.class实现简单构建器，将监听器名称作为Principal（如User:prod-listener），再用kafka-acls.sh给该Principal配置ACL：允许生产指定主题。同理给消费监听器的Principal配置消费权限。
• 动态更新：修改NetworkPolicy或Kafka ACL均无需重启Kafka节点，ACLs实时生效，NetworkPolicy修改后K8s会自动更新规则。

方案3：mTLS认证+ ACLs #

这是生产环境安全性最高的方案，与现有SSL环境兼容，仅需开启双向认证。

• 落地思路：用cert-manager在K8s集群内为每个应用生成专属客户端证书，证书的CN字段设为应用标识（如prod-app）；Kafka端开启ssl.client.auth=required，并配置信任CA为cert-manager的根CA。
• ACL配置：Kafka默认将客户端证书的CN作为Principal（如CN=prod-app），可通过ssl.principal.mapping.rules映射为更友好的格式（比如CN=(.*) -> User:$1），随后给User:prod-app配置生产指定主题的权限，User:cons-app配置消费权限。
• 动态更新：cert-manager可自动轮换证书，应用重启后加载新证书即可，Kafka节点无需重启——因为Kafka会实时验证客户端证书，只要证书在CA信任链内就能通过认证。

选型参考 #

• 追求快速落地、最小改动：选方案2，依靠网络和端口隔离实现粗粒度权限控制；
• 追求细粒度用户级控制、不想使用证书：选方案1，通过自定义回调处理器实现动态密码管理；
• 追求最高安全性、适用于敏感业务场景：选方案3，mTLS+ACL的组合是生产环境标准配置。

内容的提问来源于stack exchange，提问作者mr.wolle