共用方式為

設定 MQTT 代理授權

  • 發行項

重要

此頁面包含使用 Kubernetes 部署指令清單來管理 Azure IoT Operations 元件的指示，其處於預覽狀態。 這項功能隨附 數個限制，不應用於生產工作負載。

請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。

授權原則會決定用戶端可以在訊息代理程式上執行的動作，例如連線、發佈或訂閱主題。 設定 MQTT 代理以使用一或多個授權原則搭配 BrokerAuthorization 資源。 每個 BrokerAuthorization 資源都包含一份規則清單，這些規則會指定授權原則的主體和資源。

若要將 BrokerListener 連結到 BrokerAuthorization 資源，請在 BrokerListener 資源的設定中ports指定 authorizationRef 字段。 類似於 BrokerAuthentication，BrokerAuthorization 資源可以連結至多個 BrokerListener 埠。 授權原則會套用至所有連結的接聽程式埠。 不過，與 BrokerAuthentication 相比，有一個主要差異：

重要

若要將 BrokerAuthorization 設定套用至接聽程式埠，至少必須有一個 BrokerAuthentication 連結到該接聽程式埠。

若要深入瞭解 BrokerListener，請參閱 BrokerListener 資源。

授權規則

若要設定授權，請在 Kubernetes 叢集中建立 BrokerAuthorization 資源。 下列各節提供如何為使用使用者名稱、屬性、X.509 憑證和 Kubernetes 服務帳戶令牌 （SAT） 的用戶端設定授權的範例。 如需可用設定的清單，請參閱 Broker 授權 API 參考。

下列範例示範如何使用使用者名稱和屬性建立 BrokerAuthorization 資源：

  1. 在 Azure 入口網站 中，流覽至您的IoT作業實例。

  2. 在 [Azure IoT 作業資源] 底下，選取 [MQTT 訊息代理程式]。

  3. 選取 [授權] 索引標籤。

  4. 選取 [建立授權原則]，選擇現有的驗證原則或建立新的 驗證原則。

    使用 Azure 入口網站 建立訊息代理程式授權規則的螢幕快照。

此訊息代理程式授權可讓用戶端具有用戶端標識碼temperature-sensor或 humidity-sensor，或具有具有 值且city具有 值 seattlecontoso 之屬性的organization用戶端，以執行下列動作：

  • 連線到訊息代理程式。
  • 將訊息發佈至以其用戶端標識碼和組織限定範圍的遙測主題。 例如：
    • temperature-sensor 可以發佈至 /telemetry/temperature-sensor 和 /telemetry/contoso。
    • humidity-sensor 可以發佈至 /telemetry/humidity-sensor 和 /telemetry/contoso。
    • some-other-username 可以發佈至 /telemetry/contoso。
  • 訂閱以其組織範圍設定的命令主題。 例如：
    • temperature-sensor 可以訂閱 /commands/contoso。
    • some-other-username 可以訂閱 /commands/contoso。

使用使用者名稱進行授權

若要使用 MQTT 使用者名稱進行授權，請將它們指定為 下的 principals.usernames陣列。 不過，視驗證方法而定，用戶名稱可能無法驗證：

  • Kubernetes SAT - 使用者名稱不應該用於授權，因為它未透過增強驗證來驗證 MQTTv5。
  • X.509 - 用戶名稱符合憑證中的 CN，而且可用於授權規則。
  • 自訂 - 只有在自訂驗證驗證使用者名稱時，使用者名稱才應該用於授權規則。

若要防止安全性問題，請只在驗證代理程式授權時使用 MQTT 用戶名稱。

根據客戶端識別元進一步限制存取

principals因為欄位是邏輯 OR，因此您可以藉由將clientIds欄位新增至欄位，進一步限制根據客戶端識別碼的brokerResources存取。 例如，若要允許具有用戶端標識符的用戶端，從其建置編號開始，將遙測連線併發佈至其建置範圍的主題，請使用下列組態：

在授權原則的訊息代理程式授權規則中，使用下列設定：

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

在此，如果未clientIds在 方法下Connect設定 ，只要用戶端標識元設定為 building22 或 building23屬性，任何用戶端標識符的用戶端就可以連線building。 藉由新增 clientIds 欄位，只有具有開頭 building22 或 building23 可以連線之用戶端標識碼的用戶端。 這可確保客戶端不僅具有正確的屬性，還能確保用戶端標識元符合預期的模式。

授權使用 X.509 驗證的用戶端

使用 X.509 憑證進行驗證的用戶端可以授權根據其憑證上存在的 X.509 屬性，或鏈結上的發行憑證來存取資源。

使用屬性

若要根據來自用戶端憑證、根 CA 或中繼 CA 的屬性來建立規則，請在 BrokerAuthorization 資源中定義 X.509 屬性。 如需詳細資訊，請參閱憑證屬性。

使用用戶端憑證主題一般名稱作為使用者名稱

若要根據用戶端憑證主體通用名稱 (CN) 建立授權原則，請根據 CN 建立規則。

例如，如果用戶端具有主體 CN = smart-lock 的憑證，則其使用者名稱為 smart-lock。 從該處，依正常方式建立授權原則。

