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

重要

このページには、プレビュー段階にある Kubernetes デプロイ マニフェストを使用して Azure IoT Operations コンポーネントを管理する手順が含まれます。 この機能はいくつかの制限を設けて提供されており、運用環境のワークロードには使用しないでください。

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

MQTT ブローカーでは、クライアントの複数の認証方法がサポートされています。 リスナー ポートごとに、BrokerAuthentication リソースに関する固有の認証設定を構成できます。 使用可能な設定の一覧については、Broker Authentication API リファレンスを参照してください。

BrokerListener と BrokerAuthentication のリンク

BrokerListener と BrokerAuthentication リソースの関係には、次のルールが適用されます。

• 各 BrokerListener リソースには複数のポートを含めることができます。 各ポートを BrokerAuthentication リソースにリンクできます。
• 各 BrokerAuthentication リソースは、一度に複数の認証方法をサポートできます。
• BrokerAuthentication リソースをリンクしないポートでは認証が無効になっています。

BrokerListener ポートを BrokerAuthentication リソースにリンクするには、BrokerListener リソースの ports の設定で authenticationRef フィールドを指定します。 詳細については、BrokerListener リソースに関するページを参照してください。

既定の BrokerAuthentication リソース

Azure IoT Operations は、azure-iot-operations 名前空間の "既定の" リスナーとリンクされた default という名前の既定の BrokerAuthentication リソースをデプロイします。 これは、認証に Kubernetes サービス アカウント トークン (SAT) のみを使います。

重要

IoT Operations のコンポーネントが正常に機能するには、既定の BrokerAuthentication リソースでの SAT 認証方法が必要です。 既定の BrokerAuthentication リソースを更新または削除しないでください。

ポータル

1. Azure portal で、IoT Operations インスタンスに移動します。

2. [コンポーネント] で、[MQTT ブローカー] を選択します。

3. 認証 タブを選択します。

4. 認証ポリシーの一覧から、[default] ポリシー名を選びます。

   

新しい認証方法を追加するには、[方法の追加] を選択します。

Bicep

既定のエンドポイントを編集するには、次の内容を含む Bicep .bicep ファイルを作成します。 必要に応じて設定を更新します。 <AIO_INSTANCE_NAME> などのプレースホルダーの値は、実際のものに置き換えます。

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
          ]
        }
      }
    ]
  }
}

Azure CLI を使用して Bicep ファイルをデプロイします。

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (プレビュー)

既定のブローカー認証リソースを検査するには、次を実行します。

kubectl get brokerauthentication default -n azure-iot-operations -o yaml

出力には、簡潔にするためにメタデータが除外された既定の BrokerAuthentication リソースが示されます。

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - aio-internal

変更する必要がある場合は、aio-internal 対象ユーザーでの SAT 認証方法をそのままにして、このリソースの authenticationMethods フィールドを変更します。 次に、kubectl apply を使ってそれをデプロイします。

Authentication flow

指定されている認証方法の順序により、MQTT ブローカーでのクライアントの認証方法が決まります。 MQTT ブローカーは、指定されている最初の方法を使ってクライアントの資格情報の認証を試み、一致するものが見つかるか、最後のものに達するまで、指定されている方法を繰り返します。

方法ごとに、MQTT ブローカーは最初にクライアントの資格情報がその方法に "該当する" かどうかを調べます。 たとえば、SAT 認証では K8S-SAT から始まるユーザー名が必要であり、X.509 認証ではクライアント証明書が必要です。 クライアントの資格情報が該当する場合、MQTT ブローカーは次にそれが有効かどうかを検証します。 詳しくは、認証方法の構成に関するセクションをご覧ください。

カスタム認証の場合、MQTT ブローカーはカスタム認証サーバーとの通信エラーを "資格情報が該当しない" として扱います。 この動作により、MQTT ブローカーはカスタム認証サーバーに到達できない場合、他の方法にフォールバックします。

認証フローは、次の場合に終了します。

• 以下のいずれかの条件が満たされている場合。
  • クライアントの資格情報が以下のいずれかのメソッドに対して該当し、有効である場合。
  • クライアントの資格情報がいずれのメソッドにも該当しない場合。
  • クライアントの資格情報が以下のいずれかのメソッドに対して該当するが、無効である場合。
• MQTT ブローカーは、認証フローの結果に基づいて、クライアントへのアクセスを許可または拒否します。

次に例を示します。

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

