Kafka 安全机制：SASL 认证、SSL 加密与 ACL 授权本文将依次拆解这三种机制，从原理到配置，从命令行验证到

概述

前文已完成 Kafka 集群的搭建与 CLI 工具实战。但在生产环境中，一个没有安全防护的 Kafka 集群等同于敞开大门——任何人都可以读写任何 Topic。Kafka 通过 SASL 认证、SSL 加密和 ACL 授权三道防线，构建了从身份验证到传输加密到权限控制的完整安全体系。本文将在第 2 篇搭建的集群基础上，逐层叠加安全配置，并通过故意制造错误来揭示配置陷阱和排查思路。

Kafka 的安全机制并非为互联网公网场景设计（通常建议在 VPC 内网使用），但即使在内网环境中，认证、加密和授权仍然是企业级部署的必要条件。SASL 回答了“你是谁”，SSL 保证了“没人偷听你们说话”，ACL 则决定了“你能做什么”。本文将依次拆解这三种机制，从原理到配置，从命令行验证到 Spring Boot 整合，并设计了三个故意触发错误的故障场景，帮助读者不仅会配置，更能在配置错误时快速定位和修复。最后，根据安全级别和运维复杂度的权衡，提供一套可落地的安全方案组合决策框架。

核心要点：

SASL 认证：PLAIN、SCRAM、GSSAPI 三种机制的原理、配置与安全评估。
SSL/TLS 加密：单向认证与双向认证（mTLS）的证书生成、配置与性能影响。
ACL 授权：基于 Principal 的细粒度权限控制，kafka-acls.sh 实战。
Spring Boot 整合：通过 application.yml 统一管理安全配置，覆盖 AdminClient、Producer、Consumer。
故障场景模拟：三个故意错误的配置场景，展示错误日志、排查思路与修复方案。
安全方案组合决策：根据安全级别和运维复杂度选择合适的 SASL+SSL+ACL 组合。

文章组织架构图

flowchart TD
    subgraph S1 ["1. Kafka安全体系全景"]
        A1["1. 认证、加密、授权三道防线"]
        A2["1.1 安全协议演变"]
    end
    subgraph S2 ["2. SASL认证"]
        B1["2. SASL 认证机制深度解析"]
        B2["2.1 SASL/PLAIN"]
        B3["2.2 SASL/SCRAM"]
        B4["2.3 SASL/GSSAPI"]
        B5["2.4 三种机制对比"]
    end
    subgraph S3 ["3. SSL加密"]
        C1["3. SSL/TLS 加密传输"]
        C2["3.1 单向认证"]
        C3["3.2 双向认证 mTLS"]
        C4["3.3 性能影响"]
    end
    subgraph S4 ["4-5. 故障模拟"]
        D1["4. 故障模拟一：SASL 认证失败"]
        D2["5. 故障模拟二：SSL 握手失败"]
    end
    subgraph S5 ["6. ACL授权"]
        E1["6. ACL 授权机制"]
        E2["6.1 ACL 规则模型"]
        E3["6.2 kafka-acls.sh 实战"]
        E4["6.3 super.users"]
    end
    subgraph S6 ["7. 故障模拟三"]
        F1["7. 故障模拟三：ACL 权限不足"]
    end
    subgraph S7 ["8. Spring整合"]
        G1["8. Spring Kafka 安全配置实战"]
    end
    subgraph S8 ["9. 决策框架"]
        H1["9. 安全方案组合决策框架"]
    end
    subgraph S9 ["10. 面试专题"]
        I1["10. 面试高频专题"]
    end

    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> S8 --> S9

    classDef topic fill:#f8f9fa,stroke:#333,stroke-width:2px,rx:5,color:#333;
    class S1,S2,S3,S4,S5,S6,S7,S8,S9 topic;

架构图说明：

总览说明：全文 10 个模块从 Kafka 安全体系全景出发，依次深入认证、加密、授权三大核心机制，在每个核心机制后紧跟故障模拟以加深理解，然后整合 Spring Boot 配置，最后提供安全方案组合决策和面试题。
逐模块说明：模块 1 建立安全体系的全局认知；模块 2-3 逐一剖析认证和加密的原理与配置；模块 4-5 通过故障模拟加深理解；模块 6-7 拆解授权机制并进行故障模拟；模块 8 整合 Spring Boot；模块 9 提供决策框架；模块 10 面试巩固。
关键结论：Kafka 安全机制的核心是 SASL + SSL + ACL 的三位一体。理解每种机制的配置原理、常见错误和排查方法，是构建生产级 Kafka 集群的基础。

1. Kafka 安全体系全景：认证、加密、授权的三道防线

1.1 安全设计背景

Kafka 最初为 LinkedIn 内部日志收集而设计，运行在受信任的封闭网络中，因此早期版本没有内置安全功能。随着 Kafka 被越来越多的企业采用，安全需求急剧增加。从 0.9 版本开始，社区逐步引入 SSL 加密、SASL 认证和 ACL 授权，最终形成现今成熟的安全体系。Kafka 的安全并非面向公网直接暴露，但即便是内网部署，多租户环境、敏感数据传输和合规性要求都迫使我们必须开启安全特性。

1.2 三道防线的层次关系

Kafka 安全体系遵循经典的纵深防御模型：

认证（Authentication）：“你是谁？”——验证客户端或 Broker 的身份，防止未授权实体接入集群。
加密（Encryption）：“传输内容是否被窃听或篡改？”——保护数据在网络传输中的机密性和完整性，防止中间人攻击。
授权（Authorization）：“你能做什么？”——控制已认证用户对资源的操作权限，实现最小权限原则。

三者必须协同工作：加密确保通道安全，认证确认通信方身份，授权再基于身份进行细粒度控制。如果只启用加密而不认证，攻击者可能通过窃取的证书接入；如果只认证而不加密，凭证和数据会以明文传输，存在泄露风险；如果只认证和加密而无授权，则任意已认证用户都能访问所有 Topic。

1.3 安全协议的演变

Kafka 通过 security.protocol 配置定义通信安全级别，演变路径如下：

