Azure IoT MQ プレビュー認可を構成する

重要

Azure Arc によって有効にされる Azure IoT Operations Preview は、 現在プレビュー段階です。 運用環境ではこのプレビュー ソフトウェアを使わないでください。

ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

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

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

重要

BrokerAuthorization 構成をリスナーに適用するには、少なくとも 1 つの BrokerAuthentication もそのリスナーにリンクされている必要があります。

リスナーの BrokerAuthorization を構成する

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

フィールド名	必須	説明
listenerRef	はい	この認可ポリシーが適用される BrokerListener リソースの名前。 このフィールドは必須であり、同じ名前空間内の既存の BrokerListener リソースと一致する必要があります。
authorizationPolicies	はい	このフィールドは、enableCache や rules などの認可ポリシーの設定を定義します。
enableCache	いいえ	認可ポリシーでキャッシュを有効にするかどうか。 true に設定すると、ブローカーはパフォーマンスを向上させ、待機時間を短縮するために、クライアントとトピックの組み合わせごとに認可結果をキャッシュします。 false に設定すると、ブローカーはクライアントとトピックの要求ごとに認可ポリシーを評価し、一貫性と正確性を確保します。 このフィールドは省略可能で、既定値は false です。
ルール	いいえ	認可ポリシーのプリンシパルとリソースを指定する規則の一覧。 各ルールには、principals と brokerResources というサブフィールドがあります。
principal	はい	このサブフィールドは、usernames、clientids、attributes など、クライアントを表す ID を定義します。
usernames	いいえ	クライアントと一致するユーザー名の一覧。 ユーザー名は大文字と小文字の区別があり、認証時にクライアントによって提供されるユーザー名と一致する必要があります。
clientids	いいえ	クライアントと一致するクライアント ID の一覧。 クライアント ID は、大文字と小文字の区別があり、接続時にクライアントによって提供されるクライアント ID と一致する必要があります。
属性	いいえ	クライアントの属性と一致するキーと値のペアのリスト。 属性は大文字と小文字の区別があり、認証時にクライアントによって提供される属性と一致する必要があります。
brokerResources	はい	このサブフィールドは、method や topics など、アクションまたはトピックを表すオブジェクトを定義します。
method	はい	クライアントがブローカーに対して実行できるアクションの種類。 このサブフィールドは必須であり、次の値のいずれかにできます。Connect: この値は、クライアントがブローカーに接続できることを示します。 Publish: この値は、クライアントがブローカーのトピックにメッセージを発行できることを示します。 Subscribe: この値は、クライアントがブローカーのトピックにサブスクライブできることを示します。
topics	いいえ	クライアントが発行またはサブスクライブできるトピックに一致するトピックまたはトピック パターンのリスト。 このサブフィールドは、メソッドが Subscribe または Publish の場合に必須です。

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

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "my-listener" # change to match your listener name as needed
  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 のプロパティに基づいてルールを作成するには、証明書から属性へのマッピング TOML ファイルが必要です。 次に例を示します。

[root]
subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"

[root.attributes]
organization = "contoso"

[intermediate]
subject = "CN = Contoso Intermediate CA"

[intermediate.attributes]
city = "seattle"
foo = "bar"

[smart-fan]
subject = "CN = smart-fan"

[smart-fan.attributes]
building = "17"

この例では、ルート CA CN = Contoso Root CA Cert, OU = Engineering, C = US または中間 CA CN = Contoso Intermediate CA によって発行された証明書を持つすべてのクライアントが、リストされている属性を受け取ります。 さらに、スマート ファンはそれに固有の属性を受け取ります。

属性の照合は、常にリーフ クライアント証明書から始まり、チェーンに沿って進みます。 属性の割り当ては、最初の一致後に停止します。 前の例では、smart-fan に中間証明書 CN = Contoso Intermediate CA がある場合でも、関連付けられている属性は取得されません。

マッピングを適用するには、証明書から属性へのマッピング TOML ファイルを Kubernetes シークレットとして作成し、BrokerAuthentication リソースの authenticationMethods.x509.attributes で参照します。

その後、これらの属性を持つ 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: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "az-mqtt-non-tls-listener"
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"                                       

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

分散状態ストア

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

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

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

認可を更新する

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

kubectl edit brokerauthorization my-authz-policies

認可を無効にする

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

apiVersion: mq.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 を構成する