标签：Kafka | SASL | SSL | ACL | 多租户 | SCRAM | 配额 | 安全
适合人群：要把"裸奔"的 Kafka 集群接入认证授权、或正在做多租户隔离的工程师
阅读收益：搞清楚 SSL 握手失败最高发的坑、SASL 机制怎么选、ACL Authorizer 在 KRaft 下换成了谁、以及配额"按 Broker 算"对多租户意味着什么
前言：90% 的 SSL 握手失败，原因不在证书本身
Spring Kafka 双向认证握手失败，日志提示 No X.509 cert selected，但密钥库里明明有证书。
排查下来，最高发的原因占同场景问题的 90% 以上：只配了 ssl.key-store-password，没有单独配置 ssl.key-password。Spring Kafka 底层依赖的 Apache Kafka Java 客户端，在 JDK 11+ 和客户端 2.7+ 上不会自动用密钥库密码去解锁私钥。即使生成 PKCS12 文件时两个密码完全一样，私钥也会被判定为不可访问，最终返回空证书列表。
另一个静默坑是后缀与格式不匹配：给 PKCS12 格式的密钥库文件用了 .jks 后缀，部分 Spring Boot 版本的 SSL 类型自动探测会按 JKS 格式加载，失败后直接返回空密钥库，启动时不抛异常，只在握手时表现为没有证书。
安全加固的第一课不是"配什么"，而是知道哪些错误是静默的。这篇按认证（SASL）→ 加密（SSL）→ 授权（ACL）→ 隔离（Quotas）的顺序，把最容易踩的配置坑和语义误解讲清楚。
一、先理清三层：认证、授权、加密，缺一不可
Kafka 的安全体系分三层，很多人把它们混在一起谈，导致配置时顾此失彼：
SASL/PLAIN 本身不提供加密，用户名密码以 Base64 编码传输，可轻易解码。所以 PLAIN 在生产中必须和 TLS 捆绑为 SASL_SSL，不能单独使用 SASL_PLAINTEXT。
在 SASL 机制的选择上，SCRAM 优于 PLAIN 的根本原因是：服务端不存储明文密码，而是存储加盐的挑战---响应凭证。SCRAM 用户可以通过 kafka-configs.sh 动态创建，无需重启 Broker：
bash
bin/kafka-configs.sh --bootstrap-server broker:9093 \
--alter --add-config 'SCRAM-SHA-512=[password=AppPass]' \
--entity-type users --entity-name app-user迭代次数建议不低于 8192。PLAIN 的凭据固化在 JAAS 文件中，新增用户需要滚动重启，运维成本更高。
二、SSL 双向认证：把静默失败当成默认假设
双向认证（mTLS）要求客户端也出示证书。除了前面提到的 ssl.key-password 和密钥库后缀/格式两个高发坑，还有两个容易被忽略的细节：
证书颁发者 DN 必须逐字符匹配。 不要凭肉眼判断"看起来是同一个 CA"。JDK 对 DN 的 O、OU、L、C、CN 字段的顺序、拼写、前后空格都做严格比对，任意一处不一致就会判定证书不在服务端信任范围内。
ExtendedKeyUsage 必须包含 clientAuth。 如果证书签发时只配置了 serverAuth，JDK 会判定它不能用于 TLS 客户端身份认证，不会选中返回。
验证密钥库是否真正加载成功，可以把 org.apache.kafka.common.security.ssl 的日志级别设为 DEBUG，启动时查看成功加载的密钥库别名数量。如果显示加载 0 个别名，说明问题在密码、格式或权限，而不是证书内容。
避坑 1：SSL 双向认证先配齐 ssl.key-password，确保密钥库后缀与格式一致，再用 DEBUG 日志验证"别名数 > 0"。证书内容排查放到最后。
三、ACL 与 Authorizer：KRaft 下 AclAuthorizer 已经换人了
启用 ACL 的起点是 Authorizer。这里有一个 KRaft 时代的版本性变化：
StandardAuthorizer 是 AclAuthorizer 的 drop-in replacement，支持相同的 super.users 和 allow.everyone.if.no.acl.found 配置键。如果继续在 KRaft 集群上配 AclAuthorizer，ACL 不会被正确加载。
allow.everyone.if.no.acl.found 的生产语义必须理解清楚：默认 false 是安全的选择------如果一个资源没有任何 ACL，除了超级用户，谁都无权访问。把它设成 true 来"快速打通"是典型的测试环境习惯，在生产中等于未配置 ACL 的资源对所有人开放。还有已知问题显示，在 KRaft 集群上 allow.everyone.if.no.acl.found=true 且没有正确配置 super.users 时，重启/恢复可能不稳定；false + 显式 super.users 是更稳的组合。
ACL 配置本身要遵循最小权限：生产者需要 Write + Describe，消费者需要 Read + Describe，consumer group 需要 Read。用 kafka-acls.sh 显式授予，不要依赖"没有 ACL 就默认放行"的路径。
避坑 2：KRaft 集群用 StandardAuthorizer，不是 AclAuthorizer。allow.everyone.if.no.acl.found 保持 false，用 super.users 兜底运维身份。
四、多租户隔离：配额是按 Broker 算的，不是按集群算的
ACL 解决的是"能不能访问"，Quotas 解决的是"能占用多少资源"。没有配额，一个行为不当的客户端可以独占 Broker 的网络和 I/O 线程，对其他租户造成事实上的 DoS。
Kafka 有两类配额：
最关键、也最容易被误解的语义是：配额是按 Broker 强制的，不是按集群强制的。 一个用户在 3 个 Broker 的集群上配置 producer_byte_rate=5MB/s，意味着它在每个 Broker 上最多 5MB/s，集群总有效速率是 5 × 3 = 15MB/s。规划多租户配额时，必须用"单 Broker 配额 × Broker 数"来估算租户的实际总带宽。
配额的优先级从高到低是：(user, client-id) > user > client-id > 默认值。client.id 由客户端自己选择，不可信；多租户隔离的主边界应该建立在认证用户（user principal） 上，用 client.id 做更细的覆盖。
设置用户配额的命令：
bash
bin/kafka-configs.sh --bootstrap-server broker:9093 \
--alter --add-config 'producer_byte_rate=5242880,consumer_byte_rate=10485760' \
--entity-type users --entity-name tenant-a本篇小结
配额是按集群还是按 Broker？ 按 Broker；集群总有效速率 = 单 Broker 配额 × Broker 数
安全加固的顺序应该是：先把 SSL 配到"别名数 > 0"，再把 SASL 用户和 ACL 收口，最后用 Quotas 划出多租户的资源边界。三层都到位之前，"Kafka 安全"只是一句口号。