前の例では、custom と SAT が指定されています。 クライアントが接続すると、MQTT ブローカーは、指定されている方法を custom、SAT の順番で使って、クライアントの認証を試みます。

1. MQTT ブローカーは、クライアントの資格情報がカスタム認証に対して有効かどうかをチェックします。 カスタム認証では資格情報の有効性の判断に外部サーバーが利用されるため、ブローカーはすべての資格情報をカスタム認証に該当するものと見なして、カスタム認証サーバーに転送します。
2. カスタム認証サーバーから応答として結果 Pass または Fail が返された場合、認証フローは終了します。 カスタム認証サーバーが使用できない場合、MQTT ブローカーは指定されている残りの方法にフォールバックします。ここでは SAT が次の方法です。
3. MQTT ブローカーは、SAT 資格情報として資格情報の認証を試みます。

カスタム認証サーバーが使用できず、その後のすべての方法で、提供された資格情報が該当しないと判断された場合、ブローカーはクライアントの接続を拒否します。

認証方法を構成する

認証ポリシーに X.509、SAT、カスタムなどの認証方法を追加できます。

ポリシーに認証方法を追加するには:

ポータル

1. Azure portal で、IoT Operations インスタンスに移動します。

2. [コンポーネント] で、[MQTT ブローカー] を選択します。

3. 認証 タブを選択します。

4. 既存の認証ポリシーを選択するか、新しい認証ポリシーを作成します。

5. [方法の追加] を選択して、新しい方法を追加します。

6. ドロップダウン リストから方法の種類を選び、[詳細の追加] を選んで方法を構成します。

   

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        customSettings: {
          endpoint: 'https://auth-server-template'
          caCertConfigMap: 'custom-auth-ca'
          auth: {
            x509: {
              secretRef: 'custom-auth-client-cert'
            }
          }
          headers: {
            header_key: 'header_value'
          }
        }
      }
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: 'client-ca'
          authorizationAttributes: {
            root: {
              attributes: {
                organization: 'contoso'
              }
              subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
            }
            intermediate: {
              attributes: {
                city: 'seattle'
                foo: 'bar'
              }
              subject: 'CN = Contoso Intermediate CA'
            }
            smartfan: {
              attributes: {
                building: '17'
              }
              subject: 'CN = smart-fan'
            }
          }
        }
      }
    ]
  }
}

Azure CLI を使用して Bicep ファイルをデプロイします。

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (プレビュー)

authenticationMethods セクションに新しい方法を追加して、認証ポリシーの BrokerAuthentication リソースを変更します。 次の例は、BrokerAuthentication リソースの複数の認証方法を示しています。

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: my-policy
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: Custom
    customSettings:
      endpoint: https://auth-server-template
      caCertConfigMap: custom-auth-ca
      auth:
        x509:
          secretRef: custom-auth-client-cert
      headers:
        header_key: header_value
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience
    - method: X509
      x509Settings:
        trustedClientCaCert: client-ca
        authorizationAttributes:
          root:
            attributes:
              organization: contoso
            subject: CN = Contoso Root CA Cert, OU = Engineering, C = US
          intermediate:
            attributes:
              city: seattle
              foo: bar
            subject: CN = Contoso Intermediate CA
          smart-fan:
            attributes:
              building: "17"
            subject: CN = smart-fan

構成を変更するには、この BrokerAuthentication リソースの authenticationMethods の設定を変更します。 その後、kubectl apply を使ってそれをデプロイします。

各認証オプションの詳細については、次のセクションの各メソッドを参照してください。

Azure Key Vault インスタンスを構成し、ワークロード ID を有効にして、セキュリティ保護された設定を有効にする方法について詳しくは、Azure IoT Operations のデプロイでのセキュリティ保護された設定の有効化に関する記事をご覧ください。

X.509

ヒント

X.509 認証を構成する方法のエンド ツー エンドの例については、TLS、X.509 クライアント認証、属性ベースのアクセス制御 (ABAC) 認可に関するチュートリアルを参照してください。

X.509 認証では、MQTT ブローカーは "信頼された証明機関 (CA) 証明書" を使ってクライアント証明書を検証します。 この信頼された CA は、ルートまたは中間 CA でもかまいません。 ブローカーは、クライアント証明書チェーンを信頼された CA 証明書と照合します。 このチェーンが有効な場合、クライアントは認証されます。