授權使用 Kubernetes 服務帳戶權杖的用戶端

SAT 的授權屬性會設為服務帳戶註釋的一部分。 例如，若要新增名為 group 且值為 authz-sat 的授權屬性，請執行命令：

kubectl annotate serviceaccount mqtt-client aio-broker-auth/group=authz-sat

屬性註釋必須以 aio-broker-auth/ 開頭，才能區別於其他註釋。

由於應用程式具有稱為 authz-sat 的授權屬性，因此不需要提供 clientId 或 username。 對應的 BrokerAuthorization 資源會使用此屬性作為主體，例如：

在授權原則的 Broker 授權規則中，使用下列設定：

[
  {
    "brokerResources": [
      {
        "clientIds": [],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "odd-numbered-orders"
        ]
      },
      {
        "clientIds": [],
        "method": "Subscribe",
        "topics": [
          "orders"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "group": "authz-sat"
        }
      ]
    }
  }
]

若要深入了解範例，請參閱 使用 Dapr 用戶端設定授權原則。

狀態存放區

MQTT 訊息代理程式提供 狀態存放區 ，用戶端可用來儲存狀態。 狀態存放區也可以設定為高可用性。

若要為使用狀態存放區的用戶端設定授權，請提供下列許可權：

  • 發佈至系統金鑰值存放區 $services/statestore/_any_/command/invoke/request 主題的權限
  • 訂閱回應主題的權限 (在初始發佈期間設定為參數) <response_topic>/#

狀態存放區金鑰

狀態存放區是透過主題 statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke上的 MQTT 訊息代理程式存取。 由於用戶端可以存取主題，因此您可以在 MQTT 訊息代理程式brokerResources組態的 stateStoreResources 區段下指定金鑰和存取層級。

區 stateStoreResources 段格式包含存取層級、模式指標和模式。

在授權原則的規則中包含 區 stateStoreResources 段。

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

欄位 method 會指定存取層級。

  • 使用 指定 read讀取權限、使用 write寫入權限與兩 readwrite者搭配 。
  • 需要存取層級。
  • 讀取存取層級表示 和keynotify的get動作。
  • 寫入存取層級表示、 del和 vdel的set動作。

欄位 keyType 會指定索引鍵比對的類型。

  • pattern 使用 glob 樣式模式比對
  • string表示完全相符，例如當索引鍵包含可能以模式比對的字元時（*、 ?[0-9]、 ）
  • binary 以比對二進位索引鍵

欄位 keys 會指定要比對的索引鍵。 索引鍵可以指定為 Glob 樣式模式、令牌替代或確切字串。

  • Glob 樣式範例：
    • colors/*：“colors/” 前置詞下的所有索引鍵
    • number[0-9]：任何從 “number0” 到 “number9” 的索引鍵
    • char?：任何前置詞為 “char” 和單一數字後綴的索引鍵，例如 “charA”
    • *：所有金鑰的完整存取權。
  • 狀態存放區金鑰也支援金鑰類型為 pattern ，且大括號保留供此用途使用時，令牌替代。 權杖替代範例：
    • clients/{principal.clientId}/*
    • usernames/{principal.username}/*
    • rooms/{principal.attributes.room}/*

以下是如何撰寫狀態存放區資源的範例：

在授權原則的 Broker 授權規則中，新增類似的設定：

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect"
      },
      {
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry/*"
        ]
      },
      {
        "method": "Subscribe",
        "topics": [
          "commands/{principal.attributes.organization}"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "17",
          "organization": "contoso"
        }
      ],
      "usernames": [
        "temperature-sensor",
        "humidity-sensor"
      ]
    },
    "stateStoreResources": [
      {
        "method": "Read",
        "keyType": "Pattern",
        "keys": [
          "myreadkey",
          "myotherkey?",
          "mynumerickeysuffix[0-9]",
          "clients/{principal.clientId}/*"
        ]
      },
      {
        "method": "ReadWrite",
        "keyType": "Binary",
        "keys": [
          "xxxxxxxxxxxxxxxxxxxx"
        ]
      }
    ]
  }
]

更新授權

訊息代理程式授權資源可以在執行階段更新，而不需重新啟動。 在原則更新時連線的所有用戶端都會中斷連線。 變更原則類型也同樣支援。

kubectl edit brokerauthorization my-authz-policies

停用授權

  1. 在 Azure 入口網站 中，流覽至您的IoT作業實例。
  2. 在 [Azure IoT 作業資源] 底下，選取 [MQTT 訊息代理程式]。
  3. 從清單中選取您要編輯的訊息代理程式接聽程式。
  4. 在您要停用授權的埠上，選取 [授權] 下拉式清單中的 [無 ]。

MQTT 3.1.1 中未經授權的發佈

使用 MQTT 3.1.1 時，當發佈遭到拒絕時，用戶端會在沒有錯誤的情況下收到 PUBACK，因為通訊協定版本不支援傳回錯誤碼。 當發佈遭到拒絕時，MQTTv5 會傳回原因代碼 135 (未授權) 的 PUBACK。

相關內容