Kafka安全加固实战：SASL/PLAIN认证配置详解-育师

1. 为什么你的Kafka需要SASL/PLAIN认证？

最近帮朋友排查一个Kafka数据泄露问题，发现他们测试环境的Kafka集群居然裸奔在公网上，没有任何认证措施。这就像把自家大门钥匙插在门锁上，谁都能随便进出。今天我们就来聊聊如何用SASL/PLAIN给Kafka装上最基础的门锁。

先说说我遇到的实际案例。某电商公司的风控数据通过Kafka传输，由于开发同学图省事直接用了PLAINTEXT协议，结果被外部扫描工具发现了开放端口，导致用户手机号等敏感信息泄露。其实只需要花20分钟配置SASL/PLAIN认证，就能避免这种低级错误。

SASL/PLAIN是Kafka支持的最简单认证方式，相当于给客户端连接设置了账号密码门槛。虽然不如SSL证书或Kerberos安全，但对于内网环境或需要快速上线的场景完全够用。它的核心优势在于：

配置简单：只需修改两个配置文件
零学习成本：就是最基础的账号密码验证
兼容性强：所有Kafka客户端工具都支持

2. 环境准备与基础概念

2.1 实验环境规划

我建议用Docker快速搭建测试环境，避免污染本地系统。这里给出我的标准测试配置：

# 单节点Kafka容器 docker run -d --name kafka \ -p 9092:9092 -p 19092:19092 \ -e KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,SASL_PLAINTEXT://:19092 \ bitnami/kafka:3.6.1

关键端口说明：

9092：内部通信端口（无需认证）
19092：外部访问端口（需认证）
9093：Controller通信端口（集群模式需要）

2.2 必须理解的三个核心配置

第一次配SASL时，我被这几个概念绕晕过：

listeners：定义Kafka监听哪些端口
advertised.listeners：告诉客户端应该连接哪个地址
security.protocol：指定使用哪种安全协议

举个生活化的例子：listeners就像酒店前台电话，advertised.listeners是给客人看的宣传册上的电话，而security.protocol决定了客人需要报暗号才能订房。

3. 服务端配置步步详解

3.1 创建JAAS认证文件

在config目录新建kafka-server-jaas.conf：

KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required user_admin="Admin@123" user_reader="ReadOnly@456"; };

这里我设置了两个账号：

admin：超级管理员
reader：只读账号

重要安全提示：

密码不要用简单数字
生产环境建议定期轮换密码
不同角色分配不同账号

3.2 修改server.properties

关键配置修改点：

# 启用PLAIN机制 sasl.enabled.mechanisms=PLAIN # 监听器配置 listeners=PLAINTEXT://:9092,SASL_PLAINTEXT://:19092 advertised.listeners=PLAINTEXT://localhost:9092,SASL_PLAINTEXT://localhost:19092 # 强制外部连接走认证 security.inter.broker.protocol=PLAINTEXT

遇到过的一个坑：如果advertised.listeners配置成内网IP，外网客户端会连不上。建议先用localhost测试。

3.3 启动服务的正确姿势

用这个命令启动才能加载认证配置：

export KAFKA_OPTS="-Djava.security.auth.login.config=/path/to/kafka-server-jaas.conf" bin/kafka-server-start.sh config/server.properties

如果看到日志输出"Successfully logged in"就说明认证模块加载成功了。

4. 客户端连接全方式实测

4.1 命令行工具认证测试

创建client.conf配置文件：

security.protocol=SASL_PLAINTEXT sasl.mechanism=PLAIN sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="Admin@123";

测试命令示例：

# 创建topic bin/kafka-topics.sh --create \ --topic test-secure \ --bootstrap-server localhost:19092 \ --command-config client.conf # 生产消息 bin/kafka-console-producer.sh \ --bootstrap-server localhost:19092 \ --topic test-secure \ --producer.config client.conf

4.2 Java客户端连接示例

给Java程序添加认证的代码片段：

Properties props = new Properties(); props.put("bootstrap.servers", "localhost:19092"); props.put("security.protocol", "SASL_PLAINTEXT"); props.put("sasl.mechanism", "PLAIN"); props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required " + "username=\"admin\" password=\"Admin@123\";"); // 创建生产者 KafkaProducer<String, String> producer = new KafkaProducer<>(props);

4.3 常见连接问题排查

遇到认证失败时，按这个顺序检查：

确认服务端JAAS文件路径正确
检查端口是否被防火墙拦截
对比客户端和服务端的账号密码
查看Kafka日志中的认证错误详情

5. 生产环境进阶建议

虽然SASL/PLAIN配置简单，但在实际生产环境中还需要注意：

密码管理：考虑使用配置中心动态加载，避免硬编码
权限控制：配合ACL实现细粒度权限管理
监控告警：对认证失败尝试进行监控
协议升级：敏感业务建议升级到SASL_SSL

有次线上事故就是因为开发把测试环境的账号密码写死在代码里，结果测试账号被误用到生产环境。后来我们改用动态凭证才解决这个问题。

6. 与其他认证方式的对比

当需要更高安全级别时，可以考虑这些方案：

认证方式	安全性	配置复杂度	适用场景
SASL/PLAIN	★★☆	★☆☆	内网/测试环境
SASL/SCRAM	★★★	★★☆	生产环境
SASL/Kerberos	★★★★	★★★★	企业级安全要求
SSL双向认证	★★★★	★★★☆	金融级安全要求