Kafka 安全SASL 认证全栈实战从 JAAS 到 Kerberos、PLAIN、SCRAM、OAUTH 与委托令牌

一、JAAS 配置总览

Kafka 使用 JAAS（Java Authentication and Authorization Service） 进行 SASL 配置。

1.1 Broker 的 JAAS 配置

静态 JAAS 文件中，KafkaServer 是每个 KafkaServer/Broker 使用的节（section）名。

它为 broker 端提供 SASL 配置，包括 broker 作为"SASL 客户端 "发起的跨 broker 通信。
如果为多个监听器 配置了 SASL，可用监听器名（小写）+ 点 作为前缀，例如：sasl_ssl.KafkaServer。
也可通过 broker 配置属性 sasl.jaas.config 配置 JAAS。

属性名必须以监听器前缀 + 机制名 开头：
listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config，并且仅能指定一个 login module 。

若一个监听器启用了多个机制，需要分别为每个机制提供配置。

示例：

properties 复制代码

listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
    username="admin" \
    password="admin-secret";

listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="admin" \
    password="admin-secret" \
    user_admin="admin-secret" \
    user_alice="alice-secret";

优先级（从高到低）
1. listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config（broker 配置属性）
2. 静态 JAAS 配置中的 {listenerName}.KafkaServer 节
3. 静态 JAAS 配置中的 KafkaServer 节

机制示例详见下文各节：GSSAPI(Kerberos)、PLAIN、SCRAM、OAUTHBEARER（非生产/生产）。

1.2 客户端的 JAAS 配置

客户端既可以通过客户端属性 sasl.jaas.config 配置，也可以使用静态 JAAS 文件。
客户端属性方式 允许同一 JVM 内不同 Producer/Consumer 使用不同凭据 。若同时指定系统属性 java.security.auth.login.config 与客户端属性 sasl.jaas.config，客户端属性优先。

静态文件方式：

新增含 KafkaClient 节的 JAAS 文件，在其中配置所选机制的 login module。

例如 GSSAPI：

properties 复制代码

KafkaClient {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_client.keytab"
    principal="kafka-client-1@EXAMPLE.COM";
};

通过 JVM 参数传递路径：
-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf

二、SASL 基础配置与支持机制

SASL 可以与 PLAINTEXT 或 SSL 作为传输层使用，分别对应 SASL_PLAINTEXT 与 SASL_SSL 。

使用 SASL_SSL 时必须同时正确配置 SSL。
Kafka 支持的 SASL 机制：
- GSSAPI（Kerberos）
- PLAIN
- SCRAM-SHA-256
- SCRAM-SHA-512
- OAUTHBEARER

2.1 Broker 侧最小配置

在 server.properties 中为 SASL 开端口（可多值逗号分隔）：
properties 复制代码
```
listeners=SASL_PLAINTEXT://host.name:port
```
如仅配置 SASL 端口（或希望 broker 间也使用 SASL）：
properties 复制代码
```
security.inter.broker.protocol=SASL_PLAINTEXT   # 或 SASL_SSL
```
选择一种或多种机制在 broker 上启用，并按对应机制完成配置（下文详述）。

2.2 客户端侧最小配置

SASL 认证仅支持新的 Java Producer/Consumer API（旧 API 不支持）。
客户端需选择 broker 端已启用的机制，按该机制配置。

注意： 建立 SASL 连接时，客户端可能对 broker 地址做反向 DNS 查询 。若未使用 FQDN，bootstrap.servers 与 broker 的 advertised.listeners 都可能导致握手变慢。

三、SASL/Kerberos（GSSAPI）

3.1 先决条件

若组织已有 Kerberos（如 AD），无需额外安装；否则需按照发行版指引安装。

使用 Oracle Java 时，需下载对应版本的 JCE 策略文件 到 $JAVA_HOME/jre/lib/security。
创建 Kerberos Principal：
- 使用组织的 KDC/AD：为每个 broker 和每个使用 Kerberos 的系统用户申请 principal。
- 自建 KDC：示例命令
  bash 复制代码
```
sudo /usr/sbin/kadmin.local -q 'addprinc -randkey kafka/{hostname}@{REALM}'
sudo /usr/sbin/kadmin.local -q "ktadd -k /etc/security/keytabs/{keytabname}.keytab kafka/{hostname}@{REALM}"
```
- 请确保所有主机都能通过 FQDN 解析（Kerberos 要求）。

3.2 配置 Broker

JAAS（每个 broker 自己的 keytab）：

properties 复制代码

