谁都能连上来读写数据？——Kafka安全认证和权限控制

# SASL/PLAIN —— 最简单的用户名密码认证
# Broker端配置（server.properties）
listeners=SASL_PLAINTEXT://0.0.0.0:9092
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN
 
# Broker端的JAAS配置（kafka_server_jaas.conf）
KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin-secret"
    user_flink="flink-secret"
    user_producer="producer-secret";
};

// Producer/Consumer端配置SASL认证
Properties props = new Properties();
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=\"flink\" password=\"flink-secret\";");
 
// Flink消费Kafka时也需要配这些参数
// 在KafkaSource.builder()里通过setProperty设置

授权（Authorization）：你能干什么？

Kafka通过ACL控制每个用户对Topic的操作权限：

# 设置ACL权限
 
# 给flink用户授予gift_txn Topic的读权限
kafka-acls.sh --bootstrap-server broker1:9092 \
    --add --allow-principal User:flink \
    --operation Read --topic gift_txn
 
# 给producer用户授予user_event Topic的写权限
kafka-acls.sh --bootstrap-server broker1:9092 \
    --add --allow-principal User:producer \
    --operation Write --topic user_event
 
# 查看Topic的ACL列表
kafka-acls.sh --bootstrap-server broker1:9092 \
    --list --topic gift_txn
 
# 最佳实践：遵循最小权限原则
# 每个应用只给它需要的Topic权限
# Flink Job只给Read，Producer只给Write

加密（Encryption）：数据传输安全

Kafka支持SSL/TLS加密，保护数据在传输过程中不被窃听或篡改。但有性能开销——CPU增加5-10%、吞吐量下降10-20%。是否开启取决于数据敏感度：

数据类型	是否需要SSL	原因
用户行为埋点	可选	数据不敏感，同机房内网传输风险低
交易/支付数据	建议开启	涉及金额，安全合规要求
用户个人信息（PII）	必须开启	GDPR/隐私法规要求
跨公网传输	必须开启	公网暴露必须加密

实战经验：从裸跑到安全加固

在某元宇宙社交公司刚搭完Kafka集群时，为了快速上线没配安全——Broker地址直接暴露在内网，任何服务都能连上来读写任何Topic。当时只有3-4个人用，问题不大。

但后来公司过安全审计，审计报告里赫然写着'Kafka集群无认证授权，存在数据泄露风险'。我花了一个周末补上了SASL/PLAIN认证+ACL授权：

① 给每个应用创建独立账号：flink-dashboard（实时大盘）、flink-risk（风控）、埋点Producer各一个账号。

② 配置ACL最小权限：flink-dashboard只能Read gift_txn和user_event；flink-risk只能Read gift_txn；Producer只能Write。

③ 没有开SSL：因为全部在阿里云VPC内网传输，网络层已经隔离了，SSL的性能开销不值得。审计团队也认可这个方案。

整个加固过程最麻烦的是：所有Producer和Consumer都要加上SASL配置然后重新部署。好在应用不多，半天搞定了。如果是大规模集群，这个改造工程量会大很多。

云厂商托管Kafka的安全

在某短剧出海公司用的是云厂商托管的Kafka，安全由云厂商负责。访问控制通过云平台的RAM（资源访问管理）实现，不需要自己配SASL和ACL。这是托管服务的一大优势——安全开箱即用。

面试高频追问

追问一：SASL/PLAIN和SASL/SCRAM有什么区别？

PLAIN是明文传输密码（需要配合SSL使用才安全），配置简单。SCRAM是基于挑战-响应的认证，密码不会在网络上传输，更安全，但配置稍复杂。生产环境推荐SCRAM或Kerberos。

追问二：Kafka安全对性能影响大吗？

认证和ACL对性能几乎没有影响（只在连接建立时校验一次）。SSL加密影响较大：CPU增加5-10%，吞吐量下降10-20%。所以内网环境可以只开认证+ACL不开SSL。

总结

Kafka安全面试答三层：认证（SASL解决你是谁）、授权（ACL解决你能干什么）、加密（SSL解决传输安全）。生产环境至少要开认证+授权，遵循最小权限原则。能讲出从裸跑到安全加固的实际经历和方案选择逻辑，面试官会觉得你有安全意识和生产环境的运维经验。

下一篇是Kafka系列的最后一篇：20道题总结篇——快速查阅表+面试备战指南！

你们的Kafka集群配了安全认证吗？用的什么方案？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长