协议	认证	加密	说明
`PLAINTEXT`	无	无	默认，无安全
`SSL`	可选（仅 mTLS 时）	SSL/TLS 加密	无 SASL 认证时可通过 SSL 双向认证验证客户端证书
`SASL_PLAINTEXT`	SASL	无	有认证但数据明文传输，不推荐
`SASL_SSL`	SASL	SSL/TLS	认证+加密，生产最常用

生产环境推荐使用 SASL_SSL，同时获得身份认证和传输加密。

flowchart LR
    A[客户端请求] --> B{安全协议}
    B -->|SASL_SSL| C[SASL 认证层]
    C --> D[SSL/TLS 加密层]
    D --> E[ACL 授权检查]
    E --> F[Broker 处理]
    B -->|其他降级协议| G[跳过对应层级]

图表主旨概括：该图展示了客户端请求依次经过 SASL 认证、SSL 加密和 ACL 授权的完整链路，强调三道防线在单个请求中的串联关系。 逐层分解：认证层负责解析身份（Principal），加密层保障传输安全，授权层基于身份和资源判定许可。 设计原理映射：纵深防御原则，每一层独立检查，任何一层失败都会拒绝请求，确保即使某一层被绕过仍有其他保护。 工程联系与关键结论：在生产配置 security.protocol=SASL_SSL 时，Broker 会同时要求 SASL 握手和 SSL 握手，两者顺序为 SSL 握手先于 SASL 认证，因此证书信任链是第一步检查点。

2. SASL 认证机制深度解析：PLAIN、SCRAM、GSSAPI

SASL（Simple Authentication and Security Layer）是一个认证框架，支持多种机制。Kafka 支持三种主要 SASL 机制：PLAIN、SCRAM 和 GSSAPI（Kerberos）。

2.1 SASL/PLAIN 认证

PLAIN 是最简单的机制，基于用户名和密码的明文传输。注意 PLAIN 本身不具备加密能力，因此必须配合 SASL_SSL 使用，否则密码会在网络中明文传输。

2.1.1 配置方式

Broker 端配置 —— 在所有 Broker 节点创建 JAAS 配置文件，例如 /etc/kafka/kafka_server_jaas.conf：

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin-secret"
    user_producer="producer-secret"
    user_consumer="consumer-secret";
};

PlainLoginModule 中：

username 和 password 为 Broker 本身用于 inter-broker 通信的凭证。
user_<username> 定义客户端可用的用户名和密码，每个 user_ 条目即为一个有效用户。

server.properties 相关配置：

# 启用 SASL/PLAIN，并指定安全协议
listeners=SASL_SSL://:9093
advertised.listeners=SASL_SSL://broker1:9093

# SASL 机制
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN

# 启用 Broker 间认证
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_producer="producer-secret" \
  user_consumer="consumer-secret";

# inter-broker 使用 SASL 认证
security.inter.broker.protocol=SASL_SSL

关键配置差异：Broker 间认证通过 security.inter.broker.protocol 强制使用 SASL，且 super.users 中的超级用户也需要在 JAAS 中定义，例如 super.users=User:admin 可让 admin 绕过 ACL 检查。

2.1.2 客户端配置

客户端需要提供 JAAS 配置或通过 Java 系统属性传递。使用 kafka-console-producer.sh 时，创建 client_jaas.conf：

KafkaClient {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="producer"
    password="producer-secret";
};

命令行指定：

export KAFKA_OPTS="-Djava.security.auth.login.config=/path/client_jaas.conf"
kafka-console-producer.sh --broker-list broker1:9093 --topic test-topic \
  --producer-property security.protocol=SASL_SSL \
  --producer-property sasl.mechanism=PLAIN

2.2 SASL/SCRAM 认证

SCRAM（Salted Challenge Response Authentication Mechanism）解决了 PLAIN 在网络中传输明文密码（即使 SSL 内也存风险）的问题。它使用加盐哈希和挑战-应答方式，服务端不存储明文密码，只存储加盐哈希（如 SCRAM-SHA-256 或 SCRAM-SHA-512）。

2.2.1 安全增强原理

客户端发起认证时，Broker 返回一个随机 challenge（包含盐值和迭代次数）。客户端利用密码和盐值计算证明，服务端验证证明而无需知道密码原文。整个过程避免密码明文传输，且服务端即使被攻破，攻击者也无法直接获取用户密码，因为只存储了单向哈希。

2.2.2 配置 SCRAM 用户凭据

SCRAM 用户凭据不再写在 JAAS 文件中，而是通过 ZooKeeper（或 KRaft 元数据）动态管理，使用 kafka-configs.sh 工具。

# 创建 SCRAM 用户 producer，密码设为 producer-secret
kafka-configs.sh --bootstrap-server broker1:9092 --command-config admin.conf \
  --alter --add-config 'SCRAM-SHA-256=[password=producer-secret]' \
  --entity-type users --entity-name producer

# 查看用户配置
kafka-configs.sh --bootstrap-server broker1:9092 --command-config admin.conf \
  --describe --entity-type users --entity-name producer

输出示例：

Dynamic configs for user-principal 'producer' are:
  SCRAM-SHA-256=sha256=iterations=4096,salt=AbCd1234,stored_key=XYZ...

逐行解读：sha256 表示哈希算法，iterations 为迭代次数，salt 是随机盐值，stored_key 和 server_key 分别是服务端存储的客户端密钥哈希和服务端密钥哈希，用于挑战应答验证。

2.2.3 Broker 配置

server.properties 中启用 SCRAM：

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;

注意 Broker 间认证也需要使用同一 SCRAM 用户，所以必须先用 kafka-configs.sh 为 broker 的 principal 创建凭据，例如用户 admin。

2.3 SASL/GSSAPI (Kerberos)

GSSAPI 使用 Kerberos 协议提供企业级单点登录认证。原理涉及 KDC（密钥分发中心）、TGT（票据授予票据）和 Service Ticket。Kafka Broker 和客户端均需 Kerberos principal 和 keytab 文件。本文聚焦原理和配置流程，详细集成（如与 AD 联动）请参阅官方文档。

Broker 端 JAAS 示例：

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

配置复杂度和运维成本较高，适合已有 Kerberos 基础设施的大型企业。

2.4 三种 SASL 机制安全对比