KafkaServer {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_server.keytab"
    principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
};

JVM 参数：

-Djava.security.krb5.conf=/etc/kafka/krb5.conf
-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf

确保 keytab 对运行 broker 的系统用户可读。

server.properties：

properties 复制代码

listeners=SASL_PLAINTEXT://host.name:port
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=GSSAPI
sasl.enabled.mechanisms=GSSAPI

服务名需与 principal 的服务名一致（例：kafka/...）：

properties 复制代码

sasl.kerberos.service.name=kafka

3.3 配置客户端

为 Producer/Consumer/Connect 申请或创建各自的 principal。

长运行进程推荐 keytab：

properties 复制代码

sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
    useKeyTab=true \
    storeKey=true  \
    keyTab="/etc/security/keytabs/kafka_client.keytab" \
    principal="kafka-client-1@EXAMPLE.COM";

命令行工具可使用 kinit + 缓存：

properties 复制代码

sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
    useTicketCache=true;

也可用 JVM 参数指向 JAAS 文件（客户端节名为 KafkaClient；同 JVM 内仅一个用户）。
可选：为客户端 JVM 指定 krb5.conf：
-Djava.security.krb5.conf=/etc/kafka/krb5.conf

客户端基本属性：

properties 复制代码

security.protocol=SASL_PLAINTEXT   # 或 SASL_SSL
sasl.mechanism=GSSAPI
sasl.kerberos.service.name=kafka

四、SASL/PLAIN

SASL/PLAIN ：简单的用户名/密码机制，通常与 TLS 一起使用以保证密文传输。
默认 principal.builder.class 下，用户名为认证后的 Principal（用于 ACL）。

4.1 Broker 配置

JAAS：

properties 复制代码

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin-secret"
    user_alice="alice-secret";
};

username/password：broker 作为客户端与其他 broker 通信时的账号（本例 admin）。
user_<name>：定义所有会连接到 broker 的用户密码（包括来自其他 broker 的连接）。

JVM 参数：

-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
server.properties：

properties 复制代码

listeners=SASL_SSL://host.name:port
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=PLAIN
sasl.enabled.mechanisms=PLAIN

4.2 客户端配置

客户端 JAAS：

properties 复制代码

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="alice" \
    password="alice-secret";

客户端基本属性：

properties 复制代码

security.protocol=SASL_SSL
sasl.mechanism=PLAIN

生产建议 ：SASL/PLAIN 必须配合 SSL 使用以避免明文口令在网络中传输。Kafka 2.0+ 可用自定义回调从外部凭据源获取口令（sasl.server.callback.handler.class、sasl.client.callback.handler.class），并可接入外部认证服务。

五、SASL/SCRAM（SHA-256 / SHA-512）

SCRAM （RFC 5802）：更安全的口令认证机制族。Kafka 支持 SCRAM-SHA-256 与 SCRAM-SHA-512。
默认 principal.builder.class：用户名即 Principal（用于 ACL）。
Kafka 默认将 SCRAM 凭据存储于元数据日志（见安全考量）。

5.1 创建 SCRAM 凭据

使用元数据日志作为凭据存储。可通过 kafka-storage.sh 或 kafka-configs.sh 创建。
每种启用的机制都需要创建对应凭据。
broker 间凭据 需在启动前创建（kafka-storage.sh 可在 format 时加入初始凭据）。
客户端凭据可动态创建/更新，新连接会使用最新凭据。

示例：

bash 复制代码

# admin 初始凭据
bin/kafka-storage.sh format -t $(bin/kafka-storage.sh random-uuid) \
  -c config/server.properties \
  --add-scram 'SCRAM-SHA-256=[name="admin",password="admin-secret"]'

# 用户 alice 的凭据
bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter \
  --add-config 'SCRAM-SHA-256=[iterations=8192,password=alice-secret]' \
  --entity-type users --entity-name alice --command-config client.properties

# 查看
bin/kafka-configs.sh --bootstrap-server localhost:9092 --describe \
  --entity-type users --entity-name alice --command-config client.properties

# 删除某机制的凭据
bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter \
  --delete-config 'SCRAM-SHA-256' --entity-type users --entity-name alice \
  --command-config client.properties

默认迭代次数 4096 ，未指定 salt 则随机生成。SCRAM 身份包含 salt、iterations、StoredKey、ServerKey。

5.2 Broker 配置

JAAS：

properties 复制代码

KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required
    username="admin"
    password="admin-secret";
};

JVM 参数：
-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
server.properties：