信頼された CA 証明書で X.509 認証を使うには、次の要件を満たしている必要があります。

• トランスポート層セキュリティ (TLS) プロトコル: X.509 は TLS クライアント証明書に依存しているため、X.509 認証を使用するポートで TLS が有効になっている必要があります。
• キー アルゴリズム: EC キーと RSA キーの両方がサポートされていますが、チェーン内のすべての証明書で同じキー アルゴリズムを使用する必要があります。
• 形式: CA 証明書は Privacy Enhanced Mail (PEM) 形式である必要があります。

ヒント

PEM 形式は、証明書とキーの一般的な形式です。 PEM ファイルは、-----BEGIN CERTIFICATE----- や -----BEGIN EC PRIVATE KEY----- などのヘッダーを持つ、Base64 でエンコードされた ASCII ファイルです。

別の形式の証明書がある場合は、OpenSSL を使ってそれを PEM に変換できます。 詳しくは、適切な形式への証明書の変換に関するページをご覧ください。

信頼された CA 証明書を取得する

運用セットアップでは、CA 証明書は、組織の公開キー基盤 (PKI) または公的証明機関によって提供されます。

テストのために、OpenSSL を使用して自己署名 CA 証明書を作成します。 たとえば、次のコマンドを実行して、RSA キー、識別名 CN=Contoso Root CA Cert、365 日の有効性を持つ自己署名 CA 証明書を生成します。

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

証明書を管理するための便利なツールである Step CLI での同じコマンドは次のとおりです。

step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
 --not-after 8760h

これらのコマンドによって、CA 証明書 ca.pem と秘密キー ca-key.pem が PEM 形式で作成されます。 CA 証明書 ca.pem は、X.509 認証のために MQTT ブローカーにインポートできます。

信頼された CA 証明書をインポートする

X.509 認証を開始するには、信頼された CA 証明書を azure-iot-operations 名前空間内の ConfigMap にインポートします。 信頼された CA 証明書 ca.pem を client-ca という名前の ConfigMap にインポートするには、次のコマンドを実行します。

kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations

この例では、CA 証明書はキー ca.pem の下にインポートされます。 MQTT ブローカーは ConfigMap 内のすべての CA 証明書を信頼するため、キーの名前は何でもかまいません。

ルート CA 証明書が正常にインポートされたことを調べるには、kubectl describe configmap を実行します。 結果では、PEM 証明書ファイルの同じ Base64 エンコードが示されます。

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----


BinaryData
====

X.509 認証方法を構成する

信頼された CA 証明書がインポートされた後、それを認証方法として BrokerAuthentication リソースに追加して、X.509 クライアント認証を有効にします。 TLS が有効なリスナー ポートにこのリソースがリンクされていることを確認します。

ポータル

1. Azure portal で、IoT Operations インスタンスに移動します。

2. [コンポーネント] で、[MQTT ブローカー] を選択します。

3. 認証 タブを選択します。

4. 既存の認証ポリシーを選択するか、新しい認証ポリシーを作成します。

5. [方法の追加] を選択して、新しい方法を追加します。

6. 方法の種類のドロップダウン リストから [X.509] を選びます。 次に、[詳細の追加] を選んで方法を構成します。

7. [X.509 認証の詳細] ペインで、JSON 形式を使って信頼された CA 証明書の ConfigMap 名を指定します。

   {
       "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
   }
   

   <TRUSTED_CA_CONFIGMAP> を、信頼された CA 証明書を含む ConfigMap の名前に置き換えます。 たとえば、 "trustedClientCaCert": "client-ca"を使用します。

   

8. 必要に応じて、X.509 証明書を使ってクライアントの認可属性を追加します。 詳細については、「認可のための証明書属性」を参照してください。

9. 適用を選択して、変更を保存します。

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'
param trustedCaConfigMap string = '<TRUSTED_CA_CONFIGMAP>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: trustedCaConfigMap
          // authorizationAttributes: {
            //// Optional authorization attributes
            //// See the next section for more information
          // }
        }
      }
    ]
  }
}

<TRUSTED_CA_CONFIGMAP> を、信頼された CA 証明書を含む ConfigMap の名前に置き換えます。 たとえば、 client-caを使用します。

Azure CLI を使用して Bicep ファイルをデプロイします。

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (プレビュー)

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
        # authorizationAttributes:
          ## Optional authorization attributes
          ## See the next section for more information

