背景

最近在測試將 Pulsar 2.11.2 升級到 3.0.1的過程中碰到一個鑒權問題，正好借著這個問題充分了解下 Pulsar 的鑒權機制是如何運轉的。

Pulsar 支持 Namespace/Topic 級別的鑒權，在生產環境中往往會使用 topic 級別的鑒權，從而防止消息泄露或者其他因為權限管控不嚴格而導致的問題。

我們會在創建 topic 的時候為 topic 綁定一個應用，這樣就只能由這個應用發送消息，其他的應用嘗試發送消息的時候會遇到 401 鑒權的異常。

同理，對于訂閱者也可以關聯指定的應用，從而使得只有規定的應用可以消費消息。

鑒權流程

以上的兩個功能本質上都是通過 Pulsar 的 admin-API 實現的。

這里關鍵的就是 role，在我們的場景下通常是一個應用的 AppId，只要是一個和項目唯一綁定的 ID 即可。

這只是授權的一步，整個鑒權流程圖如下：

詳細步驟

生成公私鑰

bin/pulsar tokens create-key-pair --output-private-key my-private.key --output-public-key my-public.key

將公鑰分發到 broker 的節點上，鑒權的時候 broker 會使用公鑰進行驗證。

而私鑰通常是管理員單獨保存起來用于在后續的步驟為客戶端生成 token

使用私鑰生成 token

之后我們便可以使用這個私鑰生成 token 了：

bin/pulsar tokens create --private-key file:///path/to/my-private.key \
            --subject 123456

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJhZG1pbiJ9

其中的 subject 和本文長提到的 role 相等

使用 subject 授權

只是單純生成了 token 其實并沒有什么作用，還得將 subject(role) 與 topic 進行授權綁定。

也就是上圖的這個步驟。

這里創建的 admin 客戶端也得使用一個 superRole 角色的 token 才有權限進行授權。
superRole 使用在 broker.conf 中進行配置。

客戶端使用 token 接入 broker

PulsarClient client = PulsarClient.builder()
    .serviceUrl("pulsar://broker.example.com:6650/")
    .authentication(AuthenticationFactory.token("eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJKb2UifQ.ipevRNuRP6HflG8cFKnmUPtypruRC4fb1DWtoLL62SY")）
    .build();

使用剛才私鑰生成的 token 接入 broker 才能生產或者消費數據。

originalPrincipal cannot be a proxy role

這些流程正常都沒啥問題，但直到我升級了 Pulsar3.0 后客戶端直接就連不上了。

在 broker 中看到了 WARN 的警告日志：

cannot specify originalPrincipal when connecting without valid proxy role

之后在 3.0 的升級日志中看到相關的 Issue。

從這個 PR 相關的代碼和變更的文檔可以得知：

升級到 3.0 之后風險校驗等級提高了，proxyRole 這個字段需要在 broker 中進行指定（之前的版本不需要強制填寫）。

因為我們使用了 Proxy 組件，所有的請求都需要從 proxy 中轉一次，這個 proxyRole 是為了告訴 broker：只有使用了 proxyRole 作為 token 的 Proxy 才能訪問 broker，這樣保證了 broker 的安全。

superUserRoles: broker-admin,admin,proxy-admin 
proxyRoles: proxy-admin

以上是我的配置，我的 Proxy 配置的也是 proxy-admin 這個 token，所以理論上是沒有問題的，但依然鑒權失敗了，查看 broker 的日志后拿到以下日志：

Illegal combination of role [proxy-admin] and originalPrincipal [proxy-admin]: originalPrincipal cannot be a proxy role.

排查了許久依然沒有太多頭緒，所以我提了相關的 issue:
https://github.com/apache/pulsar/issues/21583
之后我咨詢了 Pulsar 的 PMC @Technoboy 在他的提示下發現我在測試的時候使用的是 proxy-admin，正好和 proxyRoles 相等。

閱讀源碼和這個 PR 的 comment 之后得知：

也就是說客戶端不能使用和 proxyRole 相同的角色進行連接，這個角色應當也只能給 Proxy 使用，這樣的安全性才會高。

所以這個 Comment 還在討論這是一個 breaking change? 還是一個增強補丁。
因為合并這個 PR 后對沒有使用 proxyRole 的客戶端將無法連接，同時也可能出現我這種 proxyRole 就是客戶端使用的角色，這種情況也會鑒權失敗。

所以我換了一個 superRole 角色就可以了，比如換成了 admin。

但其實即便是放到我們的生產系統，只要配置了 proxyRole 也不會有問題，因為我們應用所使用的 role 都是不這里的 superUserRole，全部都是使用 AppId 生成的。

token 不一致

但也有一個疑惑，我在換為存放在 configmap 中的 admin token 之前(測試環境使用的是 helm 安裝集群，所以這些 token 都是存放在 configmap 中的)，

為了驗證是否只要非 proxyRole 的 superRole 都可以使用，我就自己使用了私鑰重新生成了一個 admin 的 token。

bin/pulsar tokens create --private-key file:///pulsar/private/private.key --subject admin

這樣生成的 token 也是可以使用的，但是我將 token 復制出來之后卻發現 helm 生成的 token 與我用 pulsar 命令行生成的 token 并不相同。

為了搞清楚為什么 token 不同但鑒權依然可以通過的原因，之后我將 token decode之后知道了原因：


原來是 Header 不同從而導致最終的 token 不同，helm 生成的 token 中多了一個 typ 字段。

---

之后我檢查了 helm 安裝的流程，發現原來 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 不同但確依然能使用的原因。

總結

以上是生活随笔為你收集整理的升级到 Pulsar3.0 后深入了解 JWT 鉴权的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。