properties 复制代码

listeners=SASL_SSL://host.name:port
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256   # 或 SCRAM-SHA-512
sasl.enabled.mechanisms=SCRAM-SHA-256                # 或 SCRAM-SHA-512

5.3 客户端配置

客户端 JAAS：

properties 复制代码

sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
    username="alice" \
    password="alice-secret";

客户端基本属性：

properties 复制代码

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256   # 或 SCRAM-SHA-512

5.4 安全考量（SCRAM）

默认将凭据存于元数据日志 ，适用于：KRaft controllers 安全且在私有网络的生产环境。
Kafka 仅支持强哈希 SHA-256/512 ，迭代次数≥4096。强口令 + 高迭代可抵御暴破，即便 controller 安全受损。
必须与 TLS 一起使用，防止拦截/字典/暴破与冒充。
Kafka 2.0+ 可用 sasl.server.callback.handler.class 自定义存储（当 controller 不安全时）。
详见 RFC 5802。

六、SASL/OAUTHBEARER

OAuth2（RFC 6749），SASL OAUTHBEARER（RFC 7628）。
默认实现 会创建/校验不安全的 JWT ，仅适合非生产 ；新版 Kafka 已提供可对接合规 IdP 的生产实现。

默认 principal.builder.class：OAuthBearerToken 的 principalName 作为 Principal（用于 ACL）。

6.1 非生产 Broker 配置

JAAS（不安全 JWT）：

properties 复制代码

KafkaServer {
    org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
    unsecuredLoginStringClaim_sub="admin";
};

unsecuredLoginStringClaim_sub：broker 与其他 broker 连接时放入 sub claim（此处为 admin）。

不安全 JWT 的 broker 侧 JAAS 选项（校验）：

unsecuredValidatorPrincipalClaimName="value"：指定 principal 的字符串 claim 名（默认检查 sub）
unsecuredValidatorScopeClaimName="value"：scope 所在 claim 名（默认 scope）
unsecuredValidatorRequiredScope="value"：空格分隔 scope 值，要求 token scope 包含这些值
unsecuredValidatorAllowableClockSkewMs="value"：允许的正向时钟偏移毫秒（默认 0）

JVM 参数：
-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
server.properties：

properties 复制代码

listeners=SASL_SSL://host.name:port       # 非生产也可 SASL_PLAINTEXT
security.inter.broker.protocol=SASL_SSL   # 或 SASL_PLAINTEXT（非生产）
sasl.mechanism.inter.broker.protocol=OAUTHBEARER
sasl.enabled.mechanisms=OAUTHBEARER

6.2 生产 Broker 配置（对接 IdP）

JAAS：

properties 复制代码

KafkaServer {
    org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
};

JVM 参数：
-Djava.security.auth.login.config=/etc/kafka/kafka_server_jaas.conf
server.properties：

properties 复制代码

listeners=SASL_SSL://host.name:port
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=OAUTHBEARER
sasl.enabled.mechanisms=OAUTHBEARER

listener.name.<listener>.oauthbearer.sasl.server.callback.handler.class=\
  org.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler
listener.name.<listener>.oauthbearer.sasl.oauthbearer.jwks.endpoint.url=https://example.com/oauth2/v1/keys

其它可用的 broker 端 OAUTHBEARER 配置：
- sasl.oauthbearer.clock.skew.seconds
- sasl.oauthbearer.expected.audience
- sasl.oauthbearer.expected.issuer
- sasl.oauthbearer.jwks.endpoint.refresh.ms
- sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms
- sasl.oauthbearer.jwks.endpoint.retry.backoff.ms
- sasl.oauthbearer.jwks.endpoint.url
- sasl.oauthbearer.scope.claim.name
- sasl.oauthbearer.sub.claim.name

6.3 非生产客户端配置

客户端 JAAS（不安全 JWT）：

properties 复制代码

sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
    unsecuredLoginStringClaim_sub="alice";

不安全 JWT 的客户端侧 JAAS 选项（以及 broker 侧在 OAUTH 作为内部协议时）：
- unsecuredLoginStringClaim_<claimname>="value"
- unsecuredLoginNumberClaim_<claimname>="value"
- unsecuredLoginListClaim_<claimname>="|v1|v2"
- unsecuredLoginExtension_<extensionname>="value"
- unsecuredLoginPrincipalClaimName
- unsecuredLoginLifetimeSeconds（默认 3600 秒）
- unsecuredLoginScopeClaimName（默认 scope）

客户端基本属性：

properties 复制代码