机制	加密强度	运维复杂度	密码存储	适用场景
PLAIN	无（需 SSL）	低	JAAS 明文	内部低安全环境，与 SSL 组合
SCRAM	挑战-应答保护	中	ZooKeeper 加盐哈希	需要密码安全且不想管理 Kerberos
GSSAPI	Kerberos 协议强认证	高	KDC	已有 Active Directory 或 FreeIPA

接下来通过序列图深入 SASL/PLAIN 的握手过程。

sequenceDiagram
    participant Client
    participant Broker

    Client->>Broker: SSL 握手建立加密通道
    Broker-->>Client: SSL 握手完成
    Client->>Broker: SASL/PLAIN 认证请求 (username, password 经 SSL 加密)
    Broker->>Broker: 查询 JAAS 中 user_<username> 验证密码
    alt 认证成功
        Broker-->>Client: 认证成功
    else 认证失败
        Broker-->>Client: AuthenticationFailedException
    end

图表主旨概括：该序列图描绘了客户端和 Broker 在 SASL_SSL 下使用 PLAIN 机制的交互全过程。 逐层分解：第一步 SSL 握手确保加密隧道，第二步 SASL 认证发送用户名密码，Broker 在本地 JAAS 文件中查找对应用户并比对密码。 设计原理映射：PLAIN 机制依赖 SSL 为密码提供加密保护，Broker 将凭证以明文形式存储于 JAAS 文件，因此文件权限必须严格限制（例如 chmod 600）。 工程联系与关键结论：PLAIN 认证的失败通常表现为 AuthenticationFailedException: Invalid username or password，排查时应首先检查 JAAS 文件中 user_ 条目是否正确，以及客户端连接是否确实使用了 SASL_SSL 而不是 SASL_PLAINTEXT。

3. SSL/TLS 加密传输：单向认证与 mTLS

3.1 SSL/TLS 单向认证

单向认证指客户端验证 Broker 证书，确保连接到合法 Broker，防止中间人攻击。Broker 不验证客户端证书。

3.1.1 证书生成流程

每个 Broker 需要一个密钥对和自签名或 CA 签名的证书。使用 JDK 自带的 keytool 生成：

# 1. 生成 Broker 密钥库（包含私钥和自签名证书）
keytool -genkeypair -alias broker1 -keyalg RSA -keysize 2048 \
  -keystore /etc/kafka/secrets/broker1.keystore.jks \
  -dname "CN=broker1, OU=Kafka, O=MyCompany, L=City, S=State, C=US" \
  -storepass keystore-pass -keypass key-pass -validity 365

# 2. 导出证书到信任库（客户端会导入此信任库）
keytool -exportcert -alias broker1 -keystore /etc/kafka/secrets/broker1.keystore.jks \
  -file /tmp/broker1.crt -storepass keystore-pass

# 3. 创建客户端信任库并导入 Broker 证书
keytool -keystore /etc/kafka/secrets/client.truststore.jks -alias broker1 \
  -importcert -file /tmp/broker1.crt -storepass truststore-pass -noprompt

生产环境建议使用 CA 签发证书，此处为测试演示使用自签名证书。

3.1.2 Broker 配置

server.properties 中启用 SSL：

listeners=SASL_SSL://:9093
advertised.listeners=SASL_SSL://broker1:9093

# 密钥库
listener.name.sasl_ssl.ssl.keystore.location=/etc/kafka/secrets/broker1.keystore.jks
listener.name.sasl_ssl.ssl.keystore.password=keystore-pass
listener.name.sasl_ssl.ssl.key.password=key-pass

# 信任库（单向认证 Broker 不需要验证客户端，但为了扩展可忽略或使用同一文件）
# 单向时可省略 truststore，但许多配置为了方便仍会指定

关键安全参数 ssl.endpoint.identification.algorithm=HTTPS 开启主机名验证，防止中间人伪造证书。

3.1.3 客户端配置

客户端需要配置信任库：

security.protocol=SSL
ssl.truststore.location=/etc/kafka/secrets/client.truststore.jks
ssl.truststore.password=truststore-pass
ssl.endpoint.identification.algorithm=HTTPS

3.2 SSL/TLS 双向认证 (mTLS)

mTLS 要求客户端也提供证书，Broker 验证客户端身份。此时无需 SASL，客户端证书中的 Distinguished Name (DN) 可作为 Principal 用于 ACL 授权。

Broker 配置增加：

listener.name.sasl_ssl.ssl.client.auth=required
listener.name.sasl_ssl.ssl.truststore.location=/etc/kafka/secrets/broker.truststore.jks
listener.name.sasl_ssl.ssl.truststore.password=truststore-pass

同时 broker.truststore.jks 中必须导入所有合法客户端证书或 CA 根证书。客户端需配置自己的密钥库：

ssl.keystore.location=/etc/kafka/secrets/client.keystore.jks
ssl.keystore.password=clientks-pass
ssl.key.password=clientkey-pass

3.3 SSL 性能影响

TLS 加密会增加 CPU 开销和少量延迟。RSA 密钥协商开销较大，现代系统推荐使用 ECDHE 密码套件减少握手延迟。通过 ssl.cipher.suites 限制强加密套件并排除弱算法，如：

ssl.cipher.suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

实际基准测试显示，启用 SSL 后吞吐量下降约 10-20%，延迟增加约 0.1~0.5ms，具体取决于硬件和消息大小。开启会话缓存和会话票据可以重用 TLS 会话，显著降低重复握手开销。

sequenceDiagram
    participant Client
    participant Broker

    Client->>Broker: ClientHello (支持的密码套件等)
    Broker-->>Client: ServerHello, Certificate (Broker 证书), ServerHelloDone
    Client->>Client: 验证 Broker 证书信任链
    opt mTLS
        Broker->>Client: CertificateRequest
        Client-->>Broker: Client Certificate
        Broker->>Broker: 验证客户端证书
    end
    Client->>Broker: ClientKeyExchange, ChangeCipherSpec, Finished
    Broker-->>Client: ChangeCipherSpec, Finished
    Note over Client,Broker: 加密通道建立完成

