4. 网络与安全验收

Confluent 平台的网络与安全验收，核心不是“配置项是否存在”，而是“客户端在真实网络路径上能否按预期被认证、被授权、被加密，并且失败时能被正确拒绝”。一次完整的验收通常要同时覆盖四层：传输层加密（TLS/SSL）、身份认证（SASL）、集群级授权（RBAC）、资源级授权（ACL），再叠加防火墙、负载均衡与 DNS 解析这三条基础连通链路。任何一层缺失，都会让上层验证结果失真。

一、先明确验收对象与判定基线

验收前需要先固化一份“预期矩阵”，否则测试结果无法判断对错。以某生产集群为例，假设 Broker 对外暴露 kafka.example.com:9093（SASL_SSL），内部复制使用 9092（PLAINTEXT），Schema Registry 使用 https://schema.example.com:8081。预期基线可定义为：

• 所有外部客户端必须使用 TLS 1.2 及以上，禁用 TLS 1.0/1.1；
• 认证方式为 SASL/SCRAM-SHA-512，禁止匿名访问；
• RBAC 角色 DeveloperRead 只能读指定 topic，DeveloperWrite 只能写指定 topic；
• ACL 作为兜底，显式拒绝未授权 principal 的 Read/Write；
• 防火墙仅放行 9093、8081、8083 等必要端口，管理端口 9090 不对公网开放；
• DNS 解析结果必须与负载均衡 VIP 一致，且 TTL 合理。

这份基线是后续所有命令和判断的依据，验收报告中的“通过/不通过”都应对应到具体条目。

二、TLS/SSL 验证：证书链、协议版本与主机名

TLS 验证不能只看“能连上”。第一步用 openssl s_client 检查证书链和协议版本：

openssl s_client -connect kafka.example.com:9093 \
  -servername kafka.example.com -tls1_2 -showcerts

重点观察三处：Verify return code 是否为 0；证书链是否完整（服务器证书 + 中间 CA）；Protocol 是否协商为 TLSv1.2 或 TLSv1.3。若返回 unable to verify the first certificate，说明客户端缺少中间 CA，需要在客户端 truststore 中补齐。接着验证主机名匹配：证书 SAN 必须包含 kafka.example.com，否则即使证书有效，Java 客户端也会抛出 No subject alternative names present。

再用 keytool 检查 JKS/PKCS12 信任库内容，确认别名、有效期和指纹：

keytool -list -v -keystore client.truststore.jks \
  -storepass changeit | grep -E "Alias|Valid|SHA256"

最后做一次“负向验证”：强制使用 TLS 1.0 连接，预期应被拒绝。若仍能握手成功，说明 Broker 未正确设置 ssl.enabled.protocols 或 ssl.protocol，属于安全缺陷。

三、SASL 验证：认证成功与失败都要测

SASL 验收要同时覆盖“正确凭据能通过”和“错误凭据被拒绝”。使用 kafka-console-consumer 配合 SASL_SSL 配置：

kafka-console-consumer --bootstrap-server kafka.example.com:9093 \
  --topic orders --from-beginning --max-messages 1 \
  --consumer.config client-sasl.properties

其中 client-sasl.properties 包含：

security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="svc-order-reader" password="******";
ssl.truststore.location=/etc/kafka/client.truststore.jks
ssl.truststore.password=changeit

预期结果是成功消费到 1 条消息。随后把密码改为错误值，预期应返回 SaslAuthenticationException 或 Authentication failed。若错误密码仍能消费，说明 Broker 的 sasl.enabled.mechanisms 或 listener 配置存在漏洞，必须立即修复。

四、RBAC 与 ACL 验证：授权边界要可证伪

RBAC 验证关注“角色绑定是否生效”。假设已通过 confluent iam rbac role-binding create 将 DeveloperRead 绑定给 svc-order-reader，作用域为 orders topic。验证时用该 principal 读取 orders 应成功，读取 payments 应失败并返回 TopicAuthorizationException。这一步是 RBAC 验收的关键：只测“能读”不够，必须测“不能读别的”。

ACL 验证则更细粒度。用 kafka-acls --list 导出当前 ACL，确认存在类似条目：

kafka-acls --bootstrap-server kafka.example.com:9093 \
  --command-config admin.properties --list

预期看到 User:svc-order-reader 对 Topic:orders 的 Read 允许，以及 User:svc-order-writer 对 Topic:orders 的 Write 允许。若 ACL 与 RBAC 同时存在，需明确优先级：Confluent 中 RBAC 与 ACL 是叠加生效的，任一允许即可通过，因此“显式拒绝”必须通过 Deny ACL 实现，否则容易被 RBAC 放行。

五、防火墙、负载均衡与 DNS 连通性测试

基础连通性测试要按“由外到内、由粗到细”的顺序执行。先用 dig 确认 DNS 解析：

dig +short kafka.example.com
# 预期输出：10.20.0.8（负载均衡 VIP）

若返回多个 IP，需确认是否为多活 VIP；若返回内网地址而客户端在公网，说明 DNS 视图配置错误。接着用 nc 或 telnet 测试端口可达性：

nc -zv kafka.example.com 9093
nc -zv kafka.example.com 8081
nc -zv kafka.example.com 9090   # 预期被拒绝

9093 和 8081 应返回 succeeded，9090 应返回 Connection refused 或超时。若 9093 不通，需依次排查：防火墙规则是否放行、负载均衡后端健康检查是否通过、Broker 是否监听正确网卡。负载均衡层还要验证会话保持与故障转移：连续发起 10 次连接，观察是否均匀分布到多个 Broker；手动下线一个后端，确认新连接能自动切换到健康节点，且切换过程中客户端重试后能恢复。

六、验收记录与常见陷阱

建议把上述验证整理为可复用的检查表，每条记录“命令、预期、实际、结论”。常见陷阱包括：只测 TLS 不测 SASL，导致匿名访问被忽略；只测 RBAC 不测 ACL，导致 Deny 规则缺失；DNS 缓存未刷新，测试结果与真实解析不一致；负载均衡健康检查端口与业务端口混用，导致误判。验收结论必须基于“正向通过 + 负向拒绝”双向证据，任何单向通过都不能视为安全验收完成。