一加Ace2 Pro官宣：普及16G內(nèi)存 引領(lǐng)24G
一加官方今天繼續(xù)為本月發(fā)布的新機(jī)一加Ace2 Pro帶來預(yù)熱，公布了內(nèi)存方面的信息。“淘汰 8GB ，12GB 起步，16GB 普及，24GB 引領(lǐng)，還有呢？#一加Ace2Pro#，2023 年 8 月，敬請期待。”同時
最近在測試將 Pulsar 2.11.2 升級到 3.0.1的過程中碰到一個鑒權(quán)問題，正好借著這個問題充分了解下 Pulsar 的鑒權(quán)機(jī)制是如何運(yùn)轉(zhuǎn)的。
Pulsar 支持 Namespace/Topic 級別的鑒權(quán)，在生產(chǎn)環(huán)境中往往會使用 topic 級別的鑒權(quán)，從而防止消息泄露或者其他因?yàn)闄?quán)限管控不嚴(yán)格而導(dǎo)致的問題。
圖片
我們會在創(chuàng)建 topic 的時候?yàn)?nbsp;topic 綁定一個應(yīng)用，這樣就只能由這個應(yīng)用發(fā)送消息，其他的應(yīng)用嘗試發(fā)送消息的時候會遇到 401 鑒權(quán)的異常。
同理，對于訂閱者也可以關(guān)聯(lián)指定的應(yīng)用，從而使得只有規(guī)定的應(yīng)用可以消費(fèi)消息。
以上的兩個功能本質(zhì)上都是通過 Pulsar 的 admin-API 實(shí)現(xiàn)的。
圖片
這里關(guān)鍵的就是 role，在我們的場景下通常是一個應(yīng)用的 AppId，只要是一個和項(xiàng)目唯一綁定的 ID 即可。
這只是授權(quán)的一步，整個鑒權(quán)流程圖如下：
圖片
bin/pulsar tokens create-key-pair --output-private-key my-private.key --output-public-key my-public.key將公鑰分發(fā)到 broker 的節(jié)點(diǎn)上，鑒權(quán)的時候 broker 會使用公鑰進(jìn)行驗(yàn)證。
而私鑰通常是管理員單獨(dú)保存起來用于在后續(xù)的步驟為客戶端生成 token
之后我們便可以使用這個私鑰生成 token 了：
bin/pulsar tokens create --private-key file:///path/to/my-private.key / --subject 123456eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJhZG1pbiJ9其中的 subject 和本文長提到的 role 相等
只是單純生成了 token 其實(shí)并沒有什么作用，還得將 subject(role) 與 topic 進(jìn)行授權(quán)綁定。
圖片
也就是上圖的這個步驟。
這里創(chuàng)建的 admin 客戶端也得使用一個 superRole 角色的 token 才有權(quán)限進(jìn)行授權(quán)。superRole 使用在 broker.conf 中進(jìn)行配置。
PulsarClient client = PulsarClient.builder() .serviceUrl("pulsar://broker.example.com:6650/") .authentication(AuthenticationFactory.token("eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJKb2UifQ.ipevRNuRP6HflG8cFKnmUPtypruRC4fb1DWtoLL62SY")） .build();使用剛才私鑰生成的 token 接入 broker 才能生產(chǎn)或者消費(fèi)數(shù)據(jù)。
這些流程正常都沒啥問題，但直到我升級了 Pulsar3.0 后客戶端直接就連不上了。
在 broker 中看到了 WARN 的警告日志：
cannot specify originalPrincipal when connecting without valid proxy role
圖片
之后在 3.0 的升級日志中看到相關(guān)的 Issue。
從這個 PR 相關(guān)的代碼和變更的文檔可以得知：
圖片
圖片
升級到 3.0 之后風(fēng)險(xiǎn)校驗(yàn)等級提高了，proxyRole 這個字段需要在 broker 中進(jìn)行指定（之前的版本不需要強(qiáng)制填寫）。
因?yàn)槲覀兪褂昧?Proxy 組件，所有的請求都需要從 proxy 中轉(zhuǎn)一次，這個 proxyRole 是為了告訴 broker：只有使用了 proxyRole 作為 token 的 Proxy 才能訪問 broker，這樣保證了 broker 的安全。
superUserRoles: broker-admin,admin,proxy-admin proxyRoles: proxy-admin以上是我的配置，我的 Proxy 配置的也是 proxy-admin 這個 token，所以理論上是沒有問題的，但依然鑒權(quán)失敗了，查看 broker 的日志后拿到以下日志：
Illegal combination of role [proxy-admin] and originalPrincipal [proxy-admin]: originalPrincipal cannot be a proxy role.排查了許久依然沒有太多頭緒，所以我提了相關(guān)的 issue:https://github.com/apache/pulsar/issues/21583之后我咨詢了 Pulsar 的 PMC @Technoboy 在他的提示下發(fā)現(xiàn)我在測試的時候使用的是 proxy-admin，正好和 proxyRoles 相等。
圖片
閱讀源碼和這個 PR 的 comment 之后得知：
圖片
也就是說客戶端不能使用和 proxyRole 相同的角色進(jìn)行連接，這個角色應(yīng)當(dāng)也只能給 Proxy 使用，這樣的安全性才會高。
所以這個 Comment 還在討論這是一個 breaking change? 還是一個增強(qiáng)補(bǔ)丁。因?yàn)楹喜⑦@個 PR 后對沒有使用 proxyRole 的客戶端將無法連接，同時也可能出現(xiàn)我這種 proxyRole 就是客戶端使用的角色，這種情況也會鑒權(quán)失敗。
所以我換了一個 superRole 角色就可以了，比如換成了 admin。
但其實(shí)即便是放到我們的生產(chǎn)系統(tǒng)，只要配置了 proxyRole 也不會有問題，因?yàn)槲覀儜?yīng)用所使用的 role 都是不這里的 superUserRole，全部都是使用 AppId 生成的。
但也有一個疑惑，我在換為存放在 configmap 中的 admin token 之前(測試環(huán)境使用的是 helm 安裝集群，所以這些 token 都是存放在 configmap 中的)，
為了驗(yàn)證是否只要非 proxyRole 的 superRole 都可以使用，我就自己使用了私鑰重新生成了一個 admin 的 token。
bin/pulsar tokens create --private-key file:///pulsar/private/private.key --subject admin這樣生成的 token 也是可以使用的，但是我將 token 復(fù)制出來之后卻發(fā)現(xiàn) helm 生成的 token 與我用 pulsar 命令行生成的 token 并不相同。
為了搞清楚為什么 token 不同但鑒權(quán)依然可以通過的原因，之后我將 token decode之后知道了原因：
圖片
圖片
原來是 Header 不同從而導(dǎo)致最終的 token 不同，helm 生成的 token 中多了一個 typ 字段。
之后我檢查了 helm 安裝的流程，發(fā)現(xiàn)原來 helm 的腳本中使用的并不是 Java 的命令行工具：
${PULSARCTL_BIN} token create -a RS256 --private-key-file ${privatekeytmpfile} --subject ${role} 2&> ${tokentmpfile}這個 PULSARCTL_BIN 是一個由 Go 寫的命令行工具，我查看了其中的源碼，才知道 Go 的 JWT 工具會自帶一個 header。https://github.com/streamnative/pulsarctl
圖片
而 Java 是沒有這個邏輯的，但也只是加了 header，payload 的值都是相同的。這樣也就解釋了為什么 token 不同但確依然能使用的原因。
本文鏈接：http://www.www897cc.com/showinfo-26-31005-0.html升級到 Pulsar3.0 后深入了解 JWT 鑒權(quán)
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 深入理解CPU緩存一致性協(xié)議MESI（建議收藏）
下一篇： 聊聊接口最大并發(fā)處理數(shù)
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號