Zookeeper & Kafka 开启安全认证的配置

Zookeeper 和 Kafka 默认部署后，如果没有额外限制，可能会让网络可达的客户端访问集群元数据、创建节点或操作 topic。生产环境中，Zookeeper & Kafka 开启安全认证的配置通常是基础安全加固的一部分，需要同时考虑身份认证、权限控制和客户端兼容。

为什么要同时关注两端

Kafka 依赖 Zookeeper 的部署模式下，Broker 会把部分元数据写入 Zookeeper。如果只给 Kafka 开启认证，而 Zookeeper 仍然允许匿名访问，攻击者或误操作客户端仍可能影响集群状态。反过来，如果 Zookeeper 加固了，但 Kafka 客户端仍可以匿名生产和消费消息，也会留下数据访问风险。

因此，常见做法是：Zookeeper 开启 SASL 或 ACL，Kafka Broker 与 Zookeeper 之间使用认证连接；Kafka 对外监听器启用 SASL、SSL 或两者组合；再通过 ACL 控制 topic、consumer group、cluster 级操作权限。

Zookeeper 侧的配置思路

Zookeeper 侧通常需要准备 JAAS 配置，声明服务端使用的认证模块和账号信息。不同版本、发行版和安全插件的写法可能略有差异，上线前应以实际版本文档为准。示例只表达配置形态：

Server {
  org.apache.zookeeper.server.auth.DigestLoginModule required
  user_kafka="kafka-secret";
};

随后在 Zookeeper 启动参数中引用 JAAS 文件，并开启相关认证提供器。配置完成后，需要确认原有 Kafka Broker 能通过认证连接，否则 Broker 可能无法启动或无法读写元数据。

Kafka 侧的配置思路

Kafka 通常需要区分 Broker 到 Zookeeper、Broker 之间、客户端到 Broker 这几类连接。每类连接的认证协议、监听地址和 JAAS 配置都要对应起来。常见参数包括 listeners、advertised.listeners、security.inter.broker.protocol、sasl.enabled.mechanisms 等。

客户端也需要同步修改连接配置，例如指定安全协议和认证机制：

security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="app" password="secret";

生产环境如果传输链路经过不可信网络，应优先评估 SSL/TLS，避免账号密码或消息内容在明文链路中暴露。

ACL 与验证

认证只证明“你是谁”，授权才决定“你能做什么”。Kafka ACL 可以限制用户对 topic、group、cluster 的读写和管理权限。建议按应用维度创建账号，不要多个系统共用一个高权限用户。

上线前至少验证四件事：未认证客户端无法连接；低权限用户不能访问未授权 topic；正常生产和消费链路不受影响；运维命令在带认证参数后可正常执行。Zookeeper & Kafka 开启安全认证的配置不是一次性改几个参数就结束，还要把账号生命周期、权限回收和审计纳入日常运维。