Kafka 安全的三层机制
Kafka 的安全能力分三层：传输加密（SSL/TLS）保护链路不被窃听篡改，认证（SASL）确认客户端身份，授权（ACL）决定这个身份能对哪些主题、消费组和集群操作做些什么。生产中通常组合使用，即把 listeners 配置为 SASL_SSL。启用建议分步走：先开认证，再按客户端逐步收紧 ACL，一次性全部拒绝会让尚未改造的业务直接中断。
基本信息
| 加密 | SSL/TLS：服务端配 keystore，客户端配 truststore |
|---|---|
| 认证 | SASL 机制：SCRAM、GSSAPI、PLAIN（PLAIN 仅限内层已加密） |
| 授权 | ACL 控制主题、消费组与集群级操作权限 |
| 常见组合 | listeners=SASL_SSL://0.0.0.0:9093 |
典型使用场景
- 公网或跨机房访问的集群：传输加密是必备项
- 多租户集群：用 ACL 把主题权限收敛到具体应用账号
- 合规审计：需要明确谁在什么时间读写过哪些主题
- 凭据轮换：SCRAM 账号定期改密，配合客户端滚动更新
- 分级迁移：先启用认证观察一段时间，再逐步引入 ACL 规则
服务端与客户端配置片段
服务端与客户端配置片段
# 服务端 server.properties
listeners=SASL_SSL://0.0.0.0:9093
sasl.enabled.mechanisms=SCRAM-SHA-512
ssl.keystore.location=/etc/kafka/ssl/kafka.keystore.jks
ssl.keystore.password=******
ssl.truststore.location=/etc/kafka/ssl/kafka.truststore.jks
# 客户端
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
username="app-order" password="******";机制与不做的后果
| 层次 | 解决的问题 | 不做的后果 |
|---|---|---|
| TLS 加密 | 链路窃听与篡改 | 凭据与业务数据可被明文嗅探 |
| SASL 认证 | 客户端身份是否可信 | 任何能连上端口的人都能读写 |
| ACL 授权 | 操作权限最小化 | 合法账号可越权访问全部主题 |
| 配额 quota | 租户间带宽与请求隔离 | 单租户可打满集群资源 |
开启认证与授权是分步迁移过程：先启用认证，再按客户端逐个启用 ACL，最后才收紧默认策略，一次性全部拒绝会把尚未改造的客户端直接挡在门外。
凭据写进配置文件时要配合文件权限与密钥管理，禁止提交到代码仓库；轮换密码也要留足客户端滚动更新的窗口，避免换密瞬间大面积连接失败。