<TRUSTED_CA_CONFIGMAP> を、信頼された CA 証明書を含む ConfigMap の名前に置き換えます。 たとえば、 client-caを使用します。

省略可能: 認可のための証明書属性

証明書のプロパティに基づいてクライアントを認可するための BrokerAuthentication リソースで、X.509 の属性を指定できます。 属性は authorizationAttributes フィールドで定義されます。

次に例を示します。

ポータル

Azure portal で X.509 認証方法を構成するときに、[X.509 認証の詳細] ペインで認可属性を JSON 形式で追加します。

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "authorizationAttributes": {
    "root": {
      "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
      "attributes": {
        "organization": "contoso"
      }
    },
    "intermediate": {
      "subject": "CN = Contoso Intermediate CA",
      "attributes": {
        "city": "seattle",
        "foo": "bar"
      }
    },
    "smartfan": {
      "subject": "CN = smart-fan",
      "attributes": {
        "building": "17"
      }
    }
  }
}

Bicep

x509Settings: {
  trustedClientCaCert: '<TRUSTED_CA_CONFIGMAP>'
  authorizationAttributes: {
    root: {
      subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
      attributes: {
        organization: 'contoso'
      }
    }
    intermediate: {
      subject: 'CN = Contoso Intermediate CA'
      attributes: {
        city: 'seattle'
        foo: 'bar'
      }
    }
    smartfan: {
      subject: 'CN = smart-fan'
      attributes: {
        building: '17'
      }
    }
  }
}

Kubernetes (プレビュー)

x509Settings:
  trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
  authorizationAttributes:
    root:
      subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"
      attributes:
        organization = contoso
    intermediate:
      subject = "CN = Contoso Intermediate CA"
      attributes:
        city = seattle
        foo = bar
    smart-fan:
      subject = "CN = smart-fan"
      attributes:
        building = 17

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

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

これらの属性を持つ X.509 証明書を使って、認可規則をクライアントに適用できます。 署は、「X.509 認証を使用するクライアントを承認する」を参照してください。

リスナー ポートの X.509 認証を有効にする

信頼された CA 証明書をインポートし、BrokerAuthentication リソースを構成した後、それを TLS が有効なリスナー ポートにリンクします。 X.509 認証はクライアント証明書の検証を TLS に依存しているため、この手順は重要です。

TLS 対応リスナー ポートを取得するには、「ポートの TLS 手動証明書管理を有効にする」およびポートの TLS 自動証明書管理を有効にするを参照してください。

Note

ブローカー リスナー ポートで TLS を有効にすると、そのブローカーは TLS 暗号化にサーバー証明書を使うようになります。 クライアントはこのポートに接続する場合、自身の信頼ストア内に署名した CA 証明書を保持することによって、そのサーバー証明書を信頼する必要があります。 このプロセスは、"信頼配布" または "信頼バンドル" と呼ばれます。 クライアント検証とサーバー検証の次の違いを理解することが重要です。

• クライアント検証: MQTT ブローカー (サーバー) は、クライアント証明書を、X.509 クライアント認証の trustedClientCaCert フィールドで指定されている信頼された CA 証明書と照合します。
• サーバー検証: クライアント (Mosquitto や MQTTX など) は、MQTT ブローカーのサーバー証明書を、自分の信頼ストア内の信頼された CA 証明書と照合します。 Mosquitto クライアントの場合は、--cafile パラメーターを使って CA 証明書ファイルを指定します。 MQTTX の場合は、設定内の信頼ストアに CA 証明書を追加します。

X.509 認証を有効にした後、クライアントの信頼ストアに "サーバー側" CA 証明書を格納して、クライアントがブローカーのサーバー証明書を信頼するようにします。 "サーバー側" CA 証明書の信頼を、trustedClientCaCert フィールドで指定されているクライアント認証に使われる "クライアント側" CA 証明書と混同しないでください。

完全な例については、TLS、X.509 クライアント認証、属性ベースのアクセス制御 (ABAC) 認可に関するチュートリアルを参照してください。

X.509 クライアント証明書を使用して Mosquitto クライアントを MQTT ブローカーに接続する

Mosquitto のようなクライアントが、TLS と X.509 クライアント認証を使って MQTT ブローカーに接続できるようにするには、2 つのファイルが必要です。

• --cert パラメータは、クライアント証明書 PEM ファイルを指定します。 このファイルには、MQTT ブローカーが完全な証明書チェーンを構築するのに役立つ中間証明書も含める必要があります。
• --key パラメータは、クライアント秘密キー PEM ファイルを指定します。