图表主旨概括：TLS 握手序列展示客户端和 Broker 如何协商加密参数并验证证书。 逐层分解：ClientHello 到 ServerHello 协商加密套件和随机数，Broker 发送证书供客户端验证，可选步骤为 mTLS 要求客户端提交证书，最后双方交换密钥并确认加密套件生效。 设计原理映射：TLS 握手包含非对称加密（密钥交换）和对称加密（数据传输）两层，证书依赖 PKI 信任链，客户端必须信任签署 Broker 证书的 CA。 工程联系与关键结论：单向认证常见错误为客户端缺少信任库或信任库未包含 Broker 证书，导致 SSLHandshakeException: unable to find valid certification path，需要确保 ssl.truststore.location 正确配置且密码无误。

4. 故障模拟一：SASL 认证失败的排查

错误配置：在 Broker 的 JAAS 中设置用户 producer 密码为 correct-pass，但客户端配置中使用 wrong-pass。

Broker 端 JAAS 片段：

user_producer="correct-pass"

客户端 JAAS：

KafkaClient {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="producer"
    password="wrong-pass";
};

错误现象：执行 kafka-console-producer.sh 尝试发送消息时，抛出异常：

org.apache.kafka.common.errors.SaslAuthenticationException: Authentication failed: Invalid username or password
Caused by: javax.security.sasl.SaslException: Authentication failed [CIRCULAR REFERENCE]

完整日志中可见 AuthenticationFailedException。

排查思路：

确认客户端 security.protocol 是否为 SASL_SSL，sasl.mechanism 是否为 PLAIN。
检查客户端 JAAS 文件路径是否正确被 JVM 加载（通过 -Djava.security.auth.login.config）。
核对 Broker 端 JAAS 文件中 user_producer 的密码与客户端一致。
如果使用 SCRAM，则需要通过 kafka-configs.sh --describe 确认凭据正确，并确保 Broker 已启用对应的 SCRAM 机制。
检查 Broker 日志，kafka-authorizer.log 或 server.log 中可能存在 Failed authentication 记录。

修正方案：将客户端 JAAS 中的密码修正为 correct-pass。确认后可正常连接：

kafka-console-producer.sh --broker-list broker1:9093 --topic test-topic \
  --producer-property security.protocol=SASL_SSL \
  --producer-property sasl.mechanism=PLAIN

5. 故障模拟二：SSL 握手失败的排查

错误配置：客户端故意不提供 truststore 或指向空的信任库，导致无法验证 Broker 证书。

客户端属性配置（错误）：

security.protocol=SSL
# 故意不配置 truststore 或使用错误的密码
ssl.truststore.location=/path/to/empty.truststore.jks
ssl.truststore.password=wrongpass

错误现象：客户端启动或发送请求时抛出异常：

org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

或者如果是信任库密码错误：java.io.IOException: Keystore was tampered with, or password was incorrect。

排查思路：

理解证书信任链：客户端信任库必须包含签署 Broker 证书的 CA 证书，或直接包含 Broker 自签名证书。错误“unable to find valid certification path”说明客户端不信任 Broker 提供的证书。
检查 ssl.truststore.location 文件是否存在，路径权限是否正确。
确认 ssl.truststore.password 与创建信任库时一致。
使用 keytool -list -v -keystore client.truststore.jks 查看信任库内的证书摘要，并与 Broker 证书指纹比对。
如果开启主机名验证 ssl.endpoint.identification.algorithm=HTTPS，确保 Broker 证书 CN 或 SAN 包含客户端连接的地址如 broker1，否则会出现 SSLHandshakeException: No subject alternative names matching IP address ... found。

修正方案：正确导入 Broker 证书：

keytool -keystore client.truststore.jks -alias broker1 \
  -importcert -file broker1.crt -storepass truststore-pass

客户端配置：

ssl.truststore.location=/etc/kafka/secrets/client.truststore.jks
ssl.truststore.password=truststore-pass
ssl.endpoint.identification.algorithm=HTTPS

6. ACL 授权机制：细粒度权限控制

6.1 SimpleAclAuthorizer 的 ACL 规则模型

Kafka 使用 SimpleAclAuthorizer 实现 ACL，规则由三元组构成：

Resource：资源类型（Topic、Group、Cluster、TransactionalId、DelegationToken 等）和资源名称。
Operation：操作，如 Read、Write、Describe、Create、Delete、Alter、DescribeConfigs 等。
Principal：主体，即经过 SASL 或 mTLS 认证后的身份，格式 User:用户名 或 User:DN。

每个 ACL 条目绑定 host、operation、permissionType（Allow/Deny），并支持通配符 *。

6.2 `kafka-acls.sh` 的基本使用

授权器需要在 Broker 中配置 authorizer.class.name=kafka.security.authorizer.AclAuthorizer，并指定超级用户：

authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=User:admin;User:superuser

添加 ACL：允许用户 producer 对 Topic orders 拥有 Write 和 Describe 权限。

kafka-acls.sh --bootstrap-server broker1:9093 --command-config admin.conf \
  --add --allow-principal User:producer --operation Write --operation Describe \
  --topic orders

输出示例：

Adding ACLs for resource `Topic:orders`:
  User:producer has Allow permission for operations: Write, Describe from host: *
Current ACLs for resource `Topic:orders`:
  User:producer has Allow permission for operations: Write, Describe from host: *

逐行解读：显示资源 Topic:orders 上新增了一条允许主体 User:producer 在任意主机执行 Write 和 Describe 操作的规则，并回显当前所有 ACL。

查看 ACL：

kafka-acls.sh --bootstrap-server broker1:9093 --command-config admin.conf --list --topic orders

删除 ACL：

kafka-acls.sh --bootstrap-server broker1:9093 --command-config admin.conf \
  --remove --allow-principal User:producer --operation Write --topic orders

6.3 基于前缀的 Topic 权限控制

可以使用 --resource-pattern-type prefixed 针对 Topic 前缀授权，例如所有 orders- 开头的 Topic：

kafka-acls.sh --bootstrap-server broker1:9093 --command-config admin.conf \
  --add --allow-principal User:producer --operation Write --operation Read \
  --topic orders- --resource-pattern-type prefixed

此时 orders-us, orders-eu 等 Topic 都继承该权限。前缀匹配降低了动态创建 Topic 时的运维成本。

6.4 super.users 的作用

配置了 super.users 的 principal 将绕过所有 ACL 检查，可以执行任何操作。这对于集群管理和跨组件通信至关重要，但必须限制使用，避免权限过度膨胀。

