查看原文
其他

深入了解 Pulsar 认证和授权机制

🐟 ApachePulsar 2021-10-18


五一假期后的第一场 TGIP-CN 的直播,继续由郭斯杰大佬为我们带来关于「Deep dive into authentication and authorization」相关内容。


首先回顾一些最近一周 Pulsar 的相关进展:


1. Pulsar 2.5.2 版本即将发布,敬请期待


2. 新增 PIP-63: Readonly Topic Ownership
https://github.com/apache/pulsar/wiki/PIP-63%3A-Readonly-Topic-Ownership-Support


3. 5 月 26 日,将由 Nutanix 的 Shivji Kumar Jha 带来关于「Lessons From Managing A Pulsar Cluster」的线上研讨会。

如果你想参与此活动,可以通过以下链接进行申请,当然也可以期待后续的视频回放。
https://us02web.zoom.us/webinar/register/2015887356422/WN_gZqEn6KTRu25wh4d36bdCw


接下来就一起看看关于认证和授权的相关细节吧!




认证和授权的概念


Pulsar 里的授权机制一直围绕着「Role token」进行,这个角色是任意的一串字符,用来标示“连接到 broker 时所代表的信息”。那如何知道目前连接的信息用户是谁呢?这里就用到了  Authentication Provider


这是一个认证机制的插件,通过配置插件来判断连接过来客户端的角色。Role 一旦通过认证,就会再通过授权机制来判断此角色是否有相应权限。


关于 Authentication Provider 认证方面,Pulsar 提供了很多方式:


  • Athenz
  • Kerberos
  • JSON Web Token Authentication
  • TLS Authentication

这些的具体细节,在 Pulsar 官网的文档里其实有很多的介绍,大家可以在官网进行查阅。
https://pulsar.apache.org/docs/en/security-overview/ 

有了认证后,就可以证明这条链接“你是谁”的问题,而授权机制则是代表了「对于这件事情你有哪些权限」。目前 Pulsar 的授权也是基于插件上进行操作的,默认 Pulsar 授权机制是基于 ZooKeeper 实现的。

授权机制相对比较简单,首先需要确认 role token 是否是超级用户 superusers,可以判断是否有全部的权限。

另一个就是 tenant-admin 里,是否对 tenant 下的 namespace 有相应的权限。还有对于某一个 namespace 是否有生产、消费、执行 function 的权限。



配置认证和授权时,需要考虑哪些?

正常 Pulsar 结构组织里,必不可少的就是三大件:ZooKeeper、Bookie 和 Broker。

Broker 与 ZooKeeper、Bookie 和 ZooKeeper 之间也需要有认证操作。如果 broker 需要暴露出去,那么也就需要 proxy 依靠于 load balancer 出现。所以这就是最基本的拓扑图,可以更清楚的去设定一个认证和授权的配置。


在这里有一个环节大家很容易忽略。很多人觉得客户端与 broker 打交道,proxy 与 broker 连接就可以了。但是 broker 与其他的 broker 之间也会进行相连,尤其是在跨机房复制的过程中, 所以也需要进行认证等步骤。

在开始配置认证和授权时,会先从 broker 开始。首先要开启认证,然后确认开启认证的插件,即 “Provider=” 后边要填写的内容,认证后需要开启授权以及授权插件的填写。最后 superUserRoles 是要告诉 broker 哪些用户是你的超级用户。


具体关于 broker 端的认证授权代码操作,可以参考视频回放中 29:00-38:10 时间段。

Broker 端配置完成后,就需要配置客户端的相关设置了。让客户端将认证的参数等传给 broker,这样 broker 端才能进行它的认证和授权操作。客户端的操作只需配置两个参数`authPlugin=``authParams=`,即使用 JWT 的认证方式时,会传入的认证参数。

这时客户端访问 broker,就可以进行相应地认证和授权了。

以上两大部分配置完成后觉得没有问题了,在执行相应命令时发现有“返回 401,没有权限”等相关提示。这是什么问题呢?

这是因为 broker 与 broker 之间还有连接的存在。HTTP 的请求会发给任何一台 broker,但是这台 broker 不一定是这条消息的 ownership,所以它就需要跟其他的 broker 互联访问。所以如果你开启了认证,就必须保证 broker 与 broker 之间的通讯也要包含认证操作的。

这个 broker 去访问另一个 broker 时,需要带上相应的认证信息,否则这个链接是无法访问的。因此可以看作第二个 broker 是第一个 broker 的 client。


在这里需要配置的一些细节就是 `brokerClientAuthenticationPlugin=``brokerClientAuthenticationParameters=`,这个跟上边客户端配置的两处是类似的。具体详细代码应用及 proxy 补充细节,可以参考视频回放中 46:30-56:00 时间段。

特别注意一点,所有的验证操作在配置时,都需要在服务端客户端进行相应的操作。

所以当你有了前边的清晰架构后,后边再添加其他组件时,就会比较清楚地知道哪些是服务端了。

当然除了以上这些组件,可能你的构建结构中还有 function、function worker 等。


Function worker 可以看做是另一组进程。客户端想去访问 function worker 时,是需要开启认证和授权的过程,配置细节与上方 broker 端的配置数据类似,可以举一反三。同样的,如果 proxy 与 funciton worker 连接访问时,也需要在 proxy 配置这些信息。

而 Function worker 作为一个元数据代理/服务端,在实际操作中还会创建出 Pulsar function。Function 在执行时要生产和消费消息,所以需要跟 broker 打交道。所以他们之间也需要配置那些信息,但是是借由 function worker 继承而来。

具体关于 function 以及 function worker 的认证和授权代码细节分析,可以参考视频回放中 57:00-64:26 时间段。

总结来说,对于认证过程的配置,就是要分辨清楚谁是「服务端」,谁是「客户端」。不同端向配置不同的数据类别。

如果对于一个服务而言,它既是一个服务端,又是客户端的话,则需要同时配置两种媒介端的数据信息。同时规划好「谁是 superuser」,这些基本就是 Pulsar 认证过程的重点了。



本期 Q&A

Q:只启用 client 与 proxy 之间的权限认证是不是就可以了?

A:不可以,认证可以在 proxy 进行,但是授权不可以在 proxy 进行。


总 结

本次直播分享了关于 Pulsar 里的认证和授权配置相关,希望大家能通过上文提供的文字重点+视频回放中的细节可以更清楚的理解这两个机制。


想要获取更多关于「authentication and authorization」相关参考,可以查阅 Pulsar 官网的文档或点击「阅读原文」。
https://pulsar.apache.org/docs/en/security-overview/

同时如果你有更多想要了解的 Pulsar 话题,也可以去 tgip-cn repo 下提 issues,我们也会选取大家的提议进行相关话题的直播。
https://github.com/streamnative/tgip-cn/issues

查看往期 TGIP-CN 系列回顾
可点击👉🏻「专辑列表」👈🏻进行查看


: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存