尧图网站建设 
Rasa 测试环境实战为 Kafka Broker 配置 TLS 加密与 SASL_PLAIN 认证证书绑定 0.0.0.0【免费下载链接】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_plain/with_tls/ssl_all_conections/目录完整讲解如何在 Docker 中搭建一套「TLS 加密 SASL_PLAIN 用户名密码认证」的 Kafka 测试环境包括目录文件职责、证书体系CA 与 keystore的生成原理、docker-compose.yml与 JAAS 配置的逐项解读以及如何让 Rasa 客户端通过SASL_SSL安全协议连接 broker。读完本文你将掌握证书绑定0.0.0.0的 TLS 测试环境从零搭建、证书到期再生成、以及 RasaKafkaEventBroker端到端对接验证的完整方案。1. 这套测试环境解决什么问题Rasa 的对话服务如 tracker store、event broker支持把对话事件投递到 Kafka。在真实生产环境中Kafka broker 往往要求客户端既完成身份认证、又通过 TLS 加密信道通信而 Rasa 仓库为此提供了一套完整的本地测试环境test_environments/message_and_event_brokers/kafka/下按「无认证 / SASL_PLAIN / SASL_SCRAM」与「无 TLS / 带 TLS」组合出多套可一键启动的 Docker 配置见 kafka 根 README。本文聚焦其中的sasl_plain/with_tls/ssl_all_conections/变体其核心特点有两个SASL_PLAIN 认证客户端必须携带用户名/密码admin/alice才能连接TLS 证书绑定0.0.0.0broker 出示的证书 SANSubject Alternative Name为0.0.0.0客户端无论用哪个 IP/主机名访问都能通过身份校验极大方便了本地与 CI 测试——但正如文档反复强调的切勿在生产环境使用。该目录中同时附带了已预生成且有效期一年的证书server.keystore.jks、ca-cert等开箱即用若证书过期README 也给出了完整的重新生成命令序列。2. 目录文件逐项说明文件作用docker-compose.ymlKafka 与 Zookeeper 容器的编排文件server.keystore.jksJava keystore存放服务器证书与 CA 证书含私钥ca-certCA证书颁发机构证书即 CA 的公钥用于签署服务器证书需导入 keystore 作为受信证书客户端也要导入它来验证 broker 身份ca-keyCA 私钥用于生成 CA 证书ca-cert必须妥善保护cert-requestbroker 的证书签名请求CSR必须由 CA 签名后才能使用signed-server-certCA 签名后的 broker 证书需导入 keystoressl_keystore_credentials存放 keystore 口令内容为123456ssl_key_credentials存放私钥口令内容为123456用于解锁 CA 证书对应密钥broker_jaas.confbroker 的 JAAS 配置文件定义客户端可用于认证的用户名/密码注本文目录中口令文件实际命名为ssl_keystore_credentials与ssl_key_credentials子目录ssl_localhost相同README 描述中的ssl_keystore_password/ssk_key_password为同名概念的早期叫法两者本质相同均在docker-compose.yml中通过KAFKA_SSL_KEYSTORE_CREDENTIALS/KAFKA_SSL_KEY_CREDENTIALS环境变量引用。3. TLS 证书体系原理为什么需要 CA、keystore 与 SAN要正确理解这套环境需要先厘清三层概念详见 with_tls 父目录 READMERSA 密钥对本环境使用 RSA 算法生成公私钥用于证书的签名/验签与数据加解密。CACertificate Authority可信的第三方签发机构。它生成一对密钥——私钥ca-key用来给其他实体的证书签名必须保密不外泄公钥即ca-cert对外共享客户端用它来验证收到的证书确实由该 CA 签发而非恶意实体伪造。SANSubject Alternative Name允许一张证书同时保护多个主机名或 IP。验证规则如下证书 SAN 为194.3.5.1则客户端只有在 broker IP 为194.3.5.1时才接受证书证书 SAN 为localhost则只有用localhost主机名连接时才接受证书 SAN 为rasa.com则只有用rasa.com连接时才接受证书 SAN 为0.0.0.0则客户端接受任意主机名或 IP下的证书——这正是本目录ssl_all_conections的取名由来也是它适用于测试场景的根本原因。⚠️ 文档明确警告DO NOT USE THIS IN PRODUCTION!!!TLS 握手流程客户端连接 broker 时broker 出示自己的签名证书客户端用 CA 证书公钥验证该证书签名有效后才建立可信连接。4. Docker Compose 配置逐行解读本文目录的docker-compose.yml定义了两个服务4.1 Zookeeper集群协调zookeeper: image: confluentinc/cp-zookeeper:7.3.2 container_name: zookeeper-sasl-plain-tls-all-connections environment: ZOO_MY_ID: 1 ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_TICK_TIME: 2000 ZOOKEEPER_SASL_ENABLED: false healthcheck: test: nc -z localhost 2181 || exit 1 interval: 10s retries: 10 start_period: 15sKafka 与 Zookeeper 协同构成完整集群Zookeeper 负责 broker 的领导者选举、服务发现、集群拓扑维护感知 broker 上下线、指定某个 topic/partition 的首选 leader、topic 创建删除的跟踪与列表维护整体提供集群的一致性视图。本环境关闭了 Zookeeper 的 SASLZOOKEEPER_SASL_ENABLED: false认证只发生在客户端与 Kafka broker 之间。4.2 Kafka BrokerTLS SASL_PLAINkafka-broker: image: confluentinc/cp-kafka:7.3.2 container_name: kafka-broker-sasl-plain-tls-all-connections ports: - 9094:9094 - 29094:29094 depends_on: zookeeper: condition: service_healthy environment: KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 KAFKA_LISTENERS: SASL_SSL://0.0.0.0:9094, PLAINTEXT://0.0.0.0:29094 KAFKA_ADVERTISED_LISTENERS: SASL_SSL://localhost:9094, PLAINTEXT://localhost:29094 KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT KAFKA_SASL_ENABLED_MECHANISMS: PLAIN KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: PLAIN KAFKA_OPTS: -Djava.security.auth.login.config/etc/kafka/broker_jaas.conf KAFKA_SSL_KEYSTORE_FILENAME: kafka.server.keystore.jks KAFKA_SSL_KEYSTORE_CREDENTIALS: ssl_keystore_credentials KAFKA_SSL_KEY_CREDENTIALS: ssl_key_credentials KAFKA_SSL_ENABLED_PROTOCOLS: TLSv1.2,TLSv1.1,TLSv1 KAFKA_LOG4J_ROOT_LOGLEVEL: DEBUG volumes: - ./broker_jaas.conf:/etc/kafka/broker_jaas.conf - ./server.keystore.jks:/etc/kafka/secrets/kafka.server.keystore.jks - ./ssl_key_credentials:/etc/kafka/secrets/ssl_key_credentials - ./ssl_keystore_credentials:/etc/kafka/secrets/ssl_keystore_credentials healthcheck: test: nc -z localhost 9094 || exit 1 interval: 30s retries: 10 start_period: 15s关键配置说明双监听器SASL_SSL://0.0.0.0:9094对外提供「TLS 加密 SASL 认证」的安全端口映射到宿主9094PLAINTEXT://0.0.0.0:29094是给容器间/调试用的明文端口映射到宿主29094。ADVERTISED_LISTENERS告知客户端以localhost:9094与localhost:29094寻址 broker。broker 间通信KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT与KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: PLAIN让 broker 之间走明文通道避免在测试环境内部重复做 TLS/SASL 握手。SSL 物料挂载通过 volume 把宿主目录中的server.keystore.jks、ssl_keystore_credentialskeystore 口令123456、ssl_key_credentials私钥口令123456挂载进容器并分别通过KAFKA_SSL_KEYSTORE_FILENAME、KAFKA_SSL_KEYSTORE_CREDENTIALS、KAFKA_SSL_KEY_CREDENTIALS引用。协议兼容KAFKA_SSL_ENABLED_PROTOCOLS: TLSv1.2,TLSv1.1,TLSv1同时启用了三个 TLS 版本便于旧客户端测试。4.3 JAAS 认证配置broker_jaas.conf定义了客户端可用的账号KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required usernameadmin passwordadmin-secret user_adminadmin-secret user_alicealice-secret; }; Client{};可登录的用户表为UserPasswordadminadmin-secretalicealice-secret客户端连接时选择任一账号即可通过 SASL_PLAIN 认证。5. 启动与连接5.1 启动 brokerdocker-compose up -d启动后Kafka 监听9094SASL_SSLZookeeper 监听2181。客户端连接地址为localhost:9094对应证书 SAN0.0.0.0任意主机名/IP 均可验证通过。5.2 客户端侧证书信任配置TLS 双向校验要求客户端信任 CA否则无法验证 broker 身份。文档给出两种方式加入操作系统证书池把ca-cert导入运行客户端的机器的系统证书库加入客户端进程内存证书池仅对客户端进程运行期间生效具体导入方式取决于所用 Kafka 客户端库的文档。若只想快速连通、不做身份强校验也可以指示客户端跳过证书验证——此时通信仍是 TLS 加密的只是不再验证 broker 身份。跳过验证与生产安全实践相悖仅建议在测试场景临时使用。6. 对接 RasaKafkaEventBroker的 SASL_SSL 配置Rasa 通过event_broker配置把对话事件投递到 Kafka。在仓库的rasa/core/brokers/kafka.py中KafkaProducer支持四种security_protocolPLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL并会在_create_ssl_context等方法中依据协议选择性地注入 SASL 与 SSL 参数传入的security_protocol会被.upper()归一化遇到非法值会抛出InvalidEventBrokerConfigurationError。与本套环境SASL_SSL 机制PLAIN对应的最小配置见仓库示例 kafka_sasl_ssl_endpoint.ymlevent_broker: type: kafka security_protocol: SASL_SSL topic: topic url: localhost sasl_username: username sasl_password: password sasl_mechanism: PLAIN ssl_cafile: CARoot.pem ssl_certfile: certificate.pem ssl_keyfile: key.pem ssl_check_hostname: True对照本测试环境字段取值建议为url: localhost、port: 9094默认 9092需按实际端口覆盖security_protocol: SASL_SSLsasl_mechanism: PLAINsasl_username: admin、sasl_password: admin-secret或alice/alice-secretssl_cafile指向本目录的ca-cert客户端据此验证 broker 身份ssl_check_hostname在本环境可设为False因为证书 SAN 是0.0.0.0主机名校验会与通配 IP 语义冲突。仓库还在 kafka_sasl_plaintext_endpoint.yml 中提供了SASL_PLAINTEXT有认证、无 TLS变体以及kafka_invalid_sasl_mechanism.yml/kafka_invalid_security_protocol.yml等用于验证非法参数校验逻辑的样例。7. 证书到期后的重新生成绑定 0.0.0.0 的完整命令预生成证书有效期一年。由于 macOS 对证书最大有效期限制为两年一年期是仓库采用的保守选择本文目录证书约在 2024 年 3 月 20 日左右到期。若已过期可在本目录内执行以下命令重新生成口令统一为123456# 1) 创建 CA私钥 ca-key 公钥 ca-cert有效期 365 天 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) 生成受 storepass/keypass 保护的服务器 keystoreSAN 绑定 IP 0.0.0.0 keytool -dname CNlocalhost,OUAtom,ORasa,LBerlin,SGermany,CGE -keystore server.keystore.jks -alias localhost -validity 365 -genkey -keyalg RSA -storetype pkcs12 -ext SANIP:0.0.0.0 -storepass 123456 -keypass 123456 # 3) 生成证书签名请求 keytool -keystore server.keystore.jks -alias localhost -certreq -file cert-request -storepass 123456 -keypass 123456 -ext SANIP:0.0.0.0 # 4) 用 CA 私钥签署请求产出 signed-server-cert openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-request -out signed-server-cert -days 365 -CAcreateserial -passin pass:123456 # 5) 将根证书导入 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 SANIP:0.0.0.0命令要点解读步骤 1 的-nodes表示 CA 私钥不加密便于本地测试-subj填写的 CN 为localhost与后续 keytool 的 dname 保持一致步骤 2、3、6 中的-ext SANIP:0.0.0.0是「任意地址可验证」这一行为的关键务必在三处保持一致步骤 5 导入CARoot后keystore 中同时存在 CA 与服务器两条证书链服务端握手时能完整出示。仓库还提供了 SAN 绑定localhostDNS 形式的姊妹变体命令仅差异在-ext SANDNS:localhost完整脚本见 ssl_localhost/README.md该变体对应端口9095客户端只接受运行在localhost上的 broker。8. 故障排查工具箱在 with_tls 父目录 README 的 Troubleshooting 部分提供了四组验证命令适用于本文目录# 1) 查看 keystore 内容含证书链、有效期、SAN 扩展 keytool -list -v -keystore server.keystore.jks -storepass 123456 -keypass 123456 # 2) 检查 CA 私钥是否受口令保护 openssl rsa -check -in ca-key -passin pass:123456 # 3) 验证 CA 证书能否解锁签名证书 openssl verify -CAfile ca-cert signed-server-cert # 4) 验证 TLS 连接是否可用按协议分别测试 openssl s_client -debug -connect localhost:29092 -tls1 # TLS 1.0 openssl s_client -debug -connect localhost:29092 -tls1_1 # TLS 1.1 openssl s_client -debug -connect localhost:29092 -tls1_2 # TLS 1.2这些命令可以帮助你快速定位「证书过期 / 私钥口令错误 / 证书链不完整 / 端口不通」四类常见问题例如步骤 3 失败说明签名链断裂需要重新执行第 7 节的完整生成流程步骤 4 失败则需检查容器端口映射与KAFKA_SSL_ENABLED_PROTOCOLS是否包含对应 TLS 版本。9. 生产环境使用须知安全边界这套环境是为测试而设计的文档与配置中有几处明确的安全边界证书 SAN 绑定0.0.0.0任意主机名/IP 均可通过身份校验仅用于测试生产必须替换为真实域名或固定 IP 的证书参考ssl_localhost变体或自行生成 SAN 为业务地址的证书弱口令keystore 口令、私钥口令均为123456账号密码为固定的admin-secret/alice-secret明文监听器PLAINTEXT://0.0.0.0:29094端口无认证无加密仅服务调试生产环境不应暴露此类监听器broker 间明文通信KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT意味着集群内部流量未加密多节点生产集群需重新设计。如需更多认证与加密组合仓库还提供了 SASL_SCRAM TLS、SASL_PLAIN 无 TLS、无认证 等变体可作为对照实验环境帮助理解不同安全等级下 RasaKafkaEventBroker的配置差异。总结ssl_all_conections目录提供了一套「开箱即用、证书一年一换」的 Kafka 安全测试环境TLS 保证传输加密SASL_PLAIN 保证身份认证SAN0.0.0.0 保证客户端可用任意地址连接。配合docker-compose up -d启动、按第 7 节命令续期证书、再按第 6 节配置 RasaKafkaEventBroker的SASL_SSL参数即可快速验证 Rasa 与安全 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rasa 测试环境实战：为 Kafka Broker 配置 TLS 加密与 SASL_PLAIN 认证（证书绑定 0.0.0.0）
Rasa 测试环境实战为 Kafka Broker 配置 TLS 加密与 SASL_PLAIN 认证证书绑定 0.0.0.0【免费下载链接】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_plain/with_tls/ssl_all_conections/目录完整讲解如何在 Docker 中搭建一套「TLS 加密 SASL_PLAIN 用户名密码认证」的 Kafka 测试环境包括目录文件职责、证书体系CA 与 keystore的生成原理、docker-compose.yml与 JAAS 配置的逐项解读以及如何让 Rasa 客户端通过SASL_SSL安全协议连接 broker。读完本文你将掌握证书绑定0.0.0.0的 TLS 测试环境从零搭建、证书到期再生成、以及 RasaKafkaEventBroker端到端对接验证的完整方案。1. 这套测试环境解决什么问题Rasa 的对话服务如 tracker store、event broker支持把对话事件投递到 Kafka。在真实生产环境中Kafka broker 往往要求客户端既完成身份认证、又通过 TLS 加密信道通信而 Rasa 仓库为此提供了一套完整的本地测试环境test_environments/message_and_event_brokers/kafka/下按「无认证 / SASL_PLAIN / SASL_SCRAM」与「无 TLS / 带 TLS」组合出多套可一键启动的 Docker 配置见 kafka 根 README。本文聚焦其中的sasl_plain/with_tls/ssl_all_conections/变体其核心特点有两个SASL_PLAIN 认证客户端必须携带用户名/密码admin/alice才能连接TLS 证书绑定0.0.0.0broker 出示的证书 SANSubject Alternative Name为0.0.0.0客户端无论用哪个 IP/主机名访问都能通过身份校验极大方便了本地与 CI 测试——但正如文档反复强调的切勿在生产环境使用。该目录中同时附带了已预生成且有效期一年的证书server.keystore.jks、ca-cert等开箱即用若证书过期README 也给出了完整的重新生成命令序列。2. 目录文件逐项说明文件作用docker-compose.ymlKafka 与 Zookeeper 容器的编排文件server.keystore.jksJava keystore存放服务器证书与 CA 证书含私钥ca-certCA证书颁发机构证书即 CA 的公钥用于签署服务器证书需导入 keystore 作为受信证书客户端也要导入它来验证 broker 身份ca-keyCA 私钥用于生成 CA 证书ca-cert必须妥善保护cert-requestbroker 的证书签名请求CSR必须由 CA 签名后才能使用signed-server-certCA 签名后的 broker 证书需导入 keystoressl_keystore_credentials存放 keystore 口令内容为123456ssl_key_credentials存放私钥口令内容为123456用于解锁 CA 证书对应密钥broker_jaas.confbroker 的 JAAS 配置文件定义客户端可用于认证的用户名/密码注本文目录中口令文件实际命名为ssl_keystore_credentials与ssl_key_credentials子目录ssl_localhost相同README 描述中的ssl_keystore_password/ssk_key_password为同名概念的早期叫法两者本质相同均在docker-compose.yml中通过KAFKA_SSL_KEYSTORE_CREDENTIALS/KAFKA_SSL_KEY_CREDENTIALS环境变量引用。3. TLS 证书体系原理为什么需要 CA、keystore 与 SAN要正确理解这套环境需要先厘清三层概念详见 with_tls 父目录 READMERSA 密钥对本环境使用 RSA 算法生成公私钥用于证书的签名/验签与数据加解密。CACertificate Authority可信的第三方签发机构。它生成一对密钥——私钥ca-key用来给其他实体的证书签名必须保密不外泄公钥即ca-cert对外共享客户端用它来验证收到的证书确实由该 CA 签发而非恶意实体伪造。SANSubject Alternative Name允许一张证书同时保护多个主机名或 IP。验证规则如下证书 SAN 为194.3.5.1则客户端只有在 broker IP 为194.3.5.1时才接受证书证书 SAN 为localhost则只有用localhost主机名连接时才接受证书 SAN 为rasa.com则只有用rasa.com连接时才接受证书 SAN 为0.0.0.0则客户端接受任意主机名或 IP下的证书——这正是本目录ssl_all_conections的取名由来也是它适用于测试场景的根本原因。⚠️ 文档明确警告DO NOT USE THIS IN PRODUCTION!!!TLS 握手流程客户端连接 broker 时broker 出示自己的签名证书客户端用 CA 证书公钥验证该证书签名有效后才建立可信连接。4. Docker Compose 配置逐行解读本文目录的docker-compose.yml定义了两个服务4.1 Zookeeper集群协调zookeeper: image: confluentinc/cp-zookeeper:7.3.2 container_name: zookeeper-sasl-plain-tls-all-connections environment: ZOO_MY_ID: 1 ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_TICK_TIME: 2000 ZOOKEEPER_SASL_ENABLED: false healthcheck: test: nc -z localhost 2181 || exit 1 interval: 10s retries: 10 start_period: 15sKafka 与 Zookeeper 协同构成完整集群Zookeeper 负责 broker 的领导者选举、服务发现、集群拓扑维护感知 broker 上下线、指定某个 topic/partition 的首选 leader、topic 创建删除的跟踪与列表维护整体提供集群的一致性视图。本环境关闭了 Zookeeper 的 SASLZOOKEEPER_SASL_ENABLED: false认证只发生在客户端与 Kafka broker 之间。4.2 Kafka BrokerTLS SASL_PLAINkafka-broker: image: confluentinc/cp-kafka:7.3.2 container_name: kafka-broker-sasl-plain-tls-all-connections ports: - 9094:9094 - 29094:29094 depends_on: zookeeper: condition: service_healthy environment: KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 KAFKA_LISTENERS: SASL_SSL://0.0.0.0:9094, PLAINTEXT://0.0.0.0:29094 KAFKA_ADVERTISED_LISTENERS: SASL_SSL://localhost:9094, PLAINTEXT://localhost:29094 KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT KAFKA_SASL_ENABLED_MECHANISMS: PLAIN KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: PLAIN KAFKA_OPTS: -Djava.security.auth.login.config/etc/kafka/broker_jaas.conf KAFKA_SSL_KEYSTORE_FILENAME: kafka.server.keystore.jks KAFKA_SSL_KEYSTORE_CREDENTIALS: ssl_keystore_credentials KAFKA_SSL_KEY_CREDENTIALS: ssl_key_credentials KAFKA_SSL_ENABLED_PROTOCOLS: TLSv1.2,TLSv1.1,TLSv1 KAFKA_LOG4J_ROOT_LOGLEVEL: DEBUG volumes: - ./broker_jaas.conf:/etc/kafka/broker_jaas.conf - ./server.keystore.jks:/etc/kafka/secrets/kafka.server.keystore.jks - ./ssl_key_credentials:/etc/kafka/secrets/ssl_key_credentials - ./ssl_keystore_credentials:/etc/kafka/secrets/ssl_keystore_credentials healthcheck: test: nc -z localhost 9094 || exit 1 interval: 30s retries: 10 start_period: 15s关键配置说明双监听器SASL_SSL://0.0.0.0:9094对外提供「TLS 加密 SASL 认证」的安全端口映射到宿主9094PLAINTEXT://0.0.0.0:29094是给容器间/调试用的明文端口映射到宿主29094。ADVERTISED_LISTENERS告知客户端以localhost:9094与localhost:29094寻址 broker。broker 间通信KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT与KAFKA_SASL_MECHANISM_INTER_BROKER_PROTOCOL: PLAIN让 broker 之间走明文通道避免在测试环境内部重复做 TLS/SASL 握手。SSL 物料挂载通过 volume 把宿主目录中的server.keystore.jks、ssl_keystore_credentialskeystore 口令123456、ssl_key_credentials私钥口令123456挂载进容器并分别通过KAFKA_SSL_KEYSTORE_FILENAME、KAFKA_SSL_KEYSTORE_CREDENTIALS、KAFKA_SSL_KEY_CREDENTIALS引用。协议兼容KAFKA_SSL_ENABLED_PROTOCOLS: TLSv1.2,TLSv1.1,TLSv1同时启用了三个 TLS 版本便于旧客户端测试。4.3 JAAS 认证配置broker_jaas.conf定义了客户端可用的账号KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required usernameadmin passwordadmin-secret user_adminadmin-secret user_alicealice-secret; }; Client{};可登录的用户表为UserPasswordadminadmin-secretalicealice-secret客户端连接时选择任一账号即可通过 SASL_PLAIN 认证。5. 启动与连接5.1 启动 brokerdocker-compose up -d启动后Kafka 监听9094SASL_SSLZookeeper 监听2181。客户端连接地址为localhost:9094对应证书 SAN0.0.0.0任意主机名/IP 均可验证通过。5.2 客户端侧证书信任配置TLS 双向校验要求客户端信任 CA否则无法验证 broker 身份。文档给出两种方式加入操作系统证书池把ca-cert导入运行客户端的机器的系统证书库加入客户端进程内存证书池仅对客户端进程运行期间生效具体导入方式取决于所用 Kafka 客户端库的文档。若只想快速连通、不做身份强校验也可以指示客户端跳过证书验证——此时通信仍是 TLS 加密的只是不再验证 broker 身份。跳过验证与生产安全实践相悖仅建议在测试场景临时使用。6. 对接 RasaKafkaEventBroker的 SASL_SSL 配置Rasa 通过event_broker配置把对话事件投递到 Kafka。在仓库的rasa/core/brokers/kafka.py中KafkaProducer支持四种security_protocolPLAINTEXT、SSL、SASL_PLAINTEXT、SASL_SSL并会在_create_ssl_context等方法中依据协议选择性地注入 SASL 与 SSL 参数传入的security_protocol会被.upper()归一化遇到非法值会抛出InvalidEventBrokerConfigurationError。与本套环境SASL_SSL 机制PLAIN对应的最小配置见仓库示例 kafka_sasl_ssl_endpoint.ymlevent_broker: type: kafka security_protocol: SASL_SSL topic: topic url: localhost sasl_username: username sasl_password: password sasl_mechanism: PLAIN ssl_cafile: CARoot.pem ssl_certfile: certificate.pem ssl_keyfile: key.pem ssl_check_hostname: True对照本测试环境字段取值建议为url: localhost、port: 9094默认 9092需按实际端口覆盖security_protocol: SASL_SSLsasl_mechanism: PLAINsasl_username: admin、sasl_password: admin-secret或alice/alice-secretssl_cafile指向本目录的ca-cert客户端据此验证 broker 身份ssl_check_hostname在本环境可设为False因为证书 SAN 是0.0.0.0主机名校验会与通配 IP 语义冲突。仓库还在 kafka_sasl_plaintext_endpoint.yml 中提供了SASL_PLAINTEXT有认证、无 TLS变体以及kafka_invalid_sasl_mechanism.yml/kafka_invalid_security_protocol.yml等用于验证非法参数校验逻辑的样例。7. 证书到期后的重新生成绑定 0.0.0.0 的完整命令预生成证书有效期一年。由于 macOS 对证书最大有效期限制为两年一年期是仓库采用的保守选择本文目录证书约在 2024 年 3 月 20 日左右到期。若已过期可在本目录内执行以下命令重新生成口令统一为123456# 1) 创建 CA私钥 ca-key 公钥 ca-cert有效期 365 天 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) 生成受 storepass/keypass 保护的服务器 keystoreSAN 绑定 IP 0.0.0.0 keytool -dname CNlocalhost,OUAtom,ORasa,LBerlin,SGermany,CGE -keystore server.keystore.jks -alias localhost -validity 365 -genkey -keyalg RSA -storetype pkcs12 -ext SANIP:0.0.0.0 -storepass 123456 -keypass 123456 # 3) 生成证书签名请求 keytool -keystore server.keystore.jks -alias localhost -certreq -file cert-request -storepass 123456 -keypass 123456 -ext SANIP:0.0.0.0 # 4) 用 CA 私钥签署请求产出 signed-server-cert openssl x509 -req -CA ca-cert -CAkey ca-key -in cert-request -out signed-server-cert -days 365 -CAcreateserial -passin pass:123456 # 5) 将根证书导入 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 SANIP:0.0.0.0命令要点解读步骤 1 的-nodes表示 CA 私钥不加密便于本地测试-subj填写的 CN 为localhost与后续 keytool 的 dname 保持一致步骤 2、3、6 中的-ext SANIP:0.0.0.0是「任意地址可验证」这一行为的关键务必在三处保持一致步骤 5 导入CARoot后keystore 中同时存在 CA 与服务器两条证书链服务端握手时能完整出示。仓库还提供了 SAN 绑定localhostDNS 形式的姊妹变体命令仅差异在-ext SANDNS:localhost完整脚本见 ssl_localhost/README.md该变体对应端口9095客户端只接受运行在localhost上的 broker。8. 故障排查工具箱在 with_tls 父目录 README 的 Troubleshooting 部分提供了四组验证命令适用于本文目录# 1) 查看 keystore 内容含证书链、有效期、SAN 扩展 keytool -list -v -keystore server.keystore.jks -storepass 123456 -keypass 123456 # 2) 检查 CA 私钥是否受口令保护 openssl rsa -check -in ca-key -passin pass:123456 # 3) 验证 CA 证书能否解锁签名证书 openssl verify -CAfile ca-cert signed-server-cert # 4) 验证 TLS 连接是否可用按协议分别测试 openssl s_client -debug -connect localhost:29092 -tls1 # TLS 1.0 openssl s_client -debug -connect localhost:29092 -tls1_1 # TLS 1.1 openssl s_client -debug -connect localhost:29092 -tls1_2 # TLS 1.2这些命令可以帮助你快速定位「证书过期 / 私钥口令错误 / 证书链不完整 / 端口不通」四类常见问题例如步骤 3 失败说明签名链断裂需要重新执行第 7 节的完整生成流程步骤 4 失败则需检查容器端口映射与KAFKA_SSL_ENABLED_PROTOCOLS是否包含对应 TLS 版本。9. 生产环境使用须知安全边界这套环境是为测试而设计的文档与配置中有几处明确的安全边界证书 SAN 绑定0.0.0.0任意主机名/IP 均可通过身份校验仅用于测试生产必须替换为真实域名或固定 IP 的证书参考ssl_localhost变体或自行生成 SAN 为业务地址的证书弱口令keystore 口令、私钥口令均为123456账号密码为固定的admin-secret/alice-secret明文监听器PLAINTEXT://0.0.0.0:29094端口无认证无加密仅服务调试生产环境不应暴露此类监听器broker 间明文通信KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT意味着集群内部流量未加密多节点生产集群需重新设计。如需更多认证与加密组合仓库还提供了 SASL_SCRAM TLS、SASL_PLAIN 无 TLS、无认证 等变体可作为对照实验环境帮助理解不同安全等级下 RasaKafkaEventBroker的配置差异。总结ssl_all_conections目录提供了一套「开箱即用、证书一年一换」的 Kafka 安全测试环境TLS 保证传输加密SASL_PLAIN 保证身份认证SAN0.0.0.0 保证客户端可用任意地址连接。配合docker-compose up -d启动、按第 7 节命令续期证书、再按第 6 节配置 RasaKafkaEventBroker的SASL_SSL参数即可快速验证 Rasa 与安全 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考