flowchart TB
    A[Client Request] --> B{认证通过?}
    B -- No --> Z[拒绝连接]
    B -- Yes --> C{是 super.user?}
    C -- Yes --> Y[直接允许所有操作]
    C -- No --> D[Authorizer 查找匹配 ACL]
    D --> E{存在 Deny 规则?}
    E -- Yes --> X[拒绝]
    E -- No --> F{存在 Allow 规则?}
    F -- Yes --> Y
    F -- No --> X

图表主旨概括：ACL 权限检查流程从认证开始，先检查超级用户，再匹配 ACL 规则，遵循 Deny 优先原则。 逐层分解：请求携带 Principal，Authorizer 依次检查超级用户标志和 ACL 列表，若存在显式 Deny 规则则拒绝，否则寻找 Allow 规则。 设计原理映射：默认拒绝原则，未明确授权的操作一律禁止，超级用户作为运维逃生通道。 工程联系与关键结论：配置 ACL 时建议遵循最小权限原则，为每个用户仅授予必要的操作（如生产者只需 Write + Describe Topic，消费者需 Read + Describe ConsumerGroup），并利用前缀规则覆盖未来扩展，减少权限碎片化。

7. 故障模拟三：ACL 权限不足的排查

错误配置：为用户 producer 仅授予 Topic orders 的 Read 权限，未授予 Write。

kafka-acls.sh --bootstrap-server broker1:9093 --command-config admin.conf \
  --add --allow-principal User:producer --operation Read --topic orders

错误现象：使用该用户尝试生产消息时，kafka-console-producer.sh 抛出异常：

org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized to access topics: [orders]

同时 Broker 日志中出现 INFO: Principal = User:producer is Denied Operation = Write from host = 192.168.1.5 on resource = Topic:orders。

排查思路：

使用 kafka-acls.sh --list --topic orders 查看当前 ACL 规则，确认主体是否有 Write 权限。
检查客户端使用的 principal 是否正确（通过日志或回调获取）。
确认超级用户配置是否意外将当前用户排除，若有 Deny 规则覆盖。
验证资源名是否准确，包括大小写和前缀匹配。

修正方案：为用户添加 Write 权限：

kafka-acls.sh --bootstrap-server broker1:9093 --command-config admin.conf \
  --add --allow-principal User:producer --operation Write --topic orders

重新运行可正常生产消息。

8. Spring Kafka 安全配置实战

Spring Boot 2.7.x 通过 spring.kafka 命名空间下的属性，自动配置 KafkaAdmin、ProducerFactory、ConsumerFactory 和 KafkaStreams。安全配置使用 spring.kafka.properties.* 传递任意原生消费者/生产者配置。

8.1 基础 SSL 和 SASL 配置

application.yml 示例（SASL/SCRAM + SSL）：

spring:
  kafka:
    bootstrap-servers: broker1:9093,broker2:9093
    properties:
      security.protocol: SASL_SSL
      sasl.mechanism: SCRAM-SHA-256
      sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required username="producer" password="producer-secret";
      ssl.truststore.location: /etc/secrets/client.truststore.jks
      ssl.truststore.password: truststore-pass
    consumer:
      group-id: my-group
    producer:
      # Producer 会继承公共 properties
    admin:
      # AdminClient 同样继承

8.2 各组件独立安全配置

若 AdminClient 使用超级用户，而普通 Producer/Consumer 使用受限用户，可利用 Spring Kafka 的 KafkaAdmin、DefaultKafkaProducerFactory 的自定义 Map 配置覆盖。

@Configuration
public class KafkaConfig {
    @Bean
    public KafkaAdmin adminClient() {
        Map<String, Object> configs = new HashMap<>();
        configs.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "broker1:9093");
        configs.put(CommonClientConfigs.SECURITY_PROTOCOL_CONFIG, "SASL_SSL");
        configs.put(SaslConfigs.SASL_MECHANISM, "SCRAM-SHA-256");
        configs.put(SaslConfigs.SASL_JAAS_CONFIG,
            "org.apache.kafka.common.security.scram.ScramLoginModule required username=\"admin\" password=\"admin-secret\";");
        configs.put(SslConfigs.SSL_TRUSTSTORE_LOCATION_CONFIG, "/etc/secrets/client.truststore.jks");
        configs.put(SslConfigs.SSL_TRUSTSTORE_PASSWORD_CONFIG, "truststore-pass");
        return new KafkaAdmin(configs);
    }

    @Bean
    public ProducerFactory<String, String> producerFactory() {
        Map<String, Object> props = new HashMap<>();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "broker1:9093");
        // 使用不同用户 producer
        props.put(CommonClientConfigs.SECURITY_PROTOCOL_CONFIG, "SASL_SSL");
        props.put(SaslConfigs.SASL_MECHANISM, "SCRAM-SHA-256");
        props.put(SaslConfigs.SASL_JAAS_CONFIG,
            "org.apache.kafka.common.security.scram.ScramLoginModule required username=\"producer\" password=\"producer-secret\";");
        props.put(SslConfigs.SSL_TRUSTSTORE_LOCATION_CONFIG, "/etc/secrets/client.truststore.jks");
        props.put(SslConfigs.SSL_TRUSTSTORE_PASSWORD_CONFIG, "truststore-pass");
        return new DefaultKafkaProducerFactory<>(props);
    }
}

关键在于不同 Bean 使用不同的 Map，避免全局 spring.kafka.properties 覆盖。

8.3 Spring Boot 故障排查演示

错误场景：在 application.yml 中错误配置了 truststore 密码，导致 KafkaAdmin 无法连接。

spring:
  kafka:
    bootstrap-servers: broker1:9093
    properties:
      security.protocol: SASL_SSL
      ssl.truststore.password: wrongpass

应用启动时抛出：

Caused by: org.apache.kafka.common.KafkaException: Failed to construct kafka producer
Caused by: org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
...
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect

排查方法：

启用 --debug 日志，查找 KafkaAdmin 初始化异常。
检查 Spring Boot 自动配置报告，确认 KafkaAutoConfiguration 应用的条件。
校验 application.yml 中的密码与生成信任库时一致，使用 kafka-console-producer.sh 验证裸客户端能否连接，隔离问题。
修正密码后，KafkaAdmin 成功初始化，应用正常启动。

