在 Rasa 项目中搭建支持 SASL SCRAM-SHA-256 认证与 TLS 加密的 Kafka 测试环境

在 Rasa 项目中搭建支持 SASL SCRAM-SHA-256 认证与 TLS 加密的 Kafka 测试环境【免费下载链接】rasa Open source machine learning framework to automate text- and voice-based conversations: NLU, dialogue management, connect to Slack, Facebook, and more - Create chatbots and voice assistants项目地址: https://gitcode.com/GitHub_Trending/ra/rasa本文基于当前仓库test_environments/message_and_event_brokers/kafka/sasl_scram/with_tls/scram_sha_256/目录下的完整配置讲解如何用 Docker Compose 一键拉起一个同时启用SASL SCRAM-SHA-256 身份认证与TLS 加密传输的 Kafka 消息代理测试环境并说明客户端尤其是 Rasa 的KafkaEventBroker如何安全地连接它。读完本文你将掌握JAAS 与 docker-compose 配置的每一处含义、从 Zookeeper 创建 SCRAM 用户的完整命令流程、客户端连接参数与证书信任链的配置方法以及验证 TLS 与排障的常用命令。一、这套测试环境解决了什么问题Rasa 助手Assistant在运行时会持续产生对话事件events。生产级部署中这些事件通常通过消息代理message broker异步发布供 tracker store 或外部消费者订阅。当 Kafka 被用作事件代理时出于安全要求broker 往往需要客户端先完成身份认证再通过加密通道通信。本目录提供的就是这样一个最小可复现的测试环境Kafka broker 要求客户端提供SCRAM-SHA-256凭据进行 SASL 认证同时所有客户端流量都经由TLS加密传输。仓库中 Kafka 测试环境总览 还提供了无认证、SASL_PLAIN、SCRAM 无 TLS 等其他组合本目录是其中安全级别最高的变体。整体架构由两个容器组成容器镜像暴露端口作用zookeeper-sasl-scram-sha-256-tlsconfluentinc/cp-zookeeper:7.3.22188提供集群协调服务并承载 SCRAM 用户的创建kafka-broker-sasl-scram-sha-256-tlsconfluentinc/cp-kafka:7.3.29098SASL_SSL、29098PLAINTEXT事件消息代理本体端口遵循仓库约定Kafka 监听909x、Zookeeper 监听218x见 kafka/README.mdx随认证组合不同而变化。本目录为 SCRAM-SHA-256 TLS 组合对应 9098/2188。二、核心配置逐项拆解2.1 docker-compose.yml两个服务的环境变量完整的编排文件位于 docker-compose.yml关键配置如下。Zookeeper 服务通过KAFKA_OPTS注入 JAAS 配置与 SASL 开关zookeeper: image: confluentinc/cp-zookeeper:7.3.2 container_name: zookeeper-sasl-scram-sha-256-tls ports: - 2188:2188 environment: ZOOKEEPER_SERVER_ID: 1 ZOOKEEPER_CLIENT_PORT: 2188 ZOOKEEPER_TICK_TIME: 2000 ZOOKEEPER_LOG4J_ROOT_LOGLEVEL: DEBUG KAFKA_OPTS: -Djava.security.auth.login.config/etc/kafka/secrets/zookeeper_server_jaas.conf -Dquorum.auth.enableSasltrue -Dquorum.auth.learnerRequireSasltrue -Dquorum.auth.serverRequireSasltrue -Dzookeeper.authProvider.1org.apache.zookeeper.server.auth.SASLAuthenticationProvider -Dzookeeper.authProvider.2org.apache.zookeeper.server.auth.DigestAuthenticationProvider -DrequireClientAuthSchemesasl volumes: - ./zookeeper_server_jaas.conf:/etc/kafka/secrets/zookeeper_server_jaas.conf - ./zookeeper_client_jaas.conf:/etc/kafka/secrets/zookeeper_client_jaas.conf要点quorum.auth.*三项启用 Zookeeper 集群节点间的 SASL 认证尽管本环境只有一个节点配置仍保持一致requireClientAuthSchemesasl要求客户端包括 Kafka broker使用 SASL 认证访问 Zookeeper两个 JAAS 文件通过 volume 挂载进容器。Kafka broker 服务同时启用 SCRAM-SHA-256 与 TLSkafka-broker: image: confluentinc/cp-kafka:7.3.2 container_name: kafka-broker-sasl-scram-sha-256-tls ports: - 9098:9098 - 29098:29098 depends_on: - zookeeper environment: KAFKA_BROKER_ID: 1 KAFKA_ZOOKEEPER_CONNECT: zookeeper:2188 KAFKA_LISTENERS: SASL_SSL://0.0.0.0:9098, PLAINTEXT://0.0.0.0:29098 KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT KAFKA_ADVERTISED_LISTENERS: SASL_SSL://localhost:9098, PLAINTEXT://localhost:29098 KAFKA_SSL_ENABLED_PROTOCOLS: TLSv1.2,TLSv1.1,TLSv1 KAFKA_SSL_KEYSTORE_FILENAME: server.keystore.jks KAFKA_SSL_KEYSTORE_CREDENTIALS: ssl_keystore_credentials KAFKA_SSL_KEY_CREDENTIALS: ssl_key_credentials KAFKA_SASL_ENABLED_MECHANISMS: SCRAM-SHA-256 KAFKA_SUPER_USERS: User:kafkabroker;User:kafkaclient KAFKA_ZOOKEEPER_SASL_ENABLED: true KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND: false KAFKA_OPTS: -Dzookeeper.sasl.clienttrue -Dzookeeper.sasl.clientconfigClient -Djava.security.auth.login.config/etc/kafka/secrets/conf/kafka_server_jaas.conf volumes: - ./ssl:/etc/kafka/secrets - ./broker_jaas.conf:/etc/kafka/secrets/conf/kafka_server_jaas.conf要点双监听器设计SASL_SSL://0.0.0.0:9098面向认证加密的外部客户端PLAINTEXT://0.0.0.0:29098仅用于 broker 间通信KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT。对外暴露localhost:9098供客户端使用KAFKA_SASL_ENABLED_MECHANISMS: SCRAM-SHA-256指定 SASL 机制为 SCRAM-SHA-256KAFKA_SUPER_USERS将kafkabroker、kafkaclient两个用户列为超级用户绕过 ACL 限制且KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND: false表明未配置 ACL 时拒绝所有访问TLS 证书材料来自./ssl目录其中 server.keystore.jks 存放 broker 的私钥与签名证书keystore 口令ssl_keystore_credentials与私钥口令ssl_key_credentials均为123456broker 通过KAFKA_OPTS携带zookeeper.sasl.clienttrue与ClientJAAS 上下文向 Zookeeper 完成 SASL 认证。2.2 JAAS 文件三个上下文各司其职broker 端 broker_jaas.conf包含三个上下文KafkaServer { org.apache.kafka.common.security.scram.ScramLoginModule required usernamekafkabroker passwordpassword; }; Client { org.apache.kafka.common.security.plain.PlainLoginModule required usernameadmin passwordpassword; }; KafkaClient { org.apache.kafka.common.security.scram.ScramLoginModule required usernamekafkaclient passwordpassword; };KafkaServerbroker 作为服务端启动时的 SCRAM 登录模块用于与 Zookeeper 间的认证交互Clientbroker 以客户端身份连接 Zookeeper 时使用对应 docker-compose 中-Dzookeeper.sasl.clientconfigClient这里用 PLAIN 机制提供admin/password凭据KafkaClientbroker 以 Kafka 客户端身份连接其他 broker如 SCRAM 机制下的元数据交互时使用。Zookeeper 端由两个文件组成zookeeper_server_jaas.conf 定义服务端用户与仲裁quorum用户Server { org.apache.zookeeper.server.auth.DigestLoginModule required user_adminpassword; }; QuorumServer { org.apache.zookeeper.server.auth.DigestLoginModule required user_zookeeperpassword; }; QuorumLearner { org.apache.zookeeper.server.auth.DigestLoginModule required usernamezookeeper passwordpassword; };zookeeper_client_jaas.conf 定义管理员客户端凭据Client { org.apache.zookeeper.server.auth.DigestLoginModule required usernameadmin passwordpassword; };注意本环境的 Zookeeper 认证是Digestdigest 认证而SCRAM-SHA-256 用户并不存在于 JAAS 文件中而是通过kafka-configs命令写入 Zookeeper见下一节这是 SCRAM 机制“动态创建用户”的设计特点。三、启动步骤与 SCRAM 用户创建关联文档给出了完整可复现的启动流程。逐步说明如下# 1. 启动 Zookeeper docker-compose up -d zookeeper # 2. 进入 Zookeeper 容器进入 kafka-configs 所在目录 docker exec -it zookeeper-scram-sha-256-tls bash cd /etc/kafka/client # 3. 创建 kafkabroker 用户broker 间/服务端认证用 KAFKA_OPTS-Djava.security.auth.login.configzookeeper_client_jaas.conf kafka-configs --zookeeper localhost:2188 --alter --add-config SCRAM-SHA-256[iterations4096,passwordpassword] --entity-type users --entity-name kafkabroker # 4. 创建 kafkaclient 用户客户端认证用 KAFKA_OPTS-Djava.security.auth.login.configzookeeper_client_jaas.conf kafka-configs --zookeeper localhost:2188 --alter --add-config SCRAM-SHA-256[iterations4096,passwordpassword] --entity-type users --entity-name client # 5. 退出容器 exit # 6. 启动 Kafka broker docker-compose up -d kafka-broker三个细节需要特别说明先起 Zookeeper再创建用户最后起 brokerSCRAM 用户必须先写入 Zookeeperbroker 启动时才能完成 SCRAM 握手因此顺序不可颠倒--entity-name的坑文档中创建的实体名是kafkabroker和client而 JAAS 文件中对应的用户名是kafkabroker与kafkaclient。连接客户端时实际使用的用户名是kafkaclient见父目录文档 with_tls/README.md 中的用户表。若按字面创建client后连接报认证失败应使用--entity-name kafkaclient创建或补齐对应 SCRAM 凭据iterations4096SCRAM-SHA-256 的哈希迭代次数属于可配置参数值越大暴力破解成本越高但认证计算开销也越大。启动完成后broker 对外地址为localhost:9098。四、客户端连接认证与 TLS 参数关联文档给出客户端连接需要设置的属性用户名与密码kafkaclient/passwordSASL 机制SCRAM-SHA-256开启 TLS不同客户端实现方式不同也可以跳过证书校验仍走 TLS 加密但不再验证 broker 身份将ssl目录下的ca-certca-cert导入客户端证书信任池。4.1 在 Rasa 中集成KafkaEventBrokerRasa 对 Kafka 的支持实现在 rasa/core/brokers/kafka.py 的KafkaEventBroker类中。其构造函数参数与上文“客户端需要设置的属性”一一对应其中与 SASL/TLS 直接相关的有参数默认值说明sasl_usernameNoneSASL 用户名对应本环境的kafkaclientsasl_passwordNoneSASL 密码对应本环境的passwordsasl_mechanismPLAIN认证机制合法值含PLAIN、GSSAPI、OAUTHBEARER、SCRAM-SHA-256、SCRAM-SHA-512本环境须设为SCRAM-SHA-256security_protocolSASL_PLAINTEXT通信协议合法值为PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL本环境须设为SASL_SSLssl_cafileNoneCA 证书文件路径用于校验 broker 证书对应导入的ca-certssl_certfileNone客户端证书PEM双向 TLS 时才需要ssl_keyfileNone客户端私钥ssl_check_hostnameFalse是否校验证书与 broker 主机名匹配从源码_get_kafka_config()kafka.py可以看到当security_protocol SASL_SSL时底层 confluent-kafka 生产者会收到sasl.username、sasl.password、sasl.mechanism、ssl.ca.location、ssl.certificate.location、ssl.key.location、ssl.endpoint.identification.algorithm以及security.protocol等完整参数。其中ssl.endpoint.identification.algorithm由ssl_check_hostname控制为True时映射为https强制主机名校验为False时映射为None跳过校验对应文档中“skip verification of the certificate”的选项。以endpoints.yml配置为例接入本测试环境大致如下event_broker: type: kafka url: localhost:9098 topic: rasa_core_events sasl_username: kafkaclient sasl_password: password sasl_mechanism: SCRAM-SHA-256 security_protocol: SASL_SSL ssl_cafile: /path/to/ca-cert若本地仅用于联调、不校验 broker 身份可将ssl_cafile置空并把ssl_check_hostname设为false——通信仍会加密但无法抵御中间人冒充 broker。五、证书机制与 SAN 说明TLS 部分依赖仓库 with_tls/README.md 中描述的证书机制仓库用RSA 算法生成公私钥对CA证书颁发机构持有私钥仅用于签发证书、绝不外泄与公钥即ca-cert分发给客户端TLS 握手时broker 将自己的由 CA 私钥签名的证书发送给客户端客户端用ca-cert中的公钥验证该证书确由该 CA 签发验证通过后才建立连接本环境证书的SANSubject Alternative Name设为localhost因此客户端只有在连接主机名为localhost的 broker 时才接受其证书。若证书 SAN 为194.3.5.1则客户端访问该 IP 时证书才有效SAN 设为0.0.0.0时任意主机名/IP 均被接受但父目录文档明确警告生产环境禁用目录内预生成的证书有效期至2024-03-30且文档明确说明仅用于测试不可用于生产过期后需按第五节流程重新生成。六、为 TLS 重新生成绑定 localhost 的证书若预置证书过期或需要新证书可按 with_tls/README.md 的流程重新生成并将产物放回ssl目录# 1. 生成 CA 私钥与 CA 证书公钥 openssl req -x509 -newkey rsa:4096 -keyout ca-key -out ca-cert -days 365 -nodes -subj /CNlocalhost/OUAtom/ORasa/LBerlin/STGermany/CGE -passin pass:123456 -passout pass:123456 # 2. 生成 server keystorestorepass 与 keypass 均为 123456SAN 绑定 localhost keytool -dname CNlocalhost,OUAtom,ORasa,LBerlin,SGermany,CGE -keystore server.keystore.jks -alias localhost -validity 365 -genkey -keyalg RSA -storetype pkcs12 -ext SANIP:localhost -storepass 123456 -keypass 123456 # 3. 生成证书签名请求 keytool -keystore server.keystore.jks -alias localhost -certreq -file cert-request -storepass 123456 -keypass 123456 -ext SANIP:localhost # 4. 用 CA 私钥签发证书 openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-request -out signed-server-cert -days 365 -CAcreateserial -passin pass:123456 # 5. 将 CA 根证书导入 keystore keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert -storepass 123456 -keypass 123456 # 6. 将签名后的证书导入 keystore keytool -noprompt -keystore server.keystore.jks -alias localhost -import -file signed-server-cert -storepass 123456 -keypass 123456 -ext SANDNS:localhost替换后将新生成的ca-cert、server.keystore.jks放回 ssl 目录口令文件保持不变再重启容器即可。七、连接排障与验证命令父目录文档提供了一组实用的验证与排障命令# 查看 keystore 内容确认别名、证书链、有效期 keytool -list -v -keystore server.keystore.jks -storepass 123456 -keypass 123456 # 检查 CA 私钥口令是否受保护 openssl rsa -check -in ca-key -passin pass:123456 # 验证 CA 证书能否解开 broker 的签名证书 openssl verify -CAfile ca-cert signed-server-cert # 验证 TLS 握手是否正常按协议版本分别测试 openssl s_client -debug -connect localhost:29092 -tls1 openssl s_client -debug -connect localhost:29092 -tls1_1 openssl s_client -debug -connect localhost:29092 -tls1_2此外结合 Rasa 侧行为KafkaEventBroker在初始化时会调用producer.list_topics(timeout5)探测连通性kafka.py认证失败、TLS 校验失败或全部 broker 不可达都会触发kafka_error_callback抛出KafkaExceptionkafka.py最终表现为KafkaProducerInitializationError此时应优先检查sasl_mechanism是否为SCRAM-SHA-256、security_protocol是否为SASL_SSL、用户名密码是否正确、ca-cert是否已导入信任池且证书 SAN 与连接主机名localhost匹配。八、安全注意事项小结仅限测试预置证书与固定口令password/123456都是测试性质生产环境必须更换证书过期有效期至 2024-03-30使用前先keytool -list -v核对SAN 边界生产证书的 SAN 应精确绑定真实主机名或 IP切勿使用0.0.0.0跳过校验的代价跳过证书校验只放弃“身份验证”不放弃“加密”适用于本地联调但不适用于生产ACL 策略KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND: false下未授权用户会被拒绝生产部署应在此基础上配置细粒度 ACL而不是依赖KAFKA_SUPER_USERS的白名单式放行。如需对比其他认证组合无认证、SASL_PLAIN、SCRAM-SHA-512、无 TLS 变体可查阅 Kafka 测试环境目录 下各子目录的 README 与 docker-compose 配置。【免费下载链接】rasa Open source machine learning framework to automate text- and voice-based conversations: NLU, dialogue management, connect to Slack, Facebook, and more - Create chatbots and voice assistants项目地址: https://gitcode.com/GitHub_Trending/ra/rasa创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考