RabbitMQ權限控制原理

咱們在使用MQ搭建系統的時候，常常要開放隊列給外接系統訪問。外接系統的穩定性是不可控的。爲了防止外接系統不穩定致使誤操做破壞了MQ的配置或數據，須要對MQ作比較精細的權限控制。

個人需求是這樣的：

我有一個數據查詢服務，而且經過MQ推送數據變更消息。對接MQ的每一個系統都會有本身一個獨立的隊列來讀取消息。全部消息經過一個扇形交換機廣播到全部隊列。我須要這個交換機和全部隊列都由管理員統一建立好。而其餘系統使用的用戶，均沒有建立交換機和隊列的權限。數據查詢服務只擁有推送消息的權限，其餘對接MQ的系統只擁有從本身隊列讀取消息的權限。

咱們使用的MQ是RabbitMQ。我在網上搜了一下，大部分講的是用戶角色配置。對於MQ的資源受權管理講的比較少。如下內容將主要講解 RabbitMQ權限控制的基本概念和模型 。理解了這些基本概念後，應該能夠愉快地使用RabbitMQ管理界面進行受權操做。若是大家只有命令行可用，也能很輕鬆地找到相應的命令。

RabbitMQ初始化

RabbitMQ初次啓動時，初始建立這兩個東西：

/
/

RabbitMQ受權模型

第一級控權單位是virtual host，virtual host下面第二級的控權單位是resource（包含exchange和queue）。兩個相同名稱的resource若是分屬不一樣的virtual host，則算是不一樣的resource。

什麼是virtual host：

RabbitMQ is multi-tenant system: connections, exchanges, queues, bindings, user permissions, policies and some other things belong to virtual hosts, logical groups of entities.

就是說RabbitMQ是多租戶系統，簡單理解就是把多virtual host當作多個MQ系統來用就行了……

當用戶訪問MQ時，首先觸發 第一級控權，判斷用戶是否有訪問該virtual host的權限 。

若可訪問，則進行 第二級控權，判斷用戶是否具備操做（operation）所請求的資源的權限 。

RabbitMQ定義了操做（operation）有這麼三種：

• configure：主要對應建立exchange和queue操做；
• write：write主要對應綁定和推送消息操做；
• read：read主要對應讀取消息操做。

後面有個表格列出了具體的對應關係。

當管理員對一個用戶進行受權時，要配置兩個元素：

1. 容許什麼操做，即configure、write、read三種operation；
2. 操做什麼resource。用戶是否擁有某資源的權限，經過對該資源的名稱與受權時配置的正則進行匹配來判斷。

下面這張表詳細描述了operation、resource和用戶可執行的操做的關係：

例子：

• 若是要給用戶受權能夠往exchange foo 推消息，則咱們找到basic.publish這行，格子不是空的只有write這列，因此咱們須要給用戶受權一個write權限，其正則能夠匹配字符串 foo （好比說 ^foo$ ，或者 .* 等）。
• 若是要給用戶受權只能從queue bar 讀取消息，則須要給用戶受權一個read權限，其正則能夠匹配字符串 bar 。