9. 安全方案组合决策框架

根据安全级别、运维复杂度和现有基础设施，推荐以下几种组合方案：

方案	认证	加密	授权	适用场景
SASL/PLAIN + SSL	用户名/密码	SSL	ACL	企业内部中等安全需求，运维简单
SASL/SCRAM + SSL	SCRAM 加盐	SSL	ACL	安全要求高，但不想引入 Kerberos
mTLS	客户端证书	SSL (mTLS)	基于证书 DN 的 ACL	零信任架构，金融级安全
SASL/GSSAPI + SSL	Kerberos	SSL	ACL	已有 AD/LDAP 的大型企业

flowchart TD
    Start[选择安全方案] --> Q1{是否有现有 Kerberos 基础设施?}
    Q1 -- 是 --> GSSAPI[选用 SASL/GSSAPI + SSL]
    Q1 -- 否 --> Q2{是否可接受证书管理复杂度?}
    Q2 -- 是且高安全 --> mTLS[选用 mTLS 双向认证]
    Q2 -- 否 --> Q3{是否要求密码不可明文存储?}
    Q3 -- 是 --> SCRAM[选用 SASL/SCRAM + SSL]
    Q3 -- 否 --> PLAIN[选用 SASL/PLAIN + SSL]

图表主旨概括：决策树帮助工程师根据组织现状和安全需求快速锁定合适的安全组合。 逐层分解：依次判断 Kerberos 是否存在、证书管理能力、密码安全等级要求，最终导向建议方案。 设计原理映射：每个决策点对应安全属性与运维成本的折衷，例如 Kerberos 提供统一身份认证但运维复杂，SCRAM 平衡了密码安全与实现难度。 工程联系与关键结论：大多数生产环境选择 SASL/SCRAM+SSL 或 SASL/PLAIN+SSL 并结合 ACL，原因是运维友好且满足合规要求。只有当基础设施已支持 Kerberos 或需要无密码 mTLS 时，才采用更复杂的方案。

10. 面试高频专题