MQTT ブローカーが自己署名 CA 証明書を使って TLS サーバー証明書を発行する場合は、--cafile パラメーターが必要です。 このファイルには、TLS 経由で接続するときに Mosquitto クライアントがブローカーのサーバー証明書を検証するために使う CA 証明書 ("信頼バンドル" とも呼ばれます) が含まれています。 MQTT ブローカーのサーバー証明書の発行者がシステム ルート ストア (既知のパブリック CA など) の一部である場合は、--cafile パラメーターを省略できます。

次に例を示します。

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem

MQTT ブローカー X.509 クライアント認証フローを理解する

クライアント認証の場合は、次の手順のようにします。

1. X.509 クライアント認証が有効になっている場合、接続するクライアントは、クライアント証明書と、MQTT ブローカーが構成されている信頼された証明書の 1 つをルートとする証明書チェーンを構築できるようにする中間証明書を、提示する必要があります。
2. ロード バランサーにより、通信がいずれかのフロントエンド ブローカーに送られます。
3. フロントエンド ブローカーは、クライアント証明書を受け取った後、構成されている証明書の 1 つをルートとする証明書チェーンの構築を試みます。 フロントエンド ブローカーによってチェーンが正常に構築され、提示されたチェーンが検証されると、TLS ハンドシェイクが完了します。 接続しているクライアントは、作成した TLS チャネルを通じて MQTT パケットをフロントエンドに送信できます。
4. TLS チャネルは開かれていますが、クライアントの認証または認可はまだ完了していません。
5. その後、クライアントは CONNECT パケットを MQTT ブローカーに送信します。
6. CONNECT パケットはフロントエンドにもう一度ルートされます。
7. フロントエンドでは、CONNECT パケットからの認証データや、TLS ハンドシェイク中に提供されたクライアント証明書チェーンなど、クライアントがこれまでに提供したすべての資格情報を収集します。
8. フロントエンドにより、これらの資格情報が認証サービスに送信されます。 認証サービスにより、証明書チェーンがもう一度チェックされ、チェーン内のすべての証明書のサブジェクト名が収集されます。
9. 認証サービスは、構成済みの認可規則を使って、接続しているクライアントが持つ属性を判断します。 これらの属性により、CONNECT パケット自体を含め、クライアントが実行できる操作が決まります。
10. 認証サービスが決定をフロントエンド ブローカーに返します。
11. フロントエンド ブローカーにより、クライアント属性と、接続が許可されているかどうかが認識されます。 その場合、MQTT 接続が完了し、クライアントは認可規則によって定められた通りに MQTT パケットの送受信を続行できます。

Kubernetes サービス アカウント トークン

Kubernetes SAT は、Kubernetes サービス アカウントに関連付けられている JSON Web トークンです。 クライアントによって、自身を認証するために、MQTT ブローカーに SAT が提示されます。

MQTT ブローカーでは、「Kubernetes の新しいサービス アカウント トークンについて GKE ユーザーが知っておくべきこと」の記事で説明されている "バインドされたサービス アカウント トークン" が使われます。 記事で説明されている主な機能を次に示します。

バインドされたトークンは Kubernetes 1.13 で導入され、1.21 で既定の形式になりました。 バインドされたトークンは、従来のトークンの制限されたすべての機能に加えて、次の機能にも対処します。

• トークンを盗んだり誤用したりするのは困難です。 これらは、時間制限があり、対象ユーザーとオブジェクトにバインドされています。
• 標準化された形式が採用されています。 完全な OIDC 検出を含む OpenID Connect (OIDC) により、サービス プロバイダーはそれをいっそう容易に受け入れることができます。
• 新しい Kubelet 予測ボリュームの種類を使って、より安全にポッドに配布されます。

ブローカーは、Kubernetes Token Review API を使ってトークンを検証します。 Kubernetes の TokenRequestProjection 機能を有効にして、audiences を指定します (1.21 以降では既定)。 この機能が有効になっていない場合は、SAT を使用できません。

サービス アカウントの作成

SAT を作成するには、まずサービス アカウントを作成します。 次のコマンドでは、mqtt-client というサービス アカウントが作成されます。

kubectl create serviceaccount mqtt-client -n azure-iot-operations

省略可能: 認可のための属性を追加する

