Kafka 的安全体系围绕传输加密、身份认证、权限授权三层设计
一、Kafka 安全总框架
Kafka 客户端 <->Broker 的安全通信拆为三个独立维度，可组合使用：
传输加密：对网络流量加密，防止窃听、篡改、中间人攻击（底层协议：TLS/SSL）
身份认证：验证 "你是谁"，确认客户端 / 服务端身份合法（分为 SSL 证书认证、SASL 系列认证）
权限授权（ACL）：验证 "你能做什么"，控制对 Topic、Consumer Group 的读写权限（基于认证后的身份做权限控制）二、基础安全传输协议：TLS/SSL
1. 核心作用
对 Broker ↔ 客户端的所有网络流量全程加密
支持服务端证书（客户端验证 Broker 身份，防冒充）
支持双向证书（mTLS）：Broker 同时验证客户端证书，完成身份认证2. 两种工作模式
单向 TLS
只有 Broker 持有证书，客户端验证 Broker 证书合法性
只做传输加密，不做客户端身份认证
双向 TLS（mTLS， mutual TLS）
Broker + 客户端都持有 X.509 证书
传输加密 + 客户端证书认证（用证书作为身份凭证，替代账号密码）3. 优缺点
优点：加密强度高、无密码泄露风险、适合无密码场景
缺点：证书生成 / 分发 / 续期管理繁琐，不适合大量动态客户端三、身份认证机制
Kafka 支持两大类认证体系：SSL 证书认证、SASL 框架认证，其中 SASL 是企业最常用的认证方案。
方式 1：SSL 双向认证（mTLS）
认证载体：X.509 数字证书
流程：客户端出示证书 → Broker 验证证书链与信任库 → 认证通过
本质：用证书唯一标识客户端身份，无用户名 / 密码
适用：内部私有部署、信任边界清晰、可统一管理证书的场景方式 2：SASL 认证框架
SASL（Simple Authentication and Security Layer）是一套认证抽象层，Kafka 内置 4 种生产可用的 SASL 具体机制，这是主流选择：
1）SASL_PLAIN
原理：简单用户名 + 密码明文传递
风险：凭证明文传输，绝对不能单独使用
约束：必须搭配 TLS 加密（即走 SASL_SSL 协议），否则密码会被抓包窃取
适用：测试环境、简单内部系统（不推荐生产长期使用）2）SASL_SCRAM（SCRAM-SHA-256 / SCRAM-SHA-512）
全称：Salted Challenge Response Authentication Mechanism
原理：挑战 - 应答模式，不传输明文密码，仅传输哈希计算结果
安全特点：Broker 只存加盐哈希值，即使被拖库也无法反推原密码；抗重放攻击
优势：比 PLAIN 安全、配置简单、无证书管理负担
适用：中小公司生产环境首选3）SASL_GSSAPI（Kerberos）
基于 Kerberos 网络认证协议，对接 AD 域、FreeIPA、Hadoop 生态统一认证
原理：基于票据（Ticket）完成认证，无密码直接传输
安全等级：企业级最高，支持集中式身份管理、单点登录、票据过期
缺点：部署极其复杂（需 KDC 服务、Principle 管理、密钥分发）
适用：大型企业内网、金融政企、与 Hadoop 生态联动4）SASL_OAUTHBEARER
基于 OAuth 2.0 协议，使用 JWT 令牌认证
流程：客户端先从认证服务器获取 Token → 带给 Kafka Broker → Broker 验证 Token 合法性
适用：云厂商 Kafka（AWS MSK、阿里云消息队列 Kafka 版）、云原生、对接公司 SSO / 统一认证平台四、Kafka 官方 4 种标准安全协议（核心配置）
Kafka 使用配置项 security.protocol 区分传输方式 + 认证方式的组合，这是客户端 / 服务端配置的核心，共 4 种：
| 协议名称 | 传输加密 | 认证方式 | 生产是否可用 | 说明 |
|---|---|---|---|---|
| PLAINTEXT | 无（明文） | 无认证 | ❌ 禁止 | 默认协议，完全不安全，仅限本地调试 |
| SSL | TLS 加密 | SSL 证书认证（双向/单向） | ✅ 推荐 | 加密 + 证书认证，无密码体系 |
| SASL_PLAINTEXT | 无（明文） | SASL 各类机制 | ❌ 禁止 | 认证信息明文传输，极易泄露，仅测试 |
| SASL_SSL | TLS 加密 | SASL 各类机制 | ✅ 生产标准 | 传输加密 + SASL 账号认证，最通用 |
简单理解：
只要带 PLAIN/ 无加密：生产禁用
生产只允许两种：SSL（证书）、SASL_SSL（账号密码类认证）五、各认证 + 传输完整方案对比
| 方案组合 | 加密 | 认证方式 | 部署难度 | 安全等级 | 适用场景 |
|---|---|---|---|---|---|
| PLAINTEXT | 明文 | 无 | 极低 | 极弱 | 本地开发、测试 |
| SSL（单向） | TLS | 无客户端认证 | 低 | 中 | 仅需要流量加密，不限制客户端 |
| SSL（双向 mTLS） | TLS | 证书认证 | 中 | 高 | 内部可信环境、证书统一管理 |
| SASL_SSL + PLAIN | TLS | 用户名密码 | 低 | 中 | 简单测试，不推荐长期生产 |
| SASL_SSL + SCRAM | TLS | 挑战应答哈希 | 低 | 高 | 通用生产首选 |
| SASL_SSL + GSSAPI | TLS | Kerberos | 高 | 最高 | 大型企业、AD 域、Hadoop 生态 |
| SASL_SSL + OAUTHBEARER | TLS | OAuth2.0/JWT | 中 | 高 | 云 Kafka、SSO 对接、云原生 |
六、生产环境标准推荐方案
-
通用业务 / 中小团队
SASL_SSL + SCRAM-SHA-256
平衡安全、维护成本、易用性
无证书管理麻烦，密码不明文传输
-
大型企业 / 统一身份体系
SASL_SSL + GSSAPI(Kerberos)
配合公司 AD、Kerberos 做集中认证
-
云厂商托管 Kafka（阿里云、腾讯云、AWS MSK）
SASL_SSL + OAUTHBEARER 或厂商提供的 SASL 机制
-
高安全合规 / 无密码诉求
SSL（双向 mTLS 证书认证）
七、补充：授权机制（ACL）
认证解决 "你是谁"，ACL（Access Control List） 解决 "你能做什么"，基于认证后的身份（证书 DN、SASL 用户名、Kerberos Principal）配置权限：
支持权限类型：Read、Write、Create、Delete、Describe、Alter 等
控制对象：Topic、Consumer Group、Cluster、Transaction 等
开启方式：Broker 配置 authorizer.class.name=kafka.security.authorizer.AclAuthorizer
常用命令：kafka-acls.sh 增删查权限八、常见误区总结
SASL_PLAINTEXT ≠ 安全：认证信息明文传输，生产严禁使用
SASL_PLAIN 不代表 "安全的密码登录"，必须套在 SASL_SSL 里
SSL ≠ 认证：单向 SSL 只加密不认证，只有双向 SSL (mTLS) 才带认证
SCRAM 优于 PLAIN：不需要传输明文密码，是密码类认证的最优选择
所有生产集群，必须关闭 PLAINTEXT，只开放 SSL / SASL_SSL 端口