Kafka 支持哪些安全机制？各自的作用是什么？
- 一句话回答：Kafka 提供认证（SASL）、加密（SSL/TLS）和授权（ACL）三大机制，分别用于验证身份、保护传输、控制资源访问。
- 详细解释：认证通过 SASL/PLAIN、SCRAM、GSSAPI 或 mTLS 客户端证书实现；加密利用 TLS 协议保证数据传输的机密性和完整性；授权通过 AclAuthorizer 结合 Resource-Operation-Principal 模型实现细粒度权限。三者需协同工作，常见协议组合为 SASL_SSL。
- 多角度追问：1) 如果只开启 SSL 加密但不认证，安全风险是什么？2) 如何评估开启安全机制后的性能损耗？3) Kafka 安全是否支持动态变更用户？
- 加分回答：社区从 0.9 版逐步引入安全特性，KIP-11、KIP-84 等推动了安全模型的进化；AclAuthorizer 的 ACL 存储在 ZooKeeper 的 /kafka-acl 路径下，可通过 ZkClient 直接读取。
SASL/PLAIN、SASL/SCRAM、SASL/GSSAPI 有什么区别？如何选择？
- 一句话回答：PLAIN 明文密码但最简单，SCRAM 加盐挑战响应更安全，GSSAPI 集成 Kerberos 适用于企业 SSO。
- 详细解释：PLAIN 密码存储在 JAAS 明文，必须配合 SSL；SCRAM 仅存储加盐哈希，支持动态添加用户；GSSAPI 依赖 KDC 票据，支持单点登录和多服务统一管理。选择时，无 Kerberos 基础设施且注重方便选 PLAIN+SSL，注重密码安全选 SCRAM，已有 AD 环境选 GSSAPI。
- 多角度追问：1) SCRAM 能否被重放攻击？2) PLAIN 模式下 JAAS 文件权限怎样设置？3) 如何在不停机条件下切换 SASL 机制？
- 加分回答：SCRAM 机制的迭代次数和盐值在 ZooKeeper 中存储，Kafka 通过 kafka-configs.sh 管理，利用 ZK 的版本保证一致性；Kafka 的 SaslServer 实现可同时注册多种机制，通过协商选择。
Kafka 的 SSL/TLS 单向认证和双向认证（mTLS）有什么区别？各自的适用场景？
- 一句话回答：单向认证仅客户端验证 Broker，双向认证双方互验证书，mTLS 可直接作为认证手段。
- 详细解释：单向认证配置简单，客户端需要信任库；双向认证 Broker 也需信任库并设置 ssl.client.auth=required，客户端额外提供密钥库。mTLS 可以省略 SASL，将证书 DN 作为 Principal 参与 ACL 授权，适用于零信任网络和微服务间认证。
- 多角度追问：1) 如何实现证书的自动滚动更新？2) mTLS 对性能影响是否比单向更大？3) 如何在 Docker 和 Kubernetes 中管理证书？
- 加分回答：Kafka 支持通过 ssl.principal.mapping.rules 将 X.509 DN 映射为短名；动态证书加载可通过 Java 自定义 SslEngineBuilder 实现，但原生 Kafka 需滚动重启。
如何通过 kafka-acls.sh 为某个用户授予对特定 Topic 的读写权限？
- 一句话回答：使用 --add --allow-principal User:<name> --operation Read --operation Write --topic <topic>。
- 详细解释：添加权限需指定主体、主机（默认 *）、操作和资源；可通过 --resource-pattern-type prefixed 批量授权。删除使用 --remove，查看使用 --list。注意必须配置 super.users 以防自己被锁。
- 多角度追问：1) 如果忘记 super.users 把自己锁了怎么办？2) ACL 如何与其他授权器（如 Apache Ranger）集成？3) 能否通过 API 动态修改 ACL？
- 加分回答：ACL 存储在 ZooKeeper 节点 /kafka-acl 中，可使用 AdminClient 的 createAcls/deleteAcls 方法编程管理，Spring Boot 可通过 AdminClient 自动在启动时注册 ACL。
Spring Boot 中如何配置 Kafka 的 SASL 和 SSL 安全连接？
- 一句话回答：通过 spring.kafka.properties.* 传递原生配置，如 security.protocol、sasl.jaas.config 和 ssl.truststore.location。
- 详细解释：Spring Kafka 自动配置会读取这些属性并应用到 ConsumerFactory 和 ProducerFactory。如果需要为不同组件使用不同凭证，可自定义 Map 配置 Bean，注意避免全局属性覆盖。排查时启用 debug 日志查看 KafkaAdmin 初始化。
- 多角度追问：1) 如何将 JAAS 凭证外部化而不写在 application.yml 中？2) 使用 Spring Cloud Stream 时安全配置如何继承？3) SSL 证书如何与 Spring Vault 集成动态获取？
- 加分回答：可以利用 Spring 的 EnvironmentPostProcessor 或外部配置中心（如 Spring Cloud Config）动态注入 JAAS 凭证；Spring Kafka 在 2.5 后支持 SslBundles 简化证书配置。
Kafka 的 super.users 是什么？有什么作用？
- 一句话回答：超级用户列表，配置的 Principals 可以绕过所有 ACL 检查，拥有全部权限。
- 详细解释：在 server.properties 中以分号分隔，例如 super.users=User:admin;User:kafka。超级用户常用于集群间通信、管理工具和紧急恢复。滥用会导致最小权限原则失效，应严格控制。
- 多角度追问：1) super.users 是否也受 SASL 认证约束？2) 如何审计 super.user 的操作？3) 是否可以为特定 Topic 设置 super.user 豁免？
- 加分回答：super.users 的实现原理在 AclAuthorizer 中，authorize() 方法首先检查 principal 是否在 super.users 集合中，是则直接返回 true，跳过 ACL 匹配。
SASL/PLAIN 认证在生产环境中有什么安全隐患？如何缓解？
- 一句话回答：主要风险是密码明文存储在 JAAS 文件，且传输依赖 SSL 加密，一旦 SSL 被击穿或配置为 SASL_PLAINTEXT 则密码泄露。
- 详细解释：缓解措施包括：强制使用 SASL_SSL；将 JAAS 文件权限设为 600，仅 kafka 用户可读；使用配置管理工具加密敏感字段；定期轮换密码。也可迁移到 SCRAM 彻底消除服务端明文存储。
- 多角度追问：1) JAAS 文件是否支持环境变量或外部密码？2) 如何监控 JAAS 文件被非法访问？3) Kafka 计划增强 PLAIN 安全性吗？
- 加分回答：Kafka 允许通过 sasl.jaas.config 属性直接在配置中传递 JAAS 内容，避免文件落地；Confluent 版 Kafka 支持通过安全插件与外部密钥管理集成。
如果在生产中发现某个消费者突然无法消费消息，可能是安全配置的什么问题？
- 一句话回答：常见原因是 ACL 权限变化、证书过期或 SSL 信任库更新导致消费者认证授权失败。
- 详细解释：消费者需要 Read Topic 和 Read ConsumerGroup 的权限，若 ACL 被误删或修改，消费会报 TopicAuthorizationException 或 GroupAuthorizationException。证书过期表现为 SSL 握手失败。也可能是认证服务（如 Kerberos）票据过期，需刷新。
- 多角度追问：1) 如何设计告警规则主动发现权限失效？2) 能否实现客户端自动重拉证书？3) Spring Kafka 消费者如何处理授权失败重试？
- 加分回答：Spring Kafka 的 CommonErrorHandler 可捕获 AuthorizationException 并暂停消费者，发送告警；Kafka 消费者内置指标 kafka.consumer:type=consumer-metrics 包含 authentication-failure-rate。
如何验证 Kafka 集群的 SSL 加密是否生效？
- 一句话回答：使用 openssl s_client 连接 Broker 端口，观察 TLS 握手和证书信息；或者抓包对比明文与密文。
- 详细解释：执行 openssl s_client -connect broker:9093 -debug 可查看完整握手过程，确认加密套件和服务器证书。也可使用 tcpdump 抓包，观察数据为乱码而非 Kafka 协议明文。通过 JMX 指标 kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec 无明文计数但能看到负载。
- 多角度追问：1) 如何检查双方是否用了正确的加密套件？2) SSL 的会话复用是否开启如何验证？3) 客户端如何输出使用的 TLS 版本？
- 加分回答：可以设置 javax.net.debug=ssl 环境变量，客户端将输出完整的 SSL 握手细节，包括使用的协议版本和密码套件。
Kafka 的安全机制对性能有什么影响？如何评估和优化？
- 一句话回答：主要影响在于 TLS 加密的 CPU 开销和握手延迟，SASL 提升轻微，ACL 为内存匹配几乎无影响。
- 详细解释：开启 SSL 后吞吐量可能下降 10-30%，每个连接的 TLS 握手消耗数毫秒。优化方法：使用椭圆曲线密码套件 (ECDHE) 降低 CPU 消耗；启用 ssl.keystore.type=PKCS12 加速密钥加载；启用会话缓存和会话票据减少重复握手；升级到 Kafka 3.x 使用更快的 SSL 引擎。
- 多角度追问：1) 如何利用 JMX 监控 SSL 性能开销？2) 零拷贝与 SSL 是否冲突？3) Kafka 的 SSL 加速是否支持硬件卸载？
- 加分回答：Kafka 的传输层使用 Java NIO，SSL 处理在 SslTransportLayer 中实现，可通过 Netty 结合 OpenSSL 实现更快的加密，但不是官方默认支持。
在 Docker 环境中部署 Kafka 时，SSL 证书应该如何处理？有哪些最佳实践？
- 一句话回答：使用 Docker Secrets 或 Kubernetes Secrets 挂载证书文件，避免将证书打入镜像，并设置合适的文件权限。
- 详细解释：在 docker-compose 中通过 secrets 或 volumes 将证书文件以只读方式挂载；在 Kubernetes 中使用 Secret 卷并 defaultMode: 0400。证书生成可在启动容器前的初始化脚本中完成，或使用 cert-manager 自动签发和轮换。
- 多角度追问：1) 如何在容器内部进行证书续期而不重启？2) 如何通过环境变量提供信任库密码？3) Kafka 容器化后 mTLS 挑战有哪些？
- 加分回答：Strimzi 等 Kafka Operator 大大简化了证书管理，支持集群内部 CA 自动签发和滚动更新，并可配置 spec.kafka.listeners.authentication 类型为 tls。
（故障排查题）一个生产环境中的 Spring Boot 应用连接到 Kafka 集群时报 AuthenticationFailedException，但同一个用户名密码在其他机器上可以正常连接。请给出完整的排查步骤和可能的原因分析。
- 一句话回答：可能原因包括客户端时钟偏差（Kerberos）、JAAS 配置文件未正确加载、SSL 信任库不匹配，或 Broker 对该客户端的 IP/主机有特殊限制。
- 详细解释：
  - 排查步骤：1) 检查客户端日志中认证失败的详细信息；2) 确认客户端的 security.protocol 和 sasl.mechanism 与 Broker 一致；3) 对于 SCRAM，验证 kafka-configs.sh --describe 凭据；4) 对比能连接的机器的 Java 版本和安全策略文件；5) 检查是否有代理或防火墙影响 SSL 握手；6) 使用 kafka-console-producer.sh 在该故障机器上测试相同配置，排除 Spring 因素；7) 抓包分析 TLS 握手。
  - 可能原因：Jaas 文件权限或路径问题导致未生效；Broker 的 ssl.principal.mapping.rules 映射导致证书 DN 被解析为不同用户；客户端时钟与 KDC 偏差（Kerberos）；SSL 主机名验证不过；ACL 限制特定 IP。