SAT 経由するクライアント認証では、必要に応じて、認証ポリシーで使用する属性でサービス アカウントに注釈を付けることができます。 これらの注釈を他から区別するために、これらは aio-broker-auth/ プレフィックスで始まります。

kubectl annotate を使って、サービス アカウントに注釈を付けることができます。

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

または、サービス アカウントのマニフェスト ファイルに注釈を追加できます。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <SERVICE_ACCOUNT_NAME>
  namespace: azure-iot-operations
  annotations:
    aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
    aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>

詳しくは、「Kubernetes サービス アカウント トークンを使用するクライアントを認可する」をご覧ください。

SAT 認証を有効にする

BrokerAuthentication リソースの authenticationMethods 設定を変更して、有効な認証方法として ServiceAccountToken を指定します。 audiences パラメーターでは、トークンの有効な対象ユーザーのリストを指定します。 MQTT ブローカー サービスを識別する一意の値を選択します。 1 つ以上の対象ユーザーを指定し、すべての SAT が指定された対象ユーザーのいずれかと一致する必要があります。

ポータル

1. Azure portal で、IoT Operations インスタンスに移動します。
2. [コンポーネント] で、[MQTT ブローカー] を選択します。
3. 認証 タブを選択します。
4. 既存の認証ポリシーを選択するか、新しい認証ポリシーを作成します。
5. [方法の追加] を選択して、新しい方法を追加します。
6. 方法の種類のドロップダウン リストから [Kubernetes SAT] を選びます。 次に、[詳細の追加] を選んで方法を構成します。

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Azure CLI を使用して Bicep ファイルをデプロイします。

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (プレビュー)

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience

kubectl apply を使用して変更を適用します。 変更が有効になるまで、数分かかる場合があります。

SAT 認証をテストする

SAT 認証では、MQTT v5 拡張認証フィールドが使用されます。 クライアントは、拡張認証方法を K8S-SAT に、拡張認証データをトークンに設定する必要があります。

たとえば、Mosquitto を使います (簡潔にするため一部のフィールドは省略されています)。

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

ここで、<TOKEN> はサービス アカウント トークンです。 テスト トークンを取得するには、次を実行します。

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

ここで、<SERVICE_ACCOUNT> は作成したサービス アカウントの名前であり、<AUDIENCE> は BrokerAuthentication リソースで構成されている対象ユーザーの 1 つです。

SAT 認証を使用するように Kubernetes ポッドを構成する方法の例については、「クラスター内の既定のリスナーに接続する」を参照してください。

ポッド構成の serviceAccountName フィールドは、使われているトークンに関連付けられているサービス アカウントと一致する必要があります。 serviceAccountToken.audience フィールドは、BrokerAuthentication リソースで構成されている audiences のいずれかである必要があります。

サービス アカウント トークンを更新する

サービス アカウント トークンは、限られた期間有効であり、expirationSeconds を使用して構成されます。 ただし、Kubernetes は、有効期限が切れる前にトークンを自動的に更新します。 トークンはバックグラウンドで更新されます。クライアントは、それを再フェッチする以外に何も行う必要はありません。

たとえば、「SAT 認証をテストする」の例のように、クライアントがボリュームとしてマウントされたトークンを使うポッドである場合、同じパス /var/run/secrets/tokens/broker-sat で最新のトークンを取得できます。 クライアントは、新しい接続を作成するとき、最新のトークンをフェッチし、それを使って認証を行うことができます。 クライアントには、最新のトークンをフェッチして接続を再試行することで MQTT 未承認エラーを処理するメカニズムも必要です。

カスタム認証

カスタム認証を使用して、指定された認証方法以外にもクライアント認証を拡張します。 API に準拠している限りサービスは何でもかまわないため、それは "プラグ可能" です。

カスタム認証が有効な状態でクライアントが MQTT ブローカーに接続すると、そのブローカーは、クライアントの資格情報を使用してカスタム認証サーバーに HTTPS 要求を送信します。 サーバーは次に、承認または拒否のどちらか (クライアントの認可属性を含む) で応答します。

カスタム認証サービスを作成する

カスタム認証サーバーは、MQTT ブローカーとは別に実装およびデプロイされます。

サンプルのカスタム認証サーバーと手順は、GitHub で入手できます。 このサンプルをテンプレートとして、および独自のカスタム認証ロジックを実装するための開始点として使います。

API

