消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载TLS 证书认证是 Apache Pulsar 在 TLS 传输加密基础上构建的客户端身份认证机制不仅服务端持有证书供客户端验证客户端也持有一张由同一证书权威CA签发的证书其 Common NameCN即代表客户端的“角色令牌”role tokenBroker 以此完成身份识别。本文基于 Pulsar 2.3.0 版本文档 security-tls-authentication.md 展开完整覆盖客户端证书生成的 openssl 操作流程、Broker/Proxy 侧配置以及 CLI、Java、Python、C、Node.js、C# 六种客户端接入方式并结合当前仓库源码如 AuthenticationProviderTls、AuthenticationTls剖析“CN 如何变成角色名”的底层实现帮助你既能照做落地、又知其所以然。TLS 认证概述与 TLS 传输加密的关系TLS 认证TLS authentication是 TLS 传输加密TLS transport encryption的扩展。两者的关键区别在于证书校验的方向TLS 传输加密只有服务端持有密钥和证书客户端用 CA 证书验证服务端身份TLS 认证客户端同样持有密钥和证书服务端用 CA 证书验证客户端身份实现双向 TLSmTLS式的身份认证。前置条件很明确必须先完成集群的 TLS 传输加密配置本文假定你已按 TLS 传输加密文档 完成了 Broker 端 TLS 证书tlsCertificateFilePath、tlsKeyFilePath、tlsTrustCertsFilePath的准备。两个关键差异点值得注意客户端证书的 CN 就是角色令牌客户端证书与服务器证书都由同一个 CA 签发但客户端证书在生成 CSR 时Common Name 填写的不是主机名而是希望该客户端以其身份认证的角色名role token例如admin。Broker 必须开启客户端证书强制校验需要设置tlsRequireTrustedClientCertOnConnecttrue。从源码 ServiceConfiguration.java#L1347-L1351 可以看到该参数的定义与默认值FieldContext( category CATEGORY_TLS, doc Specify whether Client certificates are required for TLS Reject.\n the Connection if the Client Certificate is not trusted) private boolean tlsRequireTrustedClientCertOnConnect false;其语义是要求客户端必须携带受信任的证书建立 TLS 连接否则拒绝该连接——这正是 TLS 认证能“拒绝未认证客户端”的开关。另外Pulsar 的 TLS 相关密码套件和算法由Bouncy Castle Provider提供。如果你的环境要求 FIPS 合规版本可参考文档同目录下的 Bouncy Castle 相关章节security-bouncy-castle 一节的链接索引中提及该文档在当前版本目录中需以仓库实际存在的 security 系列文档为准。创建客户端证书openssl 完整流程客户端证书生成流程共四步生成私钥 → 转换为 PKCS 8 → 生成 CSR → 用 CA 签名。以下命令与原文档完全一致可直接照抄执行将/path/my-ca/替换为你的 CA 目录将admin替换为目标角色名。第一步生成 RSA 私钥$ openssl genrsa -out admin.key.pem 2048与 Broker 侧证书相同客户端同样期望私钥为 PKCS 8 格式因此需要转换$ openssl pkcs8 -topk8 -inform PEM -outform PEM \ -in admin.key.pem -out admin.key-pk8.pem -nocrypt注意后续配置中引用的私钥文件是转换后的admin.key-pk8.pem而不是原始的admin.key.pem。第二步生成证书签名请求CSR$ openssl req -config openssl.cnf \ -key admin.key.pem -new -sha256 -out admin.csr.pem执行时 openssl 会依次询问组织、城市、Common Name等信息。这里最关键的一步是Common Name 必须填写你希望该密钥对认证为哪个角色令牌例如admin因为这就是之后 Pulsar 中客户端的“身份名”。如果手头没有openssl.cnf请参照 TLS 传输加密文档中的“Certificate authority”一节 获取标准配置。第三步使用 CA 签名客户端证书$ openssl ca -config openssl.cnf -extensions usr_cert \ -days 1000 -notext -md sha256 \ -in admin.csr.pem -out admin.cert.pem注意-extensions usr_cert参数客户端证书使用usr_cert扩展对应 extendedKeyUsage 中的 clientAuth使该证书可被用于客户端认证场景——这是客户端证书与服务器证书在扩展用途上的核心区别。执行成功后得到两个产物证书admin.cert.pem密钥admin.key-pk8.pem客户端凭此证书 密钥 CA 证书ca.cert.pem即可向 Broker 和 Proxy 证明自己是角色admin。排错CA 私钥缺失如果签名步骤报unable to load CA private key且原因是No such file or directory: /etc/pki/CA/private/cakey.pem可执行以下命令生成cakey.pem$ cd /etc/pki/tls/misc/CA $ ./CA -newca源码深读Broker 如何把 CN 变成角色令牌配置项只是“外壳”真正执行认证逻辑的是 Broker 侧的认证 Provider。当前仓库中对应实现为 AuthenticationProviderTls.java其authenticate方法#L52-L105的核心逻辑与证书生成流程一一对应Certificate[] certs authData.getTlsCertificates(); if (null certs) { errorCode ErrorCode.INVALID_CERTS; throw new AuthenticationException(Failed to get TLS certificates from client); } String distinguishedName ((X509Certificate) certs[0]).getSubjectX500Principal().getName(); for (String keyValueStr : distinguishedName.split(,)) { String[] keyValue keyValueStr.split(, 2); if (keyValue.length 2 CN.equals(keyValue[0]) !keyValue[1].isEmpty()) { commonName keyValue[1]; break; } } // ... return commonName; // 返回的字符串即客户端的角色令牌要点解析Provider 从 TLS 层拿到的客户端证书链中取第一张证书certs[0]即客户端自证书解析其 X.500 主体名Distinguished NameRFC 2253 格式形如CNadmin,O...逐项split(,)后匹配CN前缀方法最终返回 CN 值作为角色名交由后续授权authorization流程判定该角色是否有权限。这也解释了为什么生成 CSR 时 CN 必须填角色令牌——Broker 端并不做任何“CN 到角色”的映射表CN 就是角色失败路径会区分INVALID_CERTS未拿到证书与INVALID_CN证书中无有效 CN两类错误码并计入AuthenticationMetrics指标便于通过监控排查认证失败原因。对应地客户端侧的认证插件实现为 AuthenticationTls.java#L40-L121。它接受tlsCertFile和tlsKeyFile两个参数见 #L118-L121private void setAuthParams(MapString, String authParams) { certFilePath authParams.get(tlsCertFile); keyFilePath authParams.get(tlsKeyFile); }其configure方法#L93-L105先尝试按 JSON 解析参数串失败则回退到k1:v1,k2:v2的旧式格式解析——这就是下文 broker.conf 中brokerClientAuthenticationParameters既能用 JSON 字符串、CLIclient.conf中又用逗号分隔格式的原因。在 Broker 上启用 TLS 认证在broker.conf中于既有 TLS 传输加密配置基础上追加以下参数完整参数说明见 TLS broker 配置# Configuration to enable authentication authenticationEnabledtrue authenticationProvidersorg.apache.pulsar.broker.authentication.AuthenticationProviderTls # operations and publish/consume from all topics superUserRolesadmin # Authentication settings of the broker itself. Used when the broker connects to other brokers, either in same or other clusters brokerClientTlsEnabledtrue brokerClientAuthenticationPluginorg.apache.pulsar.client.impl.auth.AuthenticationTls brokerClientAuthenticationParameters{tlsCertFile:/path/my-ca/admin.cert.pem,tlsKeyFile:/path/my-ca/admin.key-pk8.pem} brokerClientTrustCertsFilePath/path/my-ca/certs/ca.cert.pem逐项解读参数作用authenticationEnabledtrue开启认证总开关见 ServiceConfiguration.java#L1358authenticationProviders...AuthenticationProviderTls指定认证 Provider 为 TLS 证书 ProviderProvider 为类名列表superUserRolesadmin将角色admin设为超级用户可执行所有管理操作并在所有主题上发布/消费若不开启 authorization则至少需要一个 super user 才能管理集群brokerClientTlsEnabledtrueBroker 作为客户端连接其他 Broker同集群或跨集群时使用 TLSbrokerClientAuthenticationPluginBroker 间连接使用的客户端认证插件即AuthenticationTlsbrokerClientAuthenticationParametersBroker 身份所用的证书/密钥路径JSON 格式Broker 之间互连时其 CN 同样充当角色令牌brokerClientTrustCertsFilePathBroker 互连时信任的 CA 证书路径同时别忘了前文提到的前置开关# 要求客户端必须携带受信任证书否则拒绝 TLS 连接 tlsRequireTrustedClientCertOnConnecttrue # 以及 TLS 传输加密本身的三项tlsCertificateFilePath / tlsKeyFilePath / tlsTrustCertsFilePath这三项在仓库自带的 conf/broker.conf 中均以注释形式预置例如tlsTrustCertsFilePath附近的注释说明了“只有该文件中的证书才被允许连接服务端”。在 Proxy 上启用 TLS 认证Proxy 同时扮演两个角色面向客户端的服务端验证客户端证书、面向 Broker 的客户端出示自己的证书。因此 Proxy 的证书对需要在Broker 侧登记为proxyRoles。从 ServiceConfiguration.java#L1390-L1395 可以看到该参数的语义定义FieldContext( category CATEGORY_AUTHORIZATION, doc Role names that are treated as proxy roles. \n\nIf the broker sees a request with role as proxyRoles - it will demand to see the original client role or certificate.) private SetString proxyRoles new TreeSet();即当 Broker 看到来自proxyRoles中某角色的请求时会进一步要求出示原始客户端的角色或证书从而防止 Proxy 自身身份被冒充。授权细节见 授权文档。在proxy.conf中追加以下参数同样叠加在 TLS 传输加密的 proxy 配置之上# For clients connecting to the proxy authenticationEnabledtrue authenticationProvidersorg.apache.pulsar.broker.authentication.AuthenticationProviderTls # For the proxy to connect to brokers brokerClientAuthenticationPluginorg.apache.pulsar.client.impl.auth.AuthenticationTls brokerClientAuthenticationParameterstlsCertFile:/path/to/proxy.cert.pem,tlsKeyFile:/path/to/proxy.key-pk8.pem这里proxy.cert.pem的 CN 是 Proxy 自己的角色令牌如proxy该令牌必须出现在 Broker 的proxyRoles配置中。仓库自带的 conf/proxy.conf 同样预置了tlsTrustCertsFilePath等 TLS 相关参数可供参考。客户端配置启用 TLS 认证后客户端一律走 TLS 传输。URL 约定如下Web 服务 URLhttps://8443端口Broker 服务 URLpulsarssl://6651端口CLI 工具pulsar-admin / pulsar-perf / pulsar-clientpulsar-admin、pulsar-perf、pulsar-client等命令行工具读取 Pulsar 安装目录下的conf/client.conf配置文件。仓库自带的 conf/client.conf 中已预留了认证相关注释行如authPluginorg.apache.pulsar.client.impl.auth.AuthenticationTls、authParamstlsCertFile:/path/to/client-cert.pem,tlsKeyFile:/path/to/client-key.pem。在该文件中追加webServiceUrlhttps://broker.example.com:8443/ brokerServiceUrlpulsarssl://broker.example.com:6651/ useTlstrue tlsAllowInsecureConnectionfalse tlsTrustCertsFilePath/path/to/ca.cert.pem authPluginorg.apache.pulsar.client.impl.auth.AuthenticationTls authParamstlsCertFile:/path/to/my-role.cert.pem,tlsKeyFile:/path/to/my-role.key-pk8.pem其中tlsAllowInsecureConnectionfalse表示强制校验 Broker 证书生产环境不建议改为true。Java 客户端import org.apache.pulsar.client.api.PulsarClient; PulsarClient client PulsarClient.builder() .serviceUrl(pulsarssl://broker.example.com:6651/) .enableTls(true) .tlsTrustCertsFilePath(/path/to/ca.cert.pem) .authentication(org.apache.pulsar.client.impl.auth.AuthenticationTls, tlsCertFile:/path/to/my-role.cert.pem,tlsKeyFile:/path/to/my-role.key-pk8.pem) .build();这里authentication(插件类名, 参数串)最终会走到 AuthenticationTls#configure按k:v,k:v格式解析出tlsCertFile/tlsKeyFile。Python 客户端from pulsar import Client, AuthenticationTLS auth AuthenticationTLS(/path/to/my-role.cert.pem, /path/to/my-role.key-pk8.pem) client Client(pulsarssl://broker.example.com:6651/, tls_trust_certs_file_path/path/to/ca.cert.pem, tls_allow_insecure_connectionFalse, authenticationauth)C 客户端#include pulsar/Client.h pulsar::ClientConfiguration config; config.setUseTls(true); config.setTlsTrustCertsFilePath(/path/to/ca.cert.pem); config.setTlsAllowInsecureConnection(false); pulsar::AuthenticationPtr auth pulsar::AuthTls::create(/path/to/my-role.cert.pem, /path/to/my-role.key-pk8.pem); config.setAuth(auth); pulsar::Client client(pulsarssl://broker.example.com:6651/, config);C 客户端源码位于 pulsar-client-cpp 目录AuthenticationTls对应的插件实现可参考 pulsar-client-cpp/lib/auth 目录。Node.js 客户端const Pulsar require(pulsar-client); (async () { const auth new Pulsar.AuthenticationTls({ certificatePath: /path/to/my-role.cert.pem, privateKeyPath: /path/to/my-role.key-pk8.pem, }); const client new Pulsar.Client({ serviceUrl: pulsarssl://broker.example.com:6651/, authentication: auth, tlsTrustCertsFilePath: /path/to/ca.cert.pem, }); })();C# 客户端var clientCertificate new X509Certificate2(admin.pfx); var client PulsarClient.Builder() .AuthenticateUsingClientCertificate(clientCertificate) .Build();注意 C# 客户端使用 PFX 格式的证书文件admin.pfx而非 PEM 证书 PKCS8 密钥的组合。验证与测试参考仓库中的集成测试 ClientAuthenticationTlsTest.java 完整演练了上述配置它先为 Broker 设置tlsKeyFilePath/tlsCertificateFilePath/tlsTrustCertsFilePath再设置setBrokerClientAuthenticationPlugin(AuthenticationTls.class.getName())与setBrokerClientTrustCertsFilePath(...)#L58-L71然后验证带信任证书 TLS 认证构建的PulsarAdmin可正常执行管理操作testAdminWithFull只配了客户端证书密钥、缺少tlsTrustCertsFilePath时请求会因证书链校验失败抛出包含PKIX path的异常testAdminWithCertAndKey——这提醒我们客户端信任 Broker 的 CA 与 Broker 信任客户端的 CA 是两条独立的信任链缺一即失败完全不启用 TLS 的客户端访问 TLS 端点同样被拒绝testAdminWithoutTls。此外AdminApiTlsAuthTest.java、BrokerAdminClientTlsAuthTest.java 以及 Proxy 侧的 AuthedAdminProxyHandlerTest.java、ProxyAuthenticatedProducerConsumerTest.java 分别覆盖了管理 API 与 Proxy 链路的 TLS 认证场景可作为自测脚本的参照。小结TLS 认证链路的完整闭环是CA 签发 CN 为角色令牌的客户端证书usr_cert扩展→ Broker 开启tlsRequireTrustedClientCertOnConnectAuthenticationProviderTls→ Provider 从客户端证书中提取 CN 作为角色 → 授权流程按superUserRoles/proxyRoles判定权限。落地时常见的三个坑私钥忘记转 PKCS 8、CSR 的 CN 误填主机名、Proxy 角色未登记进 Broker 的proxyRoles。按本文的配置清单逐项核对即可在当前仓库版本上完整跑通 TLS 客户端认证。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐如何用 export_model.py 把 happy-llm 第五章训练出的模型 checkpoint 导出为 HuggingFace 格式如何用 export_model.py 把 happy llm 第五章训练出的模型 checkpoint 导出为 HuggingFace 格式 在 happy消息队列后端流处理Apache Pulsar 基于 TLS 的认证配置指南从客户端证书签发到多语言客户端接入Apache Pulsar 基于 TLS 的认证配置指南从客户端证书签发到多语言客户端接入 导读 TLS 认证TLS Authentication是 Ap消息队列后端流处理Apache Pulsar客户端连接验证TLS证书配置检查Apache Pulsar客户端连接验证TLS证书配置检查 你是否在使用Apache Pulsar时遇到过客户端连接失败的问题是否曾因为TLS传输层安全协消息队列后端上一篇OCRmyPDF让扫描PDF重获新生的开源工具下一篇zteOnu完全指南解决光猫管理难题的3个创新方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考