- 多角度追问：1) 如何在不重启应用的情况下重新加载 Kerberos ticket？2) 如何诊断 No valid credentials provided 错误？3) 能否使用 tcpdump 捕获 Kafka 认证包？
- 加分回答：Kafka 客户端的 AuthenticateCallbackHandler 可自定义认证逻辑，排查时可在 callback 中输出详细调试信息；Spring Boot 的 KafkaAutoConfiguration 会打印 bootstrap.servers，确认配置是否正确注入。

Kafka 安全配置参数速查表

参数	所属机制	作用	常见配置值	注意事项
`security.protocol`	全局	指定安全协议	`SASL_SSL`, `SSL`, `SASL_PLAINTEXT`	生产使用 `SASL_SSL`
`sasl.enabled.mechanisms`	SASL	Broker 支持的 SASL 机制	`PLAIN`, `SCRAM-SHA-256`, `GSSAPI`	可同时列出多个
`sasl.mechanism` (客户端)	SASL	客户端使用的 SASL 机制	与 Broker 匹配	必须在 JAAS 中提供对应 login module
`sasl.jaas.config`	SASL	客户端/SASL 认证的 JAAS 内容	PlainLoginModule, ScramLoginModule 等	避免明文写在代码中，使用外部化配置
`listener.name.{listener}.ssl.keystore.location`	SSL	Broker 密钥库路径	文件路径	必须存在且密码正确
`ssl.truststore.location`	SSL	信任库路径（客户端或 Broker mTLS）	文件路径	包含 CA 或对方证书
`ssl.client.auth`	SSL	mTLS 客户端证书要求	`required`, `requested`, `none`	`required` 强制客户端证书
`ssl.endpoint.identification.algorithm`	SSL	主机名验证	`HTTPS` 或空	启用可防 MITM
`ssl.cipher.suites`	SSL	限制加密套件	以逗号分隔的套件名	排除弱套件，提升安全性
`authorizer.class.name`	ACL	授权器实现类	`kafka.security.authorizer.AclAuthorizer`	必须配置才能启用 ACL
`super.users`	ACL	超级用户列表	`User:admin;User:kafka`	分号分隔，绕过所有 ACL
`kafka-acls.sh --add --allow-principal`	ACL	添加 ACL 规则	按需指定	支持 `--resource-pattern-type prefixed`

延伸阅读：

Kafka 官方文档 Security 章节 (kafka.apache.org/documentati…)
《Kafka: The Definitive Guide》Chapter 11
Confluent Security Guide (docs.confluent.io/platform/cu…)
KIP-11、KIP-84、KIP-554 等相关安全特性设计文档

本文通过“总览-认证-加密-授权-故障模拟-Spring整合-决策框架-面试题”的全链路，将 Kafka 安全体系的三大支柱完整呈现。结合详细的配置示例、命令行输出、故障排查场景和最佳实践，读者应能构建出满足生产要求的安全 Kafka 集群，并在 Spring Boot 应用中优雅地集成。后续章节将继续深入消息设计模式与工程实践。

Kafka 安全机制：SASL 认证、SSL 加密与 ACL 授权

概述

文章组织架构图

1. Kafka 安全体系全景：认证、加密、授权的三道防线

1.1 安全设计背景

1.2 三道防线的层次关系

1.3 安全协议的演变

2. SASL 认证机制深度解析：PLAIN、SCRAM、GSSAPI

2.1 SASL/PLAIN 认证

2.1.1 配置方式

2.1.2 客户端配置

2.2 SASL/SCRAM 认证

2.2.1 安全增强原理

2.2.2 配置 SCRAM 用户凭据

2.2.3 Broker 配置

2.3 SASL/GSSAPI (Kerberos)

2.4 三种 SASL 机制安全对比

3. SSL/TLS 加密传输：单向认证与 mTLS

3.1 SSL/TLS 单向认证

3.1.1 证书生成流程

3.1.2 Broker 配置

3.1.3 客户端配置

3.2 SSL/TLS 双向认证 (mTLS)

3.3 SSL 性能影响

4. 故障模拟一：SASL 认证失败的排查

5. 故障模拟二：SSL 握手失败的排查

6. ACL 授权机制：细粒度权限控制

6.1 SimpleAclAuthorizer 的 ACL 规则模型

6.2 kafka-acls.sh 的基本使用

6.3 基于前缀的 Topic 权限控制

6.4 super.users 的作用

7. 故障模拟三：ACL 权限不足的排查

8. Spring Kafka 安全配置实战

8.1 基础 SSL 和 SASL 配置

8.2 各组件独立安全配置

8.3 Spring Boot 故障排查演示

9. 安全方案组合决策框架

10. 面试高频专题

6.2 `kafka-acls.sh` 的基本使用