在 Rasa 开源仓库中搭建无 TLS 的 Kafka SASL SCRAM-SHA-256 认证测试环境【免费下载链接】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本文以 Rasa 仓库中 test_environments/message_and_event_brokers/kafka/sasl_scram/no_tls/scram_sha_256/README.md 为主体完整讲解如何用 Docker Compose 搭建一套启用 SASL SCRAM-SHA-256 认证、但不启用 TLS 加密的 Kafka 消息代理用于验证 Rasa 对话引擎在客户端必须认证、且走明文连接场景下的事件流输出。读完本文你将掌握 Kafka ZooKeeper 双容器的认证配置、JAAS 登录文件的编写、SCRAM 用户的创建命令以及 Rasa 端KafkaEventBroker对应的endpoints.yml连接参数与源码级实现原理。背景与适用场景Rasa 的核心对话引擎在运行时会持续产生 tracker 事件用户消息、意图预测、动作执行等。当需要把这些事件流交给下游系统消费时Rasa 通过EventBroker抽象层把事件发布到消息中间件而 Kafka 是其中最常用的实现之一见 rasa/core/brokers/kafka.py。在生产环境中Kafka 集群通常要求客户端携带凭证认证。为了在不依赖外部基础设施的前提下验证 Rasa 的认证接入能力仓库在 test_environments/message_and_event_brokers/kafka/ 下维护了一整套可一键拉起的 Kafka 测试环境按认证方式与加密方式两两组合无认证no_authenticationSASL_PLAIN分无 TLS 与带 TLSSASL_SCRAM分无 TLS 与带 TLS且 SCRAM 又细分为 SHA-256 与 SHA-512 两个算法版本本文聚焦的组合是SASL_SCRAM 认证 SHA-256 算法 无 TLS 明文传输。它模拟的是客户端必须通过 SCRAM 握手认证但信道本身不加密的中间态场景——这种配置常被用于先打通认证链路、再叠加 TLS 的分步改造路径。环境概览目录结构与端口规划先看该组合的完整文件清单test_environments/message_and_event_brokers/kafka/sasl_scram/no_tls/scram_sha_256/ ├── README.md # 启动说明 ├── docker-compose.yml # 容器编排 ├── broker_jaas.conf # Kafka Broker 的 JAAS 登录配置 ├── zookeeper_client_jaas.conf # 连接 ZooKeeper 时使用的 JAAS 客户端配置 └── zookeeper_server_jaas.conf # ZooKeeper 服务端的 JAAS 配置根据目录 README.md 与 docker-compose.yml端口规划遵循仓库的通用约定服务容器名监听端口说明ZooKeeperzookeeper-sasl-scram-sha-256-no-tls2186宿主机与容器内均为 2186提供分布式协调、leader 选举与集群元数据Kafka Brokerkafka-broker-sasl-scram-sha-256-no-tls9096客户端通过localhost:9096连接端口编号遵循仓库约定Kafka 监听909x、ZooKeeper 监听218x数字随认证配置不同而变化详见 kafka 目录总 README从而允许多套测试环境在同一台机器上并行运行而不冲突。深入 docker-compose.ymlZooKeeper 与 Broker 的认证配置ZooKeeper 服务ZooKeeper 服务段 使用confluentinc/cp-zookeeper:7.3.2镜像关键环境变量如下zookeeper: image: confluentinc/cp-zookeeper:7.3.2 container_name: zookeeper-sasl-scram-sha-256-no-tls ports: - 2186:2186 environment: ZOOKEEPER_SERVER_ID: 1 ZOOKEEPER_CLIENT_PORT: 2186 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 -Dquorum.cnxn.threads.size20 -Dzookeeper.authProvider.1org.apache.zookeeper.server.auth.SASLAuthenticationProvider -Dzookeeper.authProvider.2org.apache.zookeeper.server.auth.DigestAuthenticationProvider -DjaasLoginRenew3600000 -DrequireClientAuthSchemesasl -Dquorum.auth.learner.loginContextQuorumLearner -Dquorum.auth.server.loginContextQuorumServer volumes: - ./zookeeper_server_jaas.conf:/etc/kafka/secrets/zookeeper_server_jaas.conf - ./zookeeper_client_jaas.conf:/etc/kafka/client/zookeeper_client_jaas.conf要点解读-Djava.security.auth.login.config...指定 ZooKeeper 进程使用的 JAAS 文件即挂载进来的zookeeper_server_jaas.confquorum.auth.enableSasltrue以及 learner/server 两侧的RequireSasltrue开启 ZooKeeper 集群成员之间的 SASL 认证单节点模式下同样生效同时注册了SASLAuthenticationProvider与DigestAuthenticationProvider两个认证提供者其中 Digest 用于 admin 用户SASL 用于 quorum 内部与 Kafka broker 的连接zookeeper_client_jaas.conf被挂载到容器内/etc/kafka/client/目录供启动脚本进入容器创建 SCRAM 用户时使用。Kafka Broker 服务Broker 服务段 使用confluentinc/cp-kafka:7.3.2镜像kafka-broker: image: confluentinc/cp-kafka:7.3.2 container_name: kafka-broker-sasl-scram-sha-256-no-tls ports: - 9096:9096 depends_on: - zookeeper environment: KAFKA_BROKER_ID: 1 KAFKA_ZOOKEEPER_CONNECT: zookeeper:2186 KAFKA_ADVERTISED_LISTENERS: SASL_PLAINTEXT://localhost:9096 KAFKA_MIN_INSYNC_REPLICAS: 1 KAFKA_SASL_ENABLED_MECHANISMS: SCRAM-SHA-256 KAFKA_SECURITY_INTER_BROKER_PROTOCOL: SASL_PLAINTEXT KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: SCRAM-SHA-256 KAFKA_AUTO_CREATE_TOPICS_ENABLE: true KAFKA_OFFSETS_RETENTION_MINUTES: 172800 KAFKA_LOG4J_LOGGERS: kafka.authorizer.loggerDEBUG,kafka.controllerDEBUG KAFKA_LOG4J_ROOT_LOGLEVEL: DEBUG 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: - ./broker_jaas.conf:/etc/kafka/secrets/conf/kafka_server_jaas.conf要点解读KAFKA_ADVERTISED_LISTENERS: SASL_PLAINTEXT://localhost:9096表明监听器协议为SASL_PLAINTEXT即带 SASL 认证、但无 TLS 加密客户端必须携带凭证KAFKA_SASL_ENABLED_MECHANISMS: SCRAM-SHA-256与KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: SCRAM-SHA-256把服务端启用机制和 broker 间通信机制都固定为 SCRAM-SHA-256KAFKA_ZOOKEEPER_SASL_ENABLED: true表示 broker 连接 ZooKeeper 时也要走 SASL 认证配合KAFKA_OPTS中的-Dzookeeper.sasl.clienttrue与-Dzookeeper.sasl.clientconfigClient使用 JAAS 中名为Client的上下文Digest 登录完成对 ZooKeeper 的认证KAFKA_SUPER_USERS: User:kafkabroker;User:kafkaclient声明了两个超级用户KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND: false表示未找到 ACL 时不默认放行所有人注意本配置未显式设置 authorizer 类ACL 是否真正生效取决于 Kafka 版本与 authorizer 的启用情况这一点在排障时需要留意挂载的broker_jaas.conf被映射为kafka_server_jaas.conf通过KAFKA_OPTS的-Djava.security.auth.login.config交给 JVM 加载。JAAS 配置文件逐项解读SASL 认证的密钥全部集中在三个 JAAS 文件中它们是整套环境能否拉起的关键。zookeeper_server_jaas.confZooKeeper 服务端文件 zookeeper_server_jaas.confServer { 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; };Server上下文定义了 ZooKeeper 服务端可接受的客户端凭据用户admin、密码password这就是 broker 和运维脚本连接 ZooKeeper 时使用的账号QuorumServer/QuorumLearner两个上下文用于 ZooKeeper 集群成员之间的相互认证对应docker-compose.yml中-Dquorum.auth.server.loginContextQuorumServer与-Dquorum.auth.learner.loginContextQuorumLearner本测试环境为单节点但这些配置保证了集群模式下也能直接复用。zookeeper_client_jaas.confZooKeeper 客户端文件 zookeeper_client_jaas.confClient { org.apache.zookeeper.server.auth.DigestLoginModule required usernameadmin passwordpassword; };这个Client上下文被两处使用一是 Kafka broker 通过KAFKA_OPTS的-Dzookeeper.sasl.clientconfigClient引用它来连接 ZooKeeper二是下面启动流程中执行kafka-configs创建 SCRAM 用户时通过KAFKA_OPTS-Djava.security.auth.login.configzookeeper_client_jaas.conf指定它。两处都使用admin/password与服务端的Server上下文对应。broker_jaas.confKafka Broker 服务端与客户端文件 broker_jaas.confKafkaServer { 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; };KafkaServer上下文是 broker 自身向集群认证时使用的身份用户kafkabroker与 README 中创建的用户、KAFKA_SUPER_USERS中的声明保持一致登录模块为ScramLoginModuleClient上下文用PlainLoginModule提供admin/password对应连接 ZooKeeper 的 Digest 认证KafkaClient上下文定义了 broker 以客户端身份与其它 broker 通信inter-broker时的 SCRAM 凭据kafkaclient/password。一步步启动创建用户与启动 Broker原文档 README.md 给出了完整的启动流程分三步第一步启动 ZooKeeperdocker-compose up -d zookeeper第二步进入 ZooKeeper 容器创建 SCRAM 用户SCRAM 用户凭证存储在 ZooKeeper 中因此必须在 ZooKeeper 容器内执行kafka-configs命令docker exec -it zookeeper-sasl-scram-sha-256-no-tls bash cd /etc/kafka/client KAFKA_OPTS-Djava.security.auth.login.configzookeeper_client_jaas.conf kafka-configs --zookeeper localhost:2186 --alter --add-config SCRAM-SHA-256[iterations4096,passwordpassword] --entity-type users --entity-name kafkabroker KAFKA_OPTS-Djava.security.auth.login.configzookeeper_client_jaas.conf kafka-configs --zookeeper localhost:2186 --alter --add-config SCRAM-SHA-256[iterations4096,passwordpassword] --entity-type users --entity-name client参数说明参数含义--zookeeper localhost:2186指向容器内的 ZooKeeper 地址注意是 2186 而非默认 2181--alter --add-config SCRAM-SHA-256[iterations4096,passwordpassword]为该用户写入 SCRAM-SHA-256 凭证迭代次数 4096密码password--entity-type users --entity-name kafkabroker定义用户名第一个是 broker 自身身份kafkabroker--entity-type users --entity-name client定义第二个用户client供外部客户端认证使用KAFKA_OPTS...zookeeper_client_jaas.conf让kafka-configs工具用admin/password通过 SASL 连上受保护的 ZooKeeper第三步退出容器并启动 Kafka Brokerexit docker-compose up -d kafka-brokerdocker-compose.yml中kafka-broker通过depends_on: - zookeeper保证 ZooKeeper 先就绪。启动完成后Kafka 将在localhost:9096上提供带 SASL_SCRAM 认证的服务。仓库文件中的一处细节值得注意README 创建的第二个用户名为client而 broker_jaas.conf 的KafkaClient上下文与KAFKA_SUPER_USERS中使用的是kafkaclient。实际接入客户端时请以你自己的客户端配置为准确保ZooKeeper 中创建的用户名与客户端 SASL 用户名完全一致否则会认证失败。客户端侧让 Rasa 通过 SASL SCRAM 连接 Kafkaendpoints.yml 配置测试环境就绪后Rasa 通过endpoints.yml中的event_broker段接入 Kafka。仓库在 data/test_endpoints/event_brokers/ 提供了各种协议组合的示例其中kafka_sasl_plaintext_endpoint.yml展示了SASL_PLAINTEXT协议下的完整字段event_broker: type: kafka security_protocol: SASL_PLAINTEXT topic: topic url: localhost partition_by_sender: True sasl_username: username sasl_password: password sasl_mechanism: PLAIN对接本文的 SCRAM-SHA-256 环境只需把sasl_mechanism改为SCRAM-SHA-256、url指向localhost:9096、sasl_username/sasl_password填成在 ZooKeeper 中创建的用户例如client/passwordevent_broker: type: kafka url: localhost:9096 topic: rasa_core_events security_protocol: SASL_PLAINTEXT sasl_mechanism: SCRAM-SHA-256 sasl_username: client sasl_password: password partition_by_sender: trueKafkaEventBroker 源码解析rasa/core/brokers/kafka.py 中的KafkaEventBroker是这套配置的落地实现。其构造函数明确支持 SCRAM 系列机制见sasl_mechanism参数 docstringValid values are: PLAIN, GSSAPI, OAUTHBEARER, SCRAM-SHA-256, SCRAM-SHA-512. Default:PLAINsecurity_protocol的合法值为PLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL默认SASL_PLAINTEXT。当security_protocol SASL_PLAINTEXT时_get_kafka_config()会生成如下 confluent-kafka 生产者配置见 kafka.py 中_get_kafka_config方法authentication_params { sasl.username: self.sasl_username, sasl.password: self.sasl_password, sasl.mechanism: self.sasl_mechanism, security.protocol: self.security_protocol, }也就是说sasl_mechanism: SCRAM-SHA-256会被原样传递给 confluent-kafka 的sasl.mechanism与测试环境 Broker 端KAFKA_SASL_ENABLED_MECHANISMS: SCRAM-SHA-256一一对应。若传入非法机制或协议_get_kafka_config会抛出ValueError非法security_protocol或由_create_producer抛出KafkaProducerInitializationError仓库在 data/test_endpoints/event_brokers/ 也准备了kafka_invalid_sasl_mechanism.yml、kafka_invalid_security_protocol.yml等异常用例供测试参考。此外KafkaEventBroker的事件主题默认值为rasa_core_events构造函数topic: Text rasa_core_events可用topic字段覆盖partition_by_sender为true时会以sender_id作为消息分区键_publish方法中partition_key bytes(event.get(sender_id), ...)保证同一会话的事件按序进入同一分区。验证连接与常见故障排查启动完成后可用任意支持 SASL 的 Kafka 客户端验证连接。若使用 Rasa 运行对话可通过 event-brokers 文档 了解事件流的整体行为。排查认证类问题时可重点关注 kafka.py 中的kafka_error_callbackif ( err.code() KafkaError._ALL_BROKERS_DOWN or err.code() KafkaError._AUTHENTICATION or err.code() KafkaError._MAX_POLL_EXCEEDED ): raise KafkaException(err)即_AUTHENTICATION认证失败和_ALL_BROKERS_DOWNbroker 不可达会被直接视为异常抛出日志中通常会看到Failed to connect kafka.或Connection to kafka lost, reconnecting...publish方法内部会尝试重建 producer 并重连。常见原因与对策现象可能原因排查方向认证失败_AUTHENTICATIONsasl_username/sasl_password与 ZooKeeper 中创建的用户不一致重新执行kafka-configs创建同名同密码用户机制不匹配客户端sasl_mechanism与 Broker 端KAFKA_SASL_ENABLED_MECHANISMS不一致两端统一为SCRAM-SHA-256broker 不可达_ALL_BROKERS_DOWNurl端口写错或 Broker 未就绪确认localhost:9096可连通ZooKeeper 认证失败JAAS 文件中的admin密码与Server上下文不一致比对三个 JAAS 文件中的密码可复用的其他 Kafka 测试环境组合本文环境只是仓库提供的一种组合。若你的验证场景不同可直接切换到以下兄弟配置均位于 kafka 测试环境目录无认证的 Kafka适合先验证事件流链路本身SASL_PLAIN 无 TLS用户名密码式明文认证SASL_SCRAM 无 TLS SHA-512与本文结构完全相同仅算法换为更长的 SHA-512SASL_SCRAM 带 TLS SHA-256在本文基础上叠加 SSL 证书该目录附带ca-cert、server.keystore.jks等文件客户端需同时配置ssl_cafile等参数。各组合的端口、容器名、JAAS 文件与endpoints.yml配置遵循同一套模式掌握了本文的 SCRAM-SHA-256 无 TLS 方案后迁移到其他组合只需对照相应 README 调整机制名、端口与证书参数。注意事项与限制仅用于测试本环境关闭了 TLS所有凭据包括password均为明文可读的固定值只适合本地开发与 CI 验证不能直接用于生产明文传输风险SASL_PLAINTEXT只做认证、不加密数据若需保护数据在途安全请使用 带 TLS 的 SASL_SCRAM 组合用户名一致性创建用户、Broker JAAS、客户端配置三处的用户名/密码必须全局一致参考上文关于client与kafkaclient的提示镜像版本本套环境固定使用 Confluent 平台镜像7.3.2若更换镜像版本需自行核对 SASL/SCRAM 相关环境变量的兼容性仓库只读本文描述的启动与配置均为使用仓库既有文件的方式无需修改仓库内容即可复现整套环境。【免费下载链接】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），仅供参考