消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载作为企业级分布式消息中间件Apache Pulsar 经常承担业务关键数据的存储与流转职责其安全体系的完备程度直接决定了整个消息系统的可信边界。本文以 Pulsar 2.2.0 的安全概览文档security-overview.md为骨架系统讲解 Pulsar 的安全默认状态、可插拔认证机制、认证凭证的过期与刷新原理、Role Tokens 的授权模型以及当前支持的四类认证提供方并结合仓库源码pulsar-broker-common、pulsar-broker模块与 conf/broker.conf 配置项逐一佐证。读完本文你将掌握 Pulsar 安全体系的最小可用配置方法、理解 broker 侧认证生命周期管理的底层实现并能依据实际业务场景在 TLS、Athenz、Kerberos、JWT 等认证方案中做出正确选型。Pulsar 的安全默认状态为什么要主动加固Pulsar 的默认安装不启用任何加密、认证与授权任何客户端都可以通过明文的服务 URLplain text service URLs直接与 Pulsar 通信。从 conf/broker.conf 的默认值可以清楚地看到这一点# Enable authentication authenticationEnabledfalse # Authentication provider name list, which is comma separated list of class names authenticationProviders # Enforce authorization authorizationEnabledfalse # Role names that are treated as super-user, meaning they will be able to do all admin # operations and publish/consume from all topics superUserRoles也就是说如果直接把集群暴露给不可信网络任何人均可访问集群中的全部资源。官方文档给出的加固思路是必须确保通过明文服务 URL 访问 Pulsar 的客户端仅限于可信客户端具体手段包括网络分段Network segmentation通过防火墙、VPC、安全组等手段将 broker、proxy 的明文服务端口限制在可信网段内授权 ACL借助授权机制仅允许受信任的 IP / 角色访问。如果两者都不采用集群就处于全开放状态任何人可以读写任意 topic、执行管理操作——这是 Pulsar 部署中最常见的风险来源。可插拔认证机制从单提供方到多提供方Pulsar 支持可插拔pluggable的认证机制客户端使用该机制与 broker、proxy 完成身份验证。更关键的是Pulsar 还允许同时配置多个认证来源让不同的客户端使用不同的认证方式连接同一集群。这一能力的源码基础是pulsar-broker-common模块中的认证抽象层AuthenticationProvider.java认证提供方的顶层接口定义了initialize(ServiceConfiguration config)初始化、getAuthMethodName()返回该提供方支持的认证方法名、authenticate(AuthenticationDataSource authData)校验凭证并返回角色字符串、newAuthState(...)创建认证状态等核心方法AuthenticationProviderList.java一个包装了多个认证提供方的组合实现它会按顺序逐个尝试各个 provider只要其中一个校验通过即返回成功全部失败时才抛出最后的认证异常。这正是一个 broker 同时支持多种认证来源的实现机制AuthenticationService.javabroker 启动时根据配置中的authenticationProviders列表通过反射实例化各个 provider并以getAuthMethodName()作为 key 进行组织管理。对应的配置项是 broker 配置中的authenticationProviders见 conf/broker.conf它是一个以逗号分隔的类名列表。例如同时启用 TLS 与 JWT 认证authenticationEnabledtrue authenticationProvidersorg.apache.pulsar.broker.authentication.AuthenticationProviderTls,org.apache.pulsar.broker.authentication.AuthenticationProviderToken从pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authentication/目录可以看到仓库中已内置的提供方实现包括AuthenticationProviderTlsTLS 客户端证书认证、AuthenticationProviderTokenJWT Token 认证、AuthenticationProviderBasicHTTP Basic 认证等它们与文档列出的四类认证方案一一对应详见下文。认证生命周期连接建立、Principal 存储与凭证刷新连接建立时的凭证校验当客户端与 broker 建立连接时broker 会立即校验认证凭证。校验逻辑位于 ServerCnx.java 的handleConnect流程中如果service.isAuthenticationEnabled()为真则读取CommandConnect携带的认证数据调用认证服务完成身份确认并生成对应的AuthenticationState状态对象。一次性认证与 Principal 存储值得特别注意的是连接完成初始认证后broker 并不会在后续通信中反复重新认证。认证得到的principal token即角色令牌会被持久存储在连接上用于后续的授权判断。也就是说认证只发生一次连接建立时授权则贯穿连接的整个生命周期——每一次对 topic、namespace 的操作都基于该连接上已存储的 principal 进行 ACL 判定。凭证过期的定期检查与强制重新认证虽然连接不会主动重新认证但凭证本身可能过期。为此broker 会周期性检查每一个ServerCnx对象的过期状态。检查频率由 broker 配置authenticationRefreshCheckSeconds控制默认值为60 秒见 conf/broker.conf 与 ServiceConfiguration.java# Interval of time for checking for expired authentication credentials authenticationRefreshCheckSeconds60一旦检测到凭证过期broker 会强制对连接重新认证若重新认证失败broker 将直接断开该客户端连接。这一机制的实现位于 ServerCnx.javamaybeScheduleAuthenticationCredentialsRefresh()使用 Netty event loop 的scheduleAtFixedRate以authenticationRefreshCheckSeconds为周期启动定时任务refreshAuthenticationCredentials()首先通过authState.isExpired()判断凭证是否仍有效若有效则直接返回无任何额外开销若已过期则区分两种情况客户端支持认证刷新supportsAuthenticationRefresh()时调用authState.refreshAuthentication()获取 broker 侧 challenge 数据通过Commands.newAuthChallenge向客户端发起挑战进入重新认证握手客户端不支持认证刷新时broker 直接关闭连接ctx.close()。状态机的底层契约定义在 AuthenticationState.javaisExpired()默认返回false表示该认证方式无过期概念refreshAuthentication()默认返回AuthData.REFRESH_AUTH_DATA。各认证提供方可覆写这两个方法实现各自凭证的过期判定与刷新协议例如 JWT Token 认证即可实现基于过期时间的自动刷新。此外在刷新流程中还内置了安全约束刷新后的角色不得改变若authRole与刷新前不一致broker 会记录告警并关闭连接见 ServerCnx.java防止认证刷新被利用来提升权限。代理场景的凭证转发约束在启用 proxy 的场景下若originalPrincipal存在但originalAuthState为空即 proxy 未转发原始客户端凭证broker 在凭证过期时无法重新校验用户凭证也会直接关闭连接见 ServerCnx.java。这提醒我们启用认证刷新的部署中proxy 必须正确转发原始认证数据否则长连接会在凭证到期时被强制断开。Role Tokens认证与授权之间的桥梁在 Pulsar 中role角色是一个字符串例如admin或app1它可以代表单个客户端也可以代表多个客户端即多个客户端共享同一角色。角色用于控制客户端对特定 topic 的生产/消费权限、对 tenant 配置的管理权限等。认证与授权通过Role Token衔接起来认证阶段Pulsar 使用某个 Authentication Provider 确立客户端身份角色分配认证成功后为该客户端分配一个role token即上文所述的 principal授权阶段该 role token 被用于 Authorization and ACLs判定该客户端被授权执行哪些操作。从源码看认证返回角色正是AuthenticationProvider.authenticate()与AuthenticationState.getAuthRole()的语义所在前者在认证成功时返回 role 字符串后者在认证完成后对外暴露该角色见 AuthenticationProvider.java 与 AuthenticationState.java。认证提供方Authentication Providers当前对应 2.2.0 版本文档Pulsar 支持以下四类认证提供方认证提供方说明仓库中的对应实现TLS Authentication基于 TLS 客户端证书的身份认证AuthenticationProviderTlsAthenz基于 Athenz 生态的认证由独立的pulsar-broker-auth-athenz模块提供pulsar-broker-auth-athenz模块Kerberos基于 Kerberos / SASL 的身份认证由pulsar-broker-auth-sasl模块提供pulsar-broker-auth-sasl模块JSON Web Token Authentication基于 JWT 令牌的认证AuthenticationProviderToken、AuthTokenUtils说明2.2.0 版本文档列出的四类提供方均为可独立启用的方案。仓库根目录下pulsar-broker-auth-athenz、pulsar-broker-auth-sasl、pulsar-client-auth-athenz、pulsar-client-auth-sasl等独立模块表明Athenz 与 Kerberos 认证在工程实现上以独立模块形式存在broker 侧与客户端侧相互配套。最小安全加固实践清单综合上述原理落地一份可操作的安全加固清单如下先做网络隔离将 broker / proxy 的明文服务端口限制在可信网络内或直接关闭明文端口只开放 TLS 端口开启认证在 conf/broker.conf 中设置authenticationEnabledtrue并按需在authenticationProviders中填入一个或多个提供方类名多个用逗号分隔开启授权并指定超级用户设置authorizationEnabledtrue并在superUserRoles中填写管理员角色需要转发客户端身份时还需正确配置proxyRoles详见 security-authorization.md评估凭证刷新策略对支持过期机制的凭证如 JWT结合authenticationRefreshCheckSeconds的默认 60s 周期设计刷新流程同时确认 proxy 场景下原始凭证会被正确转发避免长连接被强制断开为 broker 与 proxy 配置自身的客户端凭证broker 与 broker 之间、broker 与 proxy 之间也会建立连接如同步元数据、geo-replication需要通过brokerClientAuthenticationPlugin与brokerClientAuthenticationParameters见 conf/broker.conf为这些内部连接配置认证凭证。总结Pulsar 的安全体系以可插拔认证 角色授权 生命周期管理为三条主线默认全开放的状态要求部署者主动做网络隔离与 ACL 限制AuthenticationProvider抽象与AuthenticationProviderList组合实现让多认证来源共存成为可能连接建立时的单次认证配合authenticationRefreshCheckSeconds驱动的周期性凭证过期检查在不打断正常通信与保障凭证新鲜度之间取得了平衡。理解这些底层机制是正确配置 TLS、Athenz、Kerberos 或 JWT 认证、设计高可用安全集群的前提。需要深入某一具体认证方案的配置细节时可继续阅读仓库中对应的分册文档TLS 认证、Athenz、Kerberos、JWT。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 安全总览认证、授权与凭证刷新机制实战指南Apache Pulsar 安全总览认证、授权与凭证刷新机制实战指南 作为企业的中央消息总线Apache Pulsar 经常被用于承载关键业务数据miss消息队列后端流处理Apache Pulsar 安全机制全解析认证、授权与凭据刷新机制实践指南Apache Pulsar 安全机制全解析认证、授权与凭据刷新机制实践指南 导读 本文以 Apache Pulsar 安全体系为主线围绕可插拔认证Au消息队列后端流处理Apache Pulsar安全机制完全指南认证授权与数据加密实战Apache Pulsar安全机制完全指南认证授权与数据加密实战 Apache Pulsar作为新一代分布式发布订阅消息系统其安全机制设计完善且强大。本文将消息队列后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Pulsar 安全机制全解析：认证、授权、Role Tokens 与凭证刷新原理
消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载作为企业级分布式消息中间件Apache Pulsar 经常承担业务关键数据的存储与流转职责其安全体系的完备程度直接决定了整个消息系统的可信边界。本文以 Pulsar 2.2.0 的安全概览文档security-overview.md为骨架系统讲解 Pulsar 的安全默认状态、可插拔认证机制、认证凭证的过期与刷新原理、Role Tokens 的授权模型以及当前支持的四类认证提供方并结合仓库源码pulsar-broker-common、pulsar-broker模块与 conf/broker.conf 配置项逐一佐证。读完本文你将掌握 Pulsar 安全体系的最小可用配置方法、理解 broker 侧认证生命周期管理的底层实现并能依据实际业务场景在 TLS、Athenz、Kerberos、JWT 等认证方案中做出正确选型。Pulsar 的安全默认状态为什么要主动加固Pulsar 的默认安装不启用任何加密、认证与授权任何客户端都可以通过明文的服务 URLplain text service URLs直接与 Pulsar 通信。从 conf/broker.conf 的默认值可以清楚地看到这一点# Enable authentication authenticationEnabledfalse # Authentication provider name list, which is comma separated list of class names authenticationProviders # Enforce authorization authorizationEnabledfalse # Role names that are treated as super-user, meaning they will be able to do all admin # operations and publish/consume from all topics superUserRoles也就是说如果直接把集群暴露给不可信网络任何人均可访问集群中的全部资源。官方文档给出的加固思路是必须确保通过明文服务 URL 访问 Pulsar 的客户端仅限于可信客户端具体手段包括网络分段Network segmentation通过防火墙、VPC、安全组等手段将 broker、proxy 的明文服务端口限制在可信网段内授权 ACL借助授权机制仅允许受信任的 IP / 角色访问。如果两者都不采用集群就处于全开放状态任何人可以读写任意 topic、执行管理操作——这是 Pulsar 部署中最常见的风险来源。可插拔认证机制从单提供方到多提供方Pulsar 支持可插拔pluggable的认证机制客户端使用该机制与 broker、proxy 完成身份验证。更关键的是Pulsar 还允许同时配置多个认证来源让不同的客户端使用不同的认证方式连接同一集群。这一能力的源码基础是pulsar-broker-common模块中的认证抽象层AuthenticationProvider.java认证提供方的顶层接口定义了initialize(ServiceConfiguration config)初始化、getAuthMethodName()返回该提供方支持的认证方法名、authenticate(AuthenticationDataSource authData)校验凭证并返回角色字符串、newAuthState(...)创建认证状态等核心方法AuthenticationProviderList.java一个包装了多个认证提供方的组合实现它会按顺序逐个尝试各个 provider只要其中一个校验通过即返回成功全部失败时才抛出最后的认证异常。这正是一个 broker 同时支持多种认证来源的实现机制AuthenticationService.javabroker 启动时根据配置中的authenticationProviders列表通过反射实例化各个 provider并以getAuthMethodName()作为 key 进行组织管理。对应的配置项是 broker 配置中的authenticationProviders见 conf/broker.conf它是一个以逗号分隔的类名列表。例如同时启用 TLS 与 JWT 认证authenticationEnabledtrue authenticationProvidersorg.apache.pulsar.broker.authentication.AuthenticationProviderTls,org.apache.pulsar.broker.authentication.AuthenticationProviderToken从pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authentication/目录可以看到仓库中已内置的提供方实现包括AuthenticationProviderTlsTLS 客户端证书认证、AuthenticationProviderTokenJWT Token 认证、AuthenticationProviderBasicHTTP Basic 认证等它们与文档列出的四类认证方案一一对应详见下文。认证生命周期连接建立、Principal 存储与凭证刷新连接建立时的凭证校验当客户端与 broker 建立连接时broker 会立即校验认证凭证。校验逻辑位于 ServerCnx.java 的handleConnect流程中如果service.isAuthenticationEnabled()为真则读取CommandConnect携带的认证数据调用认证服务完成身份确认并生成对应的AuthenticationState状态对象。一次性认证与 Principal 存储值得特别注意的是连接完成初始认证后broker 并不会在后续通信中反复重新认证。认证得到的principal token即角色令牌会被持久存储在连接上用于后续的授权判断。也就是说认证只发生一次连接建立时授权则贯穿连接的整个生命周期——每一次对 topic、namespace 的操作都基于该连接上已存储的 principal 进行 ACL 判定。凭证过期的定期检查与强制重新认证虽然连接不会主动重新认证但凭证本身可能过期。为此broker 会周期性检查每一个ServerCnx对象的过期状态。检查频率由 broker 配置authenticationRefreshCheckSeconds控制默认值为60 秒见 conf/broker.conf 与 ServiceConfiguration.java# Interval of time for checking for expired authentication credentials authenticationRefreshCheckSeconds60一旦检测到凭证过期broker 会强制对连接重新认证若重新认证失败broker 将直接断开该客户端连接。这一机制的实现位于 ServerCnx.javamaybeScheduleAuthenticationCredentialsRefresh()使用 Netty event loop 的scheduleAtFixedRate以authenticationRefreshCheckSeconds为周期启动定时任务refreshAuthenticationCredentials()首先通过authState.isExpired()判断凭证是否仍有效若有效则直接返回无任何额外开销若已过期则区分两种情况客户端支持认证刷新supportsAuthenticationRefresh()时调用authState.refreshAuthentication()获取 broker 侧 challenge 数据通过Commands.newAuthChallenge向客户端发起挑战进入重新认证握手客户端不支持认证刷新时broker 直接关闭连接ctx.close()。状态机的底层契约定义在 AuthenticationState.javaisExpired()默认返回false表示该认证方式无过期概念refreshAuthentication()默认返回AuthData.REFRESH_AUTH_DATA。各认证提供方可覆写这两个方法实现各自凭证的过期判定与刷新协议例如 JWT Token 认证即可实现基于过期时间的自动刷新。此外在刷新流程中还内置了安全约束刷新后的角色不得改变若authRole与刷新前不一致broker 会记录告警并关闭连接见 ServerCnx.java防止认证刷新被利用来提升权限。代理场景的凭证转发约束在启用 proxy 的场景下若originalPrincipal存在但originalAuthState为空即 proxy 未转发原始客户端凭证broker 在凭证过期时无法重新校验用户凭证也会直接关闭连接见 ServerCnx.java。这提醒我们启用认证刷新的部署中proxy 必须正确转发原始认证数据否则长连接会在凭证到期时被强制断开。Role Tokens认证与授权之间的桥梁在 Pulsar 中role角色是一个字符串例如admin或app1它可以代表单个客户端也可以代表多个客户端即多个客户端共享同一角色。角色用于控制客户端对特定 topic 的生产/消费权限、对 tenant 配置的管理权限等。认证与授权通过Role Token衔接起来认证阶段Pulsar 使用某个 Authentication Provider 确立客户端身份角色分配认证成功后为该客户端分配一个role token即上文所述的 principal授权阶段该 role token 被用于 Authorization and ACLs判定该客户端被授权执行哪些操作。从源码看认证返回角色正是AuthenticationProvider.authenticate()与AuthenticationState.getAuthRole()的语义所在前者在认证成功时返回 role 字符串后者在认证完成后对外暴露该角色见 AuthenticationProvider.java 与 AuthenticationState.java。认证提供方Authentication Providers当前对应 2.2.0 版本文档Pulsar 支持以下四类认证提供方认证提供方说明仓库中的对应实现TLS Authentication基于 TLS 客户端证书的身份认证AuthenticationProviderTlsAthenz基于 Athenz 生态的认证由独立的pulsar-broker-auth-athenz模块提供pulsar-broker-auth-athenz模块Kerberos基于 Kerberos / SASL 的身份认证由pulsar-broker-auth-sasl模块提供pulsar-broker-auth-sasl模块JSON Web Token Authentication基于 JWT 令牌的认证AuthenticationProviderToken、AuthTokenUtils说明2.2.0 版本文档列出的四类提供方均为可独立启用的方案。仓库根目录下pulsar-broker-auth-athenz、pulsar-broker-auth-sasl、pulsar-client-auth-athenz、pulsar-client-auth-sasl等独立模块表明Athenz 与 Kerberos 认证在工程实现上以独立模块形式存在broker 侧与客户端侧相互配套。最小安全加固实践清单综合上述原理落地一份可操作的安全加固清单如下先做网络隔离将 broker / proxy 的明文服务端口限制在可信网络内或直接关闭明文端口只开放 TLS 端口开启认证在 conf/broker.conf 中设置authenticationEnabledtrue并按需在authenticationProviders中填入一个或多个提供方类名多个用逗号分隔开启授权并指定超级用户设置authorizationEnabledtrue并在superUserRoles中填写管理员角色需要转发客户端身份时还需正确配置proxyRoles详见 security-authorization.md评估凭证刷新策略对支持过期机制的凭证如 JWT结合authenticationRefreshCheckSeconds的默认 60s 周期设计刷新流程同时确认 proxy 场景下原始凭证会被正确转发避免长连接被强制断开为 broker 与 proxy 配置自身的客户端凭证broker 与 broker 之间、broker 与 proxy 之间也会建立连接如同步元数据、geo-replication需要通过brokerClientAuthenticationPlugin与brokerClientAuthenticationParameters见 conf/broker.conf为这些内部连接配置认证凭证。总结Pulsar 的安全体系以可插拔认证 角色授权 生命周期管理为三条主线默认全开放的状态要求部署者主动做网络隔离与 ACL 限制AuthenticationProvider抽象与AuthenticationProviderList组合实现让多认证来源共存成为可能连接建立时的单次认证配合authenticationRefreshCheckSeconds驱动的周期性凭证过期检查在不打断正常通信与保障凭证新鲜度之间取得了平衡。理解这些底层机制是正确配置 TLS、Athenz、Kerberos 或 JWT 认证、设计高可用安全集群的前提。需要深入某一具体认证方案的配置细节时可继续阅读仓库中对应的分册文档TLS 认证、Athenz、Kerberos、JWT。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 安全总览认证、授权与凭证刷新机制实战指南Apache Pulsar 安全总览认证、授权与凭证刷新机制实战指南 作为企业的中央消息总线Apache Pulsar 经常被用于承载关键业务数据miss消息队列后端流处理Apache Pulsar 安全机制全解析认证、授权与凭据刷新机制实践指南Apache Pulsar 安全机制全解析认证、授权与凭据刷新机制实践指南 导读 本文以 Apache Pulsar 安全体系为主线围绕可插拔认证Au消息队列后端流处理Apache Pulsar安全机制完全指南认证授权与数据加密实战Apache Pulsar安全机制完全指南认证授权与数据加密实战 Apache Pulsar作为新一代分布式发布订阅消息系统其安全机制设计完善且强大。本文将消息队列后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考