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

[アーティクル]
11/21/2024

重要

このページには、プレビュー段階にある 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) のみを使用するように構成されています。

重要

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

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。
認証タブを選択します。
認証ポリシーの一覧から、既定のポリシー名を選択します。

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

既定のエンドポイントを編集するには、次の内容を含む 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

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

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:
        # ...

前の例では、カスタムと SAT が指定されています。クライアントに接続すると、MQTT ブローカーは、"カスタム" の次に SAT という順番で指定した方法を使用してクライアントの認証を試みます。

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

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

認証方法を構成する

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

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

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。
認証タブを選択します。
既存の認証ポリシーを選択するか、新しい認証ポリシーを作成します。
[方法の追加] を選択して、新しい方法を追加します。
ドロップダウンリストから方法の種類を選択し、[詳細の追加] を選択して方法を構成します。

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

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 認証では、MQTT ブローカーは信頼された CA 証明書を使用してクライアント証明書を検証します。クライアントは、MQTT ブローカーを認証するために、この CA に根ざした証明書を提示します。 EC キーと RSA キーの両方がサポートされていますが、チェーン内のすべての証明書で同じキーアルゴリズムを使用する必要があります。 X.509 は TLS クライアント証明書に依存しているため、X.509 認証を使用するポートでは TLS を有効にする必要があります。

クライアント証明書の検証に使用できるルート証明書をインポートするには、証明書の PEM を ConfigMap としてインポートします。次に例を示します。

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

この例では、CA 証明書はキー client_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
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
<Certificate>
-----END CERTIFICATE-----


BinaryData
====

信頼された CA 証明書がインポートされたら、X.509 クライアント認証を有効にします。これは、TLS 対応リスナーポートにリンクされた BrokerAuthentication リソースに、認証方法の 1 つとして追加することで行います。

認可用の証明書の属性

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

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。
認証タブを選択します。
既存の認証ポリシーを選択するか、新しい認証ポリシーを作成します。
[方法の追加] を選択して、新しい方法を追加します。
ドロップダウンリストから方法の種類 [X.509] を選択し、[詳細の追加] を選択して方法を構成します。

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: 'X509'
        x509Settings: {
          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'
              }
            }
          }
        }
      }
    ]
  }
}

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

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

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        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 クライアント証明書を使用して 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 クライアント認証フローを理解する

X.509 クライアント認証フローの図。

クライアント認証フローの手順を次に示します。

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

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

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

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

Kubernetes 1.13 で導入され、1.21 で既定の形式となったバインドトークンは、レガシトークンの制限された機能すべてに対処するものです。他にも次のような特徴があります。

トークン自体が盗用、誤用しずらいものです。これらは、時間、対象ユーザー、オブジェクトに対してバインドされています。
OpenID Connect (OIDC) という標準化された形式を採用し、完全な 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 経由するクライアント認証では、必要に応じて、認証ポリシーで使用する属性でサービスアカウントに注釈を付けることができます。詳細については、Kubernetes サービスアカウントトークンを使用するクライアントの認可に関するページを参照してください。

サービスアカウントトークン (SAT) 認証を有効にする

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

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

Azure portal を使用して MQTT ブローカーの SAT 認証方法を設定するスクリーンショット。

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

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 ブローカーに接続し、カスタム認証が有効になっている場合、MQTT ブローカーは、クライアントが提示するすべての資格情報と共に HTTP 要求を使用して、クライアント資格情報の検証をカスタム認証サーバーに委任します。カスタム認証サーバーは、クライアントの認可用の属性を使用して、クライアントに対して承認または拒否で応答します。

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

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

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

API

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

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

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

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

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

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

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

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

認証を無効にする

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

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

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

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

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

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

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

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

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

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

BrokerListener リソースについて
BrokerListener の認可を構成する

次の方法で共有

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

BrokerListener と BrokerAuthentication のリンク

既定の BrokerAuthentication リソース

Authentication flow

認証方法を構成する

X.509

認可用の証明書の属性

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

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

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

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

認可用の属性を追加する

サービスアカウントトークン (SAT) 認証を有効にする

SAT 認証をテストする

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

カスタム認証

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

API

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

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

認証を無効にする

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

フィードバック

その他のリソース

次の方法で共有

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

BrokerListener と BrokerAuthentication のリンク

既定の BrokerAuthentication リソース

Authentication flow

認証方法を構成する

X.509

認可用の証明書の属性

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

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

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

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

認可用の属性を追加する

サービス アカウント トークン (SAT) 認証を有効にする

SAT 認証をテストする

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

カスタム認証

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

API

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

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

認証を無効にする

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

関連するコンテンツ

フィードバック

その他のリソース

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

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

サービスアカウントトークン (SAT) 認証を有効にする

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