security.protocol=SASL_SSL   # 非生产可 SASL_PLAINTEXT
sasl.mechanism=OAUTHBEARER

默认 OAUTHBEARER 实现依赖 jackson-databind（可选依赖），需在构建工具中显式添加。

6.4 生产客户端配置（对接 IdP）

客户端 JAAS（生产模式）：

properties 复制代码

sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;

例：client_credentials 授权：

properties 复制代码

security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.oauthbearer.jwt.retriever.class=org.apache.kafka.common.security.oauthbearer.ClientCredentialsJwtRetriever
sasl.oauthbearer.client.credentials.client.id=jdoe
sasl.oauthbearer.client.credentials.client.secret=$3cr3+
sasl.oauthbearer.scope=my-application-scope
sasl.oauthbearer.token.endpoint.url=https://example.com/oauth2/v1/token

例：urn:ietf:params:oauth:grant-type:jwt-bearer 授权：

properties 复制代码

security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.oauthbearer.jwt.retriever.class=org.apache.kafka.common.security.oauthbearer.JwtBearerJwtRetriever
sasl.oauthbearer.assertion.private.key.file=/path/to/private.key
sasl.oauthbearer.assertion.algorithm=RS256
sasl.oauthbearer.assertion.claim.exp.seconds=600
sasl.oauthbearer.assertion.template.file=/path/to/template.json
sasl.oauthbearer.scope=my-application-scope
sasl.oauthbearer.token.endpoint.url=https://example.com/oauth2/v1/token

其它 客户端 OAUTHBEARER 配置项（完整列出）：
- sasl.oauthbearer.assertion.algorithm
- sasl.oauthbearer.assertion.claim.aud
- sasl.oauthbearer.assertion.claim.exp.seconds
- sasl.oauthbearer.assertion.claim.iss
- sasl.oauthbearer.assertion.claim.jti.include
- sasl.oauthbearer.assertion.claim.nbf.seconds
- sasl.oauthbearer.assertion.claim.sub
- sasl.oauthbearer.assertion.file
- sasl.oauthbearer.assertion.private.key.file
- sasl.oauthbearer.assertion.private.key.passphrase
- sasl.oauthbearer.assertion.template.file
- sasl.oauthbearer.client.credentials.client.id
- sasl.oauthbearer.client.credentials.client.secret
- sasl.oauthbearer.header.urlencode
- sasl.oauthbearer.jwt.retriever.class
- sasl.oauthbearer.jwt.validator.class
- sasl.oauthbearer.scope
- sasl.oauthbearer.token.endpoint.url
Token 自动刷新参数（Producer/Consumer/Broker 通用）：
- sasl.login.refresh.window.factor
- sasl.login.refresh.window.jitter
- sasl.login.refresh.min.period.seconds
- sasl.login.refresh.min.buffer.seconds
生产安全要求 ：

必须实现 AuthenticateCallbackHandler 来处理：
- 客户端登录回调 OAuthBearerTokenCallback（sasl.login.callback.handler.class）
- Broker 侧校验回调 OAuthBearerValidatorCallback（listener.name.<listener>.oauthbearer.sasl.server.callback.handler.class）
安全要点 ：

默认不安全实现仅限非生产 ；在生产中必须使用 TLS （SASL_SSL），并覆盖默认实现。更多 OAuth2 安全建议见 RFC 6749 §10。

七、在 Broker 上同时启用多种机制

在 JAAS 文件的 KafkaServer 节中为所有启用的机制提供 login modules，例如：

properties 复制代码

KafkaServer {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_server.keytab"
    principal="kafka/kafka1.hostname.com@EXAMPLE.COM";

    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin-secret"
    user_alice="alice-secret";
};

在 server.properties 启用机制：

properties 复制代码

sasl.enabled.mechanisms=GSSAPI,PLAIN,SCRAM-SHA-256,SCRAM-SHA-512,OAUTHBEARER

指定跨 broker的协议与机制（如需要）：

properties 复制代码

security.inter.broker.protocol=SASL_PLAINTEXT   # 或 SASL_SSL
sasl.mechanism.inter.broker.protocol=GSSAPI     # 或其它启用机制

然后按各机制章节完成剩余配置。

八、在运行中的集群修改 SASL 机制

在所有 broker 中将新机制 加入 sasl.enabled.mechanisms，并在 JAAS 中同时包含新旧机制 ；滚动重启集群。
重启客户端 ，使之使用新机制。
若要修改跨 broker 机制 ：设置 sasl.mechanism.inter.broker.protocol 为新机制，再次滚动重启。
若要移除旧机制 ：从 sasl.enabled.mechanisms 与 JAAS 中删除其配置，再滚动重启。