MQTT ブローカーとカスタム認証サーバーの間の API は、カスタム認証に関する API の仕様に従います。 OpenAPI 仕様は GitHub で入手できます。

TLS 暗号化を使用した HTTPS が必要

MQTT ブローカーは、機密のクライアント資格情報を含む要求をカスタム認証サーバーに送信します。 これらの資格情報を保護するため、MQTT ブローカーとカスタム認証サーバーの間の通信を TLS で暗号化する必要があります。

カスタム認証サーバーはサーバー証明書を提示する必要があり、MQTT ブローカーには、サーバー証明書を検証するための信頼されたルート CA 証明書が必要です。 場合によっては、カスタム認証サーバーは、MQTT ブローカーにそれ自身の認証を行うためにクライアント証明書の提示を求めることがあります。

リスナーのカスタム認証を有効にする

BrokerAuthentication リソースの [認証方法] の設定を変更し、有効な認証方法として [カスタム] を指定します。 次に、カスタム認証サーバーとの通信に必要なパラメータを指定します。

ポータル

1. Azure portal で、IoT Operations インスタンスに移動します。

2. [コンポーネント] で、[MQTT ブローカー] を選択します。

3. 認証 タブを選択します。

4. 既存の認証ポリシーを選択するか、新しい認証ポリシーを作成します。

5. [方法の追加] を選択して、新しい方法を追加します。

6. 方法の種類のドロップダウン リストから [カスタム] を選びます。 次に、[詳細の追加] を選んで方法を構成します。

   

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Azure CLI を使用して Bicep ファイルをデプロイします。

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (プレビュー)

この例では、使用する可能性のあるすべてのパラメータを示します。 求められる正確なパラメーターは、各カスタム サーバーの要件によって異なります。

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

認証を無効にする

テストのために、ブローカー リスナー ポートの認証を無効にすることができます。 運用環境では認証を無効にしないことをお勧めします。

ポータル

1. Azure portal で、IoT Operations インスタンスに移動します。
2. [コンポーネント] で、[MQTT ブローカー] を選択します。
3. 編集するブローカー リスナーを一覧から選択します。
4. 認証を無効にするポートで、認証ドロップダウンの [なし] を選びます。

Bicep

認証を無効にするには、BrokerListener リソースの ports の設定で authenticationRef を省略します。

Kubernetes (プレビュー)

認証を無効にするには、BrokerListener リソースの ports の設定で authenticationRef を省略します。

資格情報の期限切れ後のクライアントの切断

MQTT ブローカーは、資格情報が期限切れになるとクライアントを切断します。 資格情報の期限切れ後の切断は、次のような MQTT ブローカー フロントエンドに接続するすべてのクライアントに適用されます。

• SAT で認証されたクライアントは、SAT が期限切れになると切断されます。
• X.509 で認証されたクライアントは、クライアント証明書が期限切れになると切断されます。
• カスタム認証で認証されたクライアントは、カスタム認証サーバーから返された有効期限に基づいて切断されます。

切断すると、クライアントのネットワーク接続が閉じられます。 クライアントは MQTT DISCONNECT パケットを受信しませんが、ブローカーは、クライアントを切断したというメッセージをログに記録します。

SAT とカスタム認証で認証された MQTT v5 クライアントは、最初の資格情報の期限切れ前に、新しい資格情報で再認証できます。 認証は TLS 層で行われるため、X.509 クライアントは再認証できず、接続を確立し直す必要があります。

クライアントは、MQTT v5 AUTH パケットを理由 ReAuth で送信することで再認証できます。

SAT クライアントは、method: K8S-SAT と data: <token> フィールドを含む AUTH クライアントを送信します。 カスタム認証クライアントは、カスタム認証サーバーで必要に応じてメソッドとデータ フィールドを設定します。

再認証が成功すると、クライアントの資格情報の有効期限が新しい資格情報の有効期限で更新されます。 ブローカーは、Success AUTH パケットで応答します。 カスタム認証サーバーが使用できないなどの一時的な問題が原因で認証が失敗すると、ブローカーは ContinueAuthentication AUTH パケットで応答します。 クライアントは後で再試行することができます。 その他の認証エラーでは、ブローカーが DISCONNECT パケットを送信し、クライアントのネットワーク接続を閉じます。

関連するコンテンツ

• BrokerListener のリソース
• BrokerListener の認可を構成する
• チュートリアル: TLS、X.509 クライアント認証、属性ベースのアクセス制御 (ABAC) 認可