MQTT ブローカー認可を構成する

認可ポリシーは、クライアントがブローカーに対して実行できるアクション (トピックへの接続、パブリッシュ、サブスクライブなど) を決定します。 BrokerAuthorization リソースを使用して 1 つまたは複数の認可ポリシーを使用するように MQTT ブローカーを構成します。

リスナーごとに 1 つの BrokerAuthorization に設定できます。 各 BrokerAuthorization リソースには、認可ポリシーのプリンシパルとリソースを指定する規則のリストが含まれています。

リスナーの BrokerAuthorization を構成する

BrokerAuthorization リソースの仕様には、次のフィールドがあります。

次の例では、my-listener という名前のリスナーの認可ポリシーを定義する BrokerAuthorization リソースを作成する方法を示します。

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    enableCache: true
    rules:
      - principals:
          usernames:
            - temperature-sensor
            - humidity-sensor
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.username}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

このブローカー認可を使用すると、ユーザー名 temperature-sensor または humidity-sensor のクライアント、または値が contoso の属性 organization および値が seattle の属性 city を持つクライアントは、次の操作を実行できます。

• ブローカーに接続する。
• ユーザー名と組織をスコープとした telemetry トピックにメッセージを発行する。 例:
  • temperature-sensor は、/telemetry/temperature-sensor および /telemetry/contoso に発行できます。
  • humidity-sensor は、/telemetry/humidity-sensor および /telemetry/contoso に発行できます。
  • some-other-username は、/telemetry/contoso に発行できます。
• 組織をスコープとした commands トピックをサブスクライブする。 例:
  • temperature-sensor は、/commands/contoso をサブスクライブできます。
  • some-other-username は、/commands/contoso をサブスクライブできます。

この BrokerAuthorization リソースを作成するには、YAML マニフェストを Kubernetes クラスターに適用します。

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-mq-broker-auth/group=authz-sat

属性の注釈は、他の注釈と区別するために、aio-mq-broker-auth/ で始まる必要があります。

アプリケーションには authz-sat という名前の認可属性があるため、clientId や username を指定する必要はありません。 対応する BrokerAuthorization リソースでは、この属性がプリンシパルとして使用されます。次に例を示します。

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"                                       

例の詳細については、「Dapr クライアントを使用して認可ポリシーを設定する」を参照してください。

分散状態ストア

MQTT ブローカーは、クライアントが状態を格納するために使用できる分散状態ストア (DSS) を提供します。 可用性が高くなるように DSS を構成することもできます。

DSS を使用するクライアントの認可を設定するには、次のアクセス許可を指定します。

• システム キー値ストア $services/statestore/_any_/command/invoke/request トピックに発行するためのアクセス許可
• 応答トピック (パラメーターとして最初の発行時に設定される) <response_topic>/# をサブスクライブするためのアクセス許可

DSS 認可についての詳細は、状態ストア キーに関するセクションを参照してください。

認可を更新する

ブローカー認可リソースは、再起動せずに実行時に更新できます。 ポリシーの更新時に接続されているすべてのクライアントは切断されます。 ポリシーの種類の変更もサポートされています。

kubectl edit brokerauthorization my-authz-policies

認可を無効にする

認可を無効にするには、BrokerListener リソースに authorizationEnabled: false を設定します。 すべてのクライアントを許可するようにポリシーが設定されている場合、すべての認証済みクライアントがすべての操作にアクセスできます。

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: "my-listener"
  namespace: azure-iot-operations
spec:
  brokerRef: "my-broker"
  authenticationEnabled: false
  authorizationEnabled: false
  port: 1883

MQTT 3.1.1 での未承認の発行

MQTT 3.1.1 では、発行が拒否されると、このプロトコル バージョンではエラー コードを返すことがサポートされていないため、クライアントはエラーなしで PUBACK を受け取ります。 MQTTv5 では、発行が拒否されると理由コード 135 (未承認) で PUBACK が返されます。

関連するコンテンツ

• BrokerListener リソースについて
• BrokerListener の認証を構成する
• 手動証明書管理を使用して TLS を構成する
• 自動証明書管理を使用して TLS を構成する