九、委托令牌（Delegation Tokens）

轻量认证机制，用于补充 SASL/SSL。令牌是 broker 与客户端间共享的机密。
适合在安全环境中把工作分发到机器上，避免分发 Kerberos TGT/keytab 或双向 SSL 的 keystore。
详细设计见 KIP-48。
默认 principal.builder.class：令牌所有者作为认证后的 Principal（用于 ACL）。

9.1 典型使用流程

用户先通过 SASL 或 SSL 认证到 Kafka，获取委托令牌 （Admin API 或 kafka-delegation-tokens.sh）。
用户将令牌安全地分发给 Kafka 客户端用于认证。
令牌所有者/更新者 可以续期/过期令牌。

9.2 令牌管理

使用 delegation.token.secret.key 作为生成/校验令牌的共享密钥 ；必须在所有 broker 与 controllers 上一致。未设或为空将导致令牌认证与 API 失败。
令牌详情与其他元数据存放在 controller 节点；当 controllers 在私网或与 brokers 间通信加密时可使用。
目前该密钥以明文写在 server.properties，后续版本计划改进。
令牌有当前有效期 与最大可续期寿命 ：默认每 24 小时 续期一次，最长 7 天 ；通过 delegation.token.expiry.time.ms 与 delegation.token.max.lifetime.ms 配置。
令牌可被显式取消；若未续期或超过最大寿命，将从所有 broker 缓存删除。

9.3 创建与管理令牌（脚本示例）

令牌请求（创建/续期/过期/描述）必须在已通过 SASL 或 SSL 认证 的通道上发起；若初始认证是令牌本身，则不能请求令牌。

可通过 --owner-principal 为其他所有者创建。所有者/更新者可续期/过期；其总能描述自己的令牌；要描述他人的令牌，需要在表示该所有者的 User 资源上添加 DESCRIBE_TOKEN 权限。

bash 复制代码

# 创建令牌
bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --create \
  --max-life-time-period -1 --command-config client.properties \
  --renewer-principal User:user1

# 为不同所有者创建令牌
bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --create \
  --max-life-time-period -1 --command-config client.properties \
  --renewer-principal User:user1 --owner-principal User:owner1

# 续期
bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --renew \
  --renew-time-period -1 --command-config client.properties --hmac ABCDEFGHIJK

# 过期
bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --expire \
  --expiry-time-period -1 --command-config client.properties --hmac ABCDEFGHIJK

# 描述
bin/kafka-delegation-tokens.sh --bootstrap-server localhost:9092 --describe \
  --command-config client.properties --owner-principal User:user1

9.4 令牌认证（客户端）

委托令牌认证叠加在 SASL/SCRAM 之上，因此需先启用 SCRAM。
客户端 JAAS：
properties 复制代码
```
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
    username="tokenID123" \
    password="lAYYSFmLs4bTjf+lTZ1LCHR/ZZFNA==" \
    tokenauth="true";
```
其中 username 为令牌 ID 、password 为令牌 HMAC ，tokenauth=true 告知服务器进行令牌认证。同 JVM 内不同客户端可使用不同令牌。
也可通过 JVM 参数指定 JAAS（KafkaClient 节；同 JVM 内仅一个用户）。

9.5 手动轮换共享密钥

需要滚动发布 ；期间已连接 客户端不受影响，但新连接 与旧令牌的续期/过期可能失败。
步骤：
1. 让所有现有令牌过期
2. 滚动升级 轮换 delegation.token.secret.key
3. 生成新令牌
计划在未来 Kafka 版本自动化该流程。

十、实践建议与收官清单

选择合适机制：
- 企业内首选 Kerberos 或 SCRAM（配合 TLS）；
- Web/云原生生态更倾向 OAUTHBEARER（生产对接 IdP，务必启用 TLS 与回调处理器）；
- PLAIN 仅在 TLS 下使用，并建议外部化口令源。
统一 FQDN 与 DNS，避免握手缓慢与 Kerberos 失败。
多机制过渡：先增加、滚动、切客户端、再切 inter-broker、最后移除旧机制。
密钥/凭据治理：SCRAM 迭代次数≥4096，强口令；OAUTH token 按期刷新；委托令牌定期轮换共享密钥。
最小权限与审计：结合 ACL 做权限收口，记录登录失败与令牌操作日志。

落地清单（不遗漏关键项）