消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载本指南以 Apache Pulsar 官方文档《Authentication and authorization in Pulsar》版本 2.2.0 文档位于 security-authorization.md为骨架结合当前仓库的配置模板与源码实现展开。读完本文你将掌握Pulsar 中认证authentication与授权authorization的关系与分工如何在 Broker 与 Proxy 上启用授权并配置 superuser 与 Proxy Roles如何通过pulsar-admin创建租户、为命名空间与主题授予/撤销 ACL 权限以及如何为管理端PulsarAdmin配置认证含 TLS。文章中的配置项默认值、命令行参数与源码行为均以当前仓库实际内容为准。授权在 Pulsar 安全体系中的定位在 Pulsar 中认证 ProviderAuthentication Provider负责正确识别客户端身份并将客户端与 角色令牌role tokens 关联起来。如果只启用认证而不启用授权那么任何通过认证的角色令牌都能访问集群中的所有资源。授权Authorization是决定客户端能够做什么的过程即根据角色令牌对特定资源租户、命名空间、主题执行操作的许可判定。权限层级中的最高级角色是superusers超级用户拥有最高权限的角色令牌。superuser 可以创建和销毁租户tenant并对所有租户资源拥有完全访问权限。当一个 superuser 创建了 租户 时该租户会被指定一个admin 角色admin role。持有 admin 角色令牌的客户端可以创建、修改和销毁该租户下的命名空间namespace并可在这些命名空间上对其他角色令牌授予和撤销权限。Broker 与 Proxy 的授权配置在 Broker 上启用授权并指定 superuser授权开关和 superuser 列表在 Broker 配置文件conf/broker.conf中设置authorizationEnabledtrue superUserRolesmy-super-user-1,my-super-user-2完整的参数列表见conf/broker.conf文件各参数的默认值可参考 Broker 配置参考。当前仓库conf/broker.conf中与该功能直接相关的参数及其默认值如下与 ServiceConfiguration.java 中的字段默认值一一对应参数默认值说明authorizationEnabledfalse是否强制启用授权。默认关闭即任何通过认证的客户端可访问所有资源superUserRoles空被视为超级用户的角色名列表逗号分隔可执行所有 admin 操作并 publish/consume 所有主题proxyRoles空被视为代理角色的角色名列表。Broker 看到来自这些角色的请求时会要求请求必须携带有效的 original principal见下文authenticateOriginalAuthDatafalse若置为trueBroker 会对 original Auth 数据进行认证否则仅接受originalPrincipal并在需要时对其进行授权authorizationProviderorg.apache.pulsar.broker.authorization.PulsarAuthorizationProvider授权 Provider 的完全限定类名支持插件化替换authorizationAllowWildcardsMatchingfalse是否允许在授权中进行通配符匹配仅当通配符*出现在角色名首位或末位时生效例如*.pulsar.service、pulsar.service.*anonymousUserRole空当此参数非空时未认证用户以anonymousUserRole的角色执行操作需要说明的是仅开启认证、未开启授权时认证令牌即可访问全部资源——这正是必须在 Broker 上同时开启authorizationEnabledtrue的原因。典型的使用方式是superuser 角色用于管理员、客户端以及 Broker 之间的授权。当使用跨地域复制geo-replication时每个 Broker 都需要能够向其他集群的所有主题发布消息因此 Broker 间的连接通常也要以 superuser 身份进行认证与授权。在 Proxy 上启用授权同样地可以在 Proxy 配置文件conf/proxy.conf中启用授权# 在 conf/proxy.conf 中 authorizationEnabledfalse # 默认关闭需改为 true superUserRoles authorizationProviderorg.apache.pulsar.broker.authorization.PulsarAuthorizationProvider在 Proxy 上启用授权后Proxy 会在把请求转发给 Broker 之前先做一次额外的授权检查如果 Broker 上也启用了授权那么 Broker 在收到转发过来的请求时还会再检查一次该请求的授权。由此形成Proxy 前置检查 Broker 二次检查的双重防线。conf/proxy.conf中还有一个值得注意的参数forwardAuthorizationCredentials默认false它决定是否把客户端的授权凭证转发给 Broker 以进行二次授权且要求先启用authenticationEnabledtrue才生效。提示conf/standalone.conf单机模式、conf/websocket.confWebSocket 服务以及conf/functions_worker.ymlFunctions Worker中也都有authorizationEnabled/superUserRoles/proxyRoles等同类配置项默认值均为关闭/空可按部署形态分别开启。Proxy Roles代理角色默认情况下Broker 把 Proxy 与 Broker 之间的连接当作普通用户连接处理Broker 会以conf/proxy.conf中配置的角色来认证该用户参见 在 Proxy 上启用 TLS 认证。但用户通过 Proxy 连接集群时通常并不想再向 Broker 单独认证一次——用户期望的是以自己向 Proxy 认证时使用的角色身份来与集群交互。Pulsar 通过Proxy Roles机制实现这一目标。Proxy Roles 在 Broker 配置文件conf/broker.conf中指定如果某个与 Broker 完成认证的客户端其角色是proxyRoles中的一员那么来自该客户端的所有请求都必须额外携带该客户端向 Proxy 认证时的角色信息这个信息被称为original principal原始主体。如果缺少 original principal该客户端将无法访问任何资源。因此要让资源可以通过 Proxy 被访问必须同时授权 proxy role 和 original principal 两者。管理员有两种做法方式一更安全每次授权资源时都同时授予 proxy role。例如proxy role 名为proxy1则当 superuser 创建租户时应把proxy1一并指定为 admin 角色之一当某个角色被授予在命名空间上 produce/consume 的权限时如果该客户端要通过 Proxy 生产/消费则也应当给proxy1授予相同权限。方式二把 proxy role 直接设为 superuser。这样 Proxy 可以访问所有资源。客户端仍然需要向 Proxy 认证所有经由 Proxy 发出的请求其角色都会被降级为已认证客户端的 original principal。风险在于一旦 Proxy 被攻破攻击者就能获得整个集群的完全访问权限。在conf/broker.conf中指定 proxy rolesproxyRolesmy-proxy-role # 如果你想让 superuser 也能使用该 proxy见上文方式二 superUserRolesmy-super-user-1,my-super-user-2,my-proxy-role源码层面的双重校验逻辑可参见 AuthorizationService.java当请求的clientRole命中proxyRoles时isSuperUser与各类allowXxxOperationAsync都会把proxy role 是否被授权和original principal 是否被授权两者做 AND 合并——任一未授权即拒绝。而 isValidOriginalPrincipal 则校验角色组合的合法性当authenticatedPrincipal命中proxyRoles时originalPrincipal必须存在且不能也是 proxy role当非 proxy role 携带了originalPrincipal时会记录告警日志originalPrincipal只允许等于自身角色且未来版本将不再允许该行为。这从代码层面印证了文档中的约束Proxy 场景下proxy role original principal二者缺一不可。租户管理Administer tenantsPulsar 实例 的管理员或某种自助服务门户通常会负责为业务方供给一个 Pulsar 租户。租户管理使用pulsar-admin工具完成。创建一个新租户下面是一个创建租户的示例命令$ bin/pulsar-admin tenants create my-tenant \ --admin-roles my-admin-role \ --allowed-clusters us-west,us-east该命令创建了一个名为my-tenant的新租户允许其使用us-west和us-east两个集群。一个能够成功认证为my-admin-role角色的客户端就被允许对该租户执行所有管理任务。对应命令的 CLI 实现位于 CmdTenants.java参数细节如下参数短参数说明--admin-roles-r允许管理该租户的认证主体auth principal列表逗号分隔省略则为空--allowed-clusters-c允许使用的集群列表逗号分隔省略时默认赋值为当前所有可用集群同时pulsar-admin tenants update也支持--admin-roles/--allowed-clusters用于在保留现有配置的基础上增量修改租户的管理角色与可用集群。Pulsar 中主题名称的结构恰好体现了租户、集群与命名空间之间的层级关系persistent://tenant/namespace/topic即persistent://租户/命名空间/主题这也解释了为何租户是授权边界的第一层授予了租户 admin 角色即可管理其下所有命名空间与主题。管理权限Manage permissions可以使用 Pulsar Admin Tools权限管理 API 来管理 Pulsar 中的权限。通过pulsar-admin可以针对命名空间与主题分别执行权限的授予与撤销。以命名空间为例CLI 实现位于 CmdNamespaces.java# 授予给角色 my-client-role 授予在 my-tenant/my-ns 上 produce 与 consume 的权限 $ bin/pulsar-admin namespaces grant-permission my-tenant/my-ns \ --role my-client-role \ --actions produce,consume # 撤销移除角色 my-client-role 在该命名空间上的所有权限 $ bin/pulsar-admin namespaces revoke-permission my-tenant/my-ns \ --role my-client-role--actions支持的取值来自源码中的命令描述包括produce、consume、sources、sinks、functions、packages。对应的主题级命令为pulsar-admin topics grant-permission/pulsar-admin topics revoke-permission实现见 CmdPersistentTopics.java 与 CmdTopics.java。此外Pulsar 还支持订阅级subscription权限pulsar-admin namespaces grant-subscription-permission/revoke-subscription-permission/get-permission-on-subscription用于控制哪些角色可以访问订阅的管理 API。底层实现可参见默认授权 Provider PulsarAuthorizationProvider.java默认的PulsarAuthorizationProvider把授权策略ACL存储在元数据存储MetadataStore如 ZooKeeper中通过pulsarResources读写租户/命名空间的 policy 数据生产/消费等操作在 checkPermission 中按命名空间级 ACL → 主题级 ACL → 通配符匹配的顺序判定先看该角色在命名空间级namespaceAuthentication中是否具备对应AuthAction再看主题级topicAuthentication中是否授权最后若authorizationAllowWildcardsMatchingtrue做前缀/后缀通配匹配分区主题还会回退检查其分区主题partitioned topic本身的策略判定通过后还会执行 checkCluster 的集群校验本地集群或全局主题global放行其他集群须确认其存在于集群列表中消费检查canConsumeAsync还会校验订阅级授权列表以及在subscription_auth_modePrefix模式下要求订阅名必须以角色名称为前缀在 AuthorizationService 层面superuser 拥有最短路径豁免canProduceAsync/canConsumeAsync/canLookupAsync都会先调用provider.isSuperUser(...)命中 superuser 则直接放行否则才继续走上述 ACL 判定。管理端 PulsarAdmin 的认证配置除了面向用户的pulsar-adminCLI程序化管理接口PulsarAdmin同样需要携带认证信息。下面的 Java 代码演示如何构建一个带认证的管理客户端PulsarAdmin admin PulsarAdmin.builder() .serviceHttpUrl(http://broker:8080) .authentication(com.org.MyAuthPluginClass, param1:value1) .build();若要使用 TLSPulsarAdmin admin PulsarAdmin.builder() .serviceHttpUrl(https://broker:8080) .authentication(com.org.MyAuthPluginClass, param1:value1) .tlsTrustCertsFilePath(/path/to/trust/cert) .build();要点说明serviceHttpUrl指向 Broker 的 Web 服务地址使用 TLS 时协议切换为httpsauthentication接受两个参数认证插件类的完全限定名如 Pulsar 内置的org.apache.pulsar.client.impl.auth.AuthenticationToken等可参照认证 Provider 文档以及插件所需的参数字符串形如param1:value1具体格式取决于插件例如 Token 认证的token:xxxTLS 场景下通过tlsTrustCertsFilePath指定信任证书路径用于校验服务端证书链。小结Pulsar 的授权体系以角色令牌为身份载体以租户 → 命名空间 → 主题为资源层级通过authorizationEnabledsuperUserRolesproxyRoles三项核心配置构建起完整的访问控制模型。在引入 Proxy 时务必理解proxy role 与 original principal 必须同时被授权这一关键约束并按安全等级选择逐资源授予 proxy role或proxy role 设为 superuser两种策略。配合pulsar-admin的租户/权限管理命令与带认证的PulsarAdmin管理端即可在生产环境中落地一套完整、可审计的多租户 ACL 方案。延伸阅读同一版本文档目录安全总览认证 Provider、角色令牌与过期刷新机制多租户概念租户/命名空间/集群的层次关系权限管理 API以 Admin API 视角管理 ACLBroker 配置参考authorizationEnabled等参数的完整说明pulsar-admin 工具参考全部 CLI 子命令赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 授权与 ACL 配置实战Broker/Proxy 授权、代理角色与租户权限管理Apache Pulsar 授权与 ACL 配置实战Broker/Proxy 授权、代理角色与租户权限管理 Apache Pulsar 的授权Authori消息队列后端流处理Apache Pulsar 授权与 ACL 实战指南从 Broker 配置到租户权限管理Apache Pulsar 授权与 ACL 实战指南从 Broker 配置到租户权限管理 导读 本指南系统讲解 Apache Pulsar 的授权Autho消息队列后端流处理Apache Pulsar 授权机制详解Authorization 配置、Superusers 与 Proxy Roles 实战指南Apache Pulsar 授权机制详解Authorization 配置、Superusers 与 Proxy Roles 实战指南 本文基于 Apache消息队列后端流处理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
