📚 课程目录第2章认证机制入门

2. 认证机制入门

在 Kafka 中，认证解决的是“客户端是谁”的问题，而授权解决的是“这个身份能做什么”。Confluent Kafka 的认证能力主要建立在 SASL 框架之上，通过不同的 SASL 机制对接不同的身份来源与安全强度。理解四种常见机制——PLAIN、SCRAM、GSSAPI（Kerberos）、OAUTHBEARER——的差异，是后续配置 TLS 加密、ACL 授权和多租户隔离的基础。

一、四种机制的本质差异

SASL/PLAIN 是最简单的机制：客户端把用户名和密码以明文形式放入 SASL 交换报文，Broker 端用配置的 JAAS 或静态用户列表比对。它本身不加密，必须配合 TLS 才能避免密码在网络上裸奔。适合内网测试或已有强网络隔离的环境，生产环境单独使用风险很高。

SASL/SCRAM 在 PLAIN 的基础上引入了挑战—响应机制。密码不再直接传输，而是通过 Salted Challenge Response Authentication Mechanism 完成校验。Confluent 支持 SCRAM-SHA-256 和 SCRAM-SHA-512。用户凭据由 Kafka 自身存储（KRaft 元数据或 ZooKeeper），可通过 kafka-configs 动态增删，适合中小规模、希望减少外部依赖的集群。

SASL/GSSAPI 即 Kerberos 认证。客户端先向 KDC 申请 TGT，再用 TGT 换取访问 Kafka 服务主体（Service Principal）的 Service Ticket，Broker 通过 keytab 验证票据。它适合已有企业级 Kerberos 基础设施、需要单点登录和强身份治理的场景，但部署与运维复杂度最高，时钟同步、DNS 正反向解析、principal 命名都容易成为故障点。

SASL/OAUTHBEARER 基于 OAuth 2.0 的 Bearer Token。客户端从 OIDC 提供方（如 Okta、Azure AD、Keycloak）获取 JWT，Broker 通过 JWKS 端点验证签名与声明。它天然适合云原生、短期凭据和集中式身份管理，Token 过期与刷新逻辑需要客户端正确处理。

二、Broker 端配置要点

Broker 端需要同时声明监听器协议与 SASL 机制。以 SCRAM 为例，server.properties 中关键配置如下：

listeners=SASL_SSL://:9093
advertised.listeners=SASL_SSL://kafka1.example.com:9093
sasl.enabled.mechanisms=SCRAM-SHA-256,SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=\
  org.apache.kafka.common.security.scram.ScramLoginModule required;
security.inter.broker.protocol=SASL_SSL

若使用 GSSAPI，则需在 JAAS 中指定 useKeyTab、keyTab、principal、storeKey 等参数，并确保 krb5.conf 中 realm 与 KDC 地址正确。OAUTHBEARER 则需配置 listener.name.sasl_ssl.oauthbearer.sasl.jaas.config，指定 unsecuredLoginStringClaim_sub 或自定义回调类，并设置 sasl.oauthbearer.jwks.endpoint.url 指向 IdP 的 JWKS 地址。

三、客户端配置与验证

客户端侧通过 sasl.mechanism 与 sasl.jaas.config 指定凭据。以 SCRAM 为例：

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="app-user" password="AppUser@2024";

创建 SCRAM 用户可使用：

kafka-configs --bootstrap-server kafka1:9093 \
  --alter --add-config 'SCRAM-SHA-256=[password=AppUser@2024]' \
  --entity-type users --entity-name app-user

验证时，先用 kafka-broker-api-versions 或 kafka-topics --list 确认连接成功；若失败，重点检查 JAAS 配置的引号与分号、监听器名称前缀是否匹配、TLS 证书是否被信任。GSSAPI 场景下，kinit 能否正常获取票据、klist 是否显示有效 TGT，是排查的第一步。

选型建议：若团队没有专职 Kerberos 运维能力，优先考虑 SCRAM 或 OAUTHBEARER；若已有成熟 IdP 且客户端支持 Token 刷新，OAUTHBEARER 在云环境中扩展性最好。

四、常见误区

把 PLAIN 当作“简单所以安全”，忽略其明文传输风险；
SCRAM 用户创建后未同步到所有 Broker，导致部分节点认证失败；
GSSAPI 中 principal 大小写、realm 与 DNS 解析不一致，票据被拒；
OAUTHBEARER Token 过期后客户端未刷新，连接被 Broker 主动断开。

掌握这四种机制的配置差异与适用边界后，下一步即可结合 TLS 与 ACL，构建完整的“认证—加密—授权”安全链路。