BrokerListener を使用して MQTT ブローカー通信をセキュリティで保護する

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

重要

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

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

BrokerListener は、ネットワークを介してブローカーをクライアントに公開するネットワークエンドポイントに相当します。 Broker ごとに 1 つ以上の BrokerListener リソースを用意し、それぞれで複数のポートと異なるアクセス制御を使用できます。

各 BrokerListener ポートに認証と認可の独自のルールを設定し、誰がそのリスナーポートで接続できるか、どのようなアクションをそのブローカーで実行できるかを定義できます。 BrokerAuthentication リソースと BrokerAuthorization リソースを使って、各リスナーポートのアクセス制御ポリシーを指定できます。この柔軟性により、各 MQTT クライアントのアクセス許可とロールを、そのニーズとユースケースに基づいて微調整できます。

ヒント

既定の MQTT ブローカーのデプロイは、クライアントが TLS で接続し、サービスアカウントトークンで認証する必要がある、クラスター IP サービスです。クラスター外から接続するクライアントには、接続のための追加の構成が必要です。

ブローカーリスナーには次の特性があります。

名前: リスナーの名前。この名前は、オーバーライドしない限り、Kubernetes サービス名でもあります。
サービスの種類: サービスの種類ごとに 1 つずつ、最大 3 つのリスナーを持つことができます。既定のリスナーのサービスの種類は ClusterIp です。
ポート: 各リスナーは複数のポートをサポートします。ポートを異なるリスナー間で競合させることはできません。
認証と認可の参照: ポートごとに BrokerAuthentication と BrokerAuthorization を構成します。
TLS: ポートごとに手動または自動の TLS 構成を適用します。
プロトコル: ポートごとに MQTT over WebSockets を有効にできます。

使用できるすべての設定の一覧については、ブローカーリスナーの API リファレンスを参照してください。

既定の BrokerListener

Azure IoT Operations をデプロイすると、デプロイによって default という名前の BrokerListener リソースが作成されます。このリスナーは、Azure IoT Operations コンポーネント間の暗号化された内部通信に使用されます。既定のリスナーは、既定のブローカーの一部です。

ポート 18883 で ClusterIp サービスを公開します
クライアントに Kubernetes サービスアカウント認証の使用が要求されます
自動的に管理される TLS 証明書があります
クライアント認可ポリシーは構成されません

注意事項

Azure IoT Operations の内部通信が中断されないようにするために、既定のリスナーは変更せず、内部使用専用にしてください。外部通信のためには、新しいリスナーを作成します。 ClusterIp サービスを使う必要がある場合は、既定のリスナーにポートを追加して、既存の設定を変更しないようにします。

既定のリスナーを表示または編集するには:

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。
ブローカーリスナーの一覧から、default リスナーを選択します。
リスナーの設定を確認しますが、既存の設定は変更しないでください。代わりに、必要に応じて新しいポートを作成して構成します。

Bicep を使って既定のリスナーを変更するときは注意してください。既存の設定は変更しないでください。代わりに、既定のリスナーにポートを追加します。次の例は、既定のリスナーに新しいポートを追加する方法を示しています。

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

resource aioInstance 'Microsoft.IoTOperations/instances@2024-09-15-preview' existing = {
  name: aioInstanceName
}

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

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

resource defaultListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-09-15-preview' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    // Don't change the service name or service type
    serviceType: 'ClusterIp'
    serviceName: 'aio-broker'
    ports: [
      // Don't modify the default port 18883 settings
      {
        port: 18883
        authenticationRef: 'default'
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
            privateKey: {
              algorithm: 'Ec256'
              rotationPolicy: 'Always'
            }
          }
        }
      }
      // Add more ports here, like the following example
      {
        port: 1884
        protocol: 'Mqtt'
      }
    ]
  }
}

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

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

既定の BrokerListener リソースを表示するには、次のコマンドを使用します。

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

出力は次のようになります。簡潔にするために、ほとんどのメタデータが削除されています:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: default
  namespace: azure-iot-operations
  ownerReferences:
  - apiVersion: mqttbroker.iotoperations.azure.com/v1
    kind: Broker
    name: default
spec:
  serviceType: ClusterIp
  serviceName: aio-broker
  ports:
  - port: 18883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: azure-iot-operations-aio-certificate-issuer
          kind: ClusterIssuer
          group: cert-manager.io
        privateKey:
          algorithm: Ec256
          rotationPolicy: Always

既定のリスナーに新しいポート 1883 を、TLS なし、認証オフで追加するには、kubectl patch コマンドを使います。

kubectl patch brokerlistener default -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/-", "value": {"port": 1883, "protocol": "Mqtt"}}]'

既定のブローカーリスナーを変更しない

Azure IoT Operations の内部通信が中断されないようにするために、既定のリスナーは変更せず、内部使用専用にしてください。外部通信のためには、新しいリスナーを作成します。

既定のブローカーリスナーによってサービスの種類 ClusterIp が使用され、使用できるリスナーはサービスの種類ごとに 1 つだけなので、ClusterIp サービスを使用する必要がある場合は、既存の設定を変更せずに既定のリスナーにポートを追加します。

新しいブローカーリスナーを作成する

新しいリスナーを作成するには、次の設定を指定します。

名前: リスナーの名前。この名前は、オーバーライドしない限り、Kubernetes サービス名でもあります。
サービスの種類: Kubernetes サービスの種類。「サービスの種類」を参照してください。
ポート: リッスンするポートのリスト。「ポート」を参照してください。
(省略可能) サービス名: Kubernetes サービス名をオーバーライドします。「サービス名」を参照してください。

例: 2 つのポートを持つ新しいリスナーを作成する

この例では、サービスの種類がロードバランサーの新しいリスナーを作成する方法を示します。 BrokerListener リソースでは、クライアントからの MQTT 接続を受け入れる 2 つのポートを定義します。

最初のポートは、TLS と認証なしのポート 1883 でリッスンします。このセットアップは、テスト専用に適しています。運用環境でこの構成を使わないでください。
2 番目のポートは、TLS と認証が有効になっているポート 8883 でリッスンします。 Kubernetes サービスアカウントトークンを持つ認証されたクライアントだけが接続できます。 TLS は自動モードに設定され、cert-manager を使って既定の発行者からのサーバー証明書を管理します。このセットアップは、運用環境の構成により近くなります。

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。

[LoadBalancer の MQTT ブローカーリスナー]>[作成] を選択します。

次の情報を入力します :

設定	内容
Name	BrokerListener リソースの名前。
サービス名	Kubernetes サービスの名前。空のままにして、リスナー名をサービス名として使用します。
サービスの種類	LoadBalancer が既に選択されています。

[ポート] で、最初のポート用に次の設定を入力します。

設定説明

ポート「1883」と入力します

認証 [なし] を選択します

承認 [なし] を選択します

Protocol [MQTT] を選択します

TLS 列を

設定	説明
ポート	「1883」と入力します
認証	[なし] を選択します
承認	[なし] を選択します
Protocol	[MQTT] を選択します
TLS	列を

[ポートエントリの追加] を選択して 2 つ目のポートを追加し、次の設定を入力します。

設定	説明
ポート	「8883」と入力します
認証	既定を選択します
承認	[なし] を選択します
Protocol	[MQTT] を選択します
TLS	[追加] を選択します。

[TLS 構成] ペインで、次の設定を入力します。

設定	説明
TLS モード	[自動] を選択します
発行者名	「`azure-iot-operations-aio-certificate-issuer`」と入力します
発行者の種類	[ClusterIssuer] を選択します

他の設定は既定値のままにして、[適用] を選択します。

[リスナーの作成] を選択します。

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = '<LISTENER_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 loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        port: 1883
        protocol: 'Mqtt'
      }
      {
        authenticationRef: 'default'
        port: 8883
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
          }
        }
      }
    ]
  }
}

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

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

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: <LISTENER_NAME>
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: LoadBalancer
  ports:
  - port: 1883
    protocol: Mqtt
  - port: 8883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
            name: azure-iot-operations-aio-certificate-issuer
            kind: ClusterIssuer
            group: cert-manager.io

サービスの種類

各 BrokerListener は、Kubernetes サービスにマップされます。サービスの種類によって、ブローカーがネットワークに公開される方法が決まります。サポートされているサービスの種類は次のとおりです。

ClusterIp: クラスターの内部 IP でブローカーを公開します。クライアントは、クラスター内からブローカーに接続できます。これは、既定のリスナーに対する既定のサービスの種類です。
NodePort: 各ノードの IP で静的ポートでブローカーを公開します。クライアントは、クラスター外からブローカーに接続できます。このサービスの種類は、開発とテスト用に便利です。
LoadBalancer: ブローカーを外部に公開します。サービスには外部 IP アドレスが割り当てられ、クライアントはそれを使ってブローカーに接続できます。これは、運用環境のデプロイで最も一般的なサービスの種類です。

サービスの種類ごとに 1 つのリスナー

使用できるのは、サービスの種類ごとに 1 つのリスナーです。同じサービスの種類で接続を増やす必要がある場合は、そのサービスの種類の既存のリスナーにポートを追加します。

サービス名

サービス名は、ブローカーに関連付けられている Kubernetes サービスの名前です。指定しない場合は、ブローカーリスナー名がサービス名として使用されます。サービス名は、名前空間内で一意にする必要があります。

ヒント

管理のオーバーヘッドを防ぐために、サービス名は空のままにすることをお勧めします。リスナー名は一意であり、サービスを識別するために使用できます。リスナーにちなんだサービス名を付けられない場合にのみ、サービス名をオーバーライドとして使用します。

Port

各リスナーは複数のポートを持つことができ、各ポートで認証、認可、プロトコル、TLS を独自に設定できます。

ポートで独自の認証または認可設定を使うには、対応するリソースを作成してから、リスナーで使う必要があります。詳しくは、「MQTT ブローカー認証を構成する」と「MQTT ブローカー認可を構成する」を参照してください。

TLS を使う場合は、「自動の証明書管理で TLS を構成する」または「手動の証明書管理で TLS を構成する」を参照してください。

リスナー間で同じポートを使う

異なるリスナー間で同じポート番号を使用することはサポートされていません。各ポート番号は、Azure IoT Operations MQTT ブローカー内で一意である必要があります。

たとえば、ポート 1883 を使用するリスナーがある場合、ポート 1883 で別のリスナーを作成することはできません。同様に、既定のリスナーではポート 18883 が使用されるため、ポート 18883 で別のリスナーを作成することはできません。

WebSocket のサポート

Azure IoT Operations MQTT ブローカーでは、MQTT over WebSockets がサポートされています。 WebSockets を有効にするには、ポートに対してプロトコルを WebSockets に設定します。

自動の証明書管理で TLS を構成する

自動証明書管理で TLS を有効にするには、リスナーポートで TLS 設定を指定してください。

cert-manager のインストールを確認する

証明書の自動管理では、cert-manager を使用して TLS サーバー証明書を管理します。既定では、cert-manager は Azure IoT Operations Preview と共に cert-manager 名前空間に既にインストールされています。続行する前に、インストールを確認します。

kubectl を使用して、cert-manager のアプリラベルに一致するポッドを確認します。

kubectl get pods --namespace cert-manager -l 'app in (cert-manager,cainjector,webhook)'

NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

ポッドが準備完了で実行中と表示されている場合、cert-manager はインストールされており、使用できる状態になっています。

ヒント

インストール状況をさらに確認するには、cert-manager のドキュメント、「インストールの確認」を確認します。 cert-manager 名前空間を必ず使用してください。

TLS サーバー証明書の発行者を作成する

cert-manager の発行者リソースでは、証明書を自動的に発行する方法が定義されます。 cert-manager では、いくつかの発行者の種類がネイティブでサポートされています。また、ネイティブでサポートされている発行者以外にも機能を拡張するために、外部発行者の種類もサポートされています。 MQTT ブローカーは、あらゆる種類の cert-manager 発行者で使用できます。

重要

初期デプロイ時に、Azure IoT Operations は TLS サーバー証明書の既定の発行者を使用してインストールされます。この発行者を開発とテストに使うことができます。詳細については、「Azure IoT Operations での既定のルート CA と発行者」を参照してください。以下の手順は、別の発行者を使用する場合にのみ必要です。

発行者を作成する方法は、シナリオによって異なります。次のセクションでは、作業の開始に役立つ例を示します。

開発またはテスト
実稼働

CA 発行者は、開発とテストに役立ちます。これは、Kubernetes シークレットに格納されている証明書と秘密キーを使用して構成する必要があります。

ルート証明書を Kubernetes シークレットとして設定する

既存の CA 証明書がある場合は、CA 証明書と CA 秘密キーの PEM ファイルを使用して Kubernetes シークレットを作成します。次のコマンドを実行して CA 証明書を Kubernetes シークレットとしてインポートし、次のセクションはスキップしてください。

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

CA 証明書がない場合、cert-manager で CA 証明書を生成できます。 cert-manager を使って CA 証明書を生成することは、自己署名証明書による CA 発行者のブートストラップと呼ばれます。

まず、ca.yaml を作成します。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

次のコマンドを使用して、自己署名 CA 証明書を作成します。
```
kubectl apply -f ca.yaml
```

cert-manager では、既定値を使用して CA 証明書を作成します。この証明書のプロパティは、証明書の仕様を変更することで変更できます。有効なオプションの一覧については、cert-manager のドキュメントを参照してください。

ルート証明書を配布する

前の例では、CA 証明書が test-ca という Kubernetes シークレットに格納されます。 PEM 形式の証明書は、シークレットから取得し、次のコマンドを使用してファイル ca.crt に格納できます。

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

この証明書は、すべてのクライアントに配布および信頼されている必要があります。たとえば、mosquitto クライアントの場合は --cafile フラグを使用します。

CA 証明書に基づいて発行者を作成する

cert-manager には、前の手順で生成またはインポートされた CA 証明書に基づく発行者が必要です。次のファイルを issuer-ca.yaml として作成します。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
  namespace: azure-iot-operations
spec:
  ca:
    # Must match secretName of generated or imported CA cert
    secretName: test-ca

次のコマンドで発行者を作成します。

kubectl apply -f issuer-ca.yaml

前のコマンドでは、TLS サーバー証明書を発行するための発行者を作成しています。発行者の名前と種類をメモします。この例では、名前は my-issuer で、種類は Issuer です。これらの値は、後で BrokerListener リソースで設定されます。

運用環境の場合は、cert-manager のドキュメントを確認して、どの発行者が最適かを確認してください。 Vault Issuer の場合の例:

Kubernetes などの選択した環境に、HashiCorp コンテナーをデプロイします。コンテナーを適宜初期化してシール解除します。
CA 証明書をインポートして、PKI シークレットエンジンを作成して構成します。
サーバー証明書を発行するためのロールとポリシーを使用してコンテナーを構成します。

ロールの例を次に示します。 ExtKeyUsageServerAuth によってサーバー証明書が機能します。
```
vault write pki/roles/my-issuer \
  allow_any_name=true \
  client_flag=false \
  ext_key_usage=ExtKeyUsageServerAuth \
  no_store=true \
  max_ttl=240h
```
ロールのポリシーの例:
```
path "pki/sign/my-issuer" {
  capabilities = ["create", "update"]
}
```
SAT などの任意の方法を使用して、cert-manager とコンテナーの間の認証を設定します。
cert-manager Vault Issuer を構成します。

ポートの TLS 自動証明書管理を有効にする

自動証明書管理を使用してポート 8884 で TLS を有効にする BrokerListener リソースの例を次に示します。

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。
リスナーを選択または作成します。サービスの種類ごとにリスナーを 1 つだけ作成できます。同じサービスの種類のリスナーが既にある場合は、既存のリスナーにポートをさらに追加できます。

リスナーに TLS 設定を追加するには、既存のポートで [TLS] を選択するか、新しいポートを追加します。

次の情報を入力します :

設定	内容
Name	BrokerListener リソースの名前。「`aio-broker-loadbalancer-tls`」と入力します。
ポート	BrokerListener が MQTT 接続をリッスンするポート番号。「8884」と入力します。
認証	認証リソース参照。
承認	認可リソース参照。
TLS	追加ボタンを選択します。
発行者名	cert-manager 発行者の名前。必須。
発行者の種類	cert-manager 発行者の種類。必須。
発行者グループ	cert-manager 発行者のグループ。必須。
秘密キーアルゴリズム	秘密キーのアルゴリズム。
秘密キーローテーションポリシー	秘密キーをローテーションするためのポリシー。
DNS 名	証明書の DNS サブジェクト代替名。
IP アドレス	証明書のサブジェクト代替名の IP アドレス。
シークレット名	X.509 クライアント証明書を含む Kubernetes シークレット。
Duration	TLS サーバー証明書の合計有効期間の既定値は 90 日です。
更新前	証明書の更新を開始するタイミング。

[適用] を選択し、TLS 設定を保存します。

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-loadbalancer-tls'

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 loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8884
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'my-issuer'
              kind: 'Issuer'
            }
          }
        }
      }
    ]
  }
}

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

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

BrokerListener リソースの tls 設定を変更して、フロントエンドの TLS ポートと発行者を指定します。

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-loadbalancer-tls # Avoid conflicts with default service name 'aio-broker'
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer
  ports:
  - port: 8884 # Avoid conflicts with default port 18883
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: my-issuer
          kind: Issuer

BrokerListener リソースが構成されると、MQTT ブローカーでは、指定されたポートと TLS が有効になっている新しいサービスが自動的に作成されます。

省略可能: サーバー証明書のパラメーターを構成する

必須のパラメーターは、発行者名と発行者の種類のみです。生成された TLS サーバー証明書のその他のプロパティは、すべて自動的に選択されます。しかし、MQTT ブローカーでは、cert-manager の証明書と同じ構文に従って、特定のプロパティをカスタマイズできます。たとえば、秘密キーのアルゴリズムとローテーションポリシーを指定できます。これらの設定は、tls.certManagerCertificateSpec か、Azure portal の [TLS 構成] ペインにあります。

これらの設定の完全な一覧については、ブローカーリスナーの CertManagerCertificateSpec API リファレンスを参照してください。

デプロイの検証

kubectl を使用して、BrokerListener リソースに関連付けられているサービスが実行されていることを確認します。上記の例では、サービス名が aio-broker-loadbalancer-tls、名前空間が azure-iot-operations です。次のコマンドで、サービスの状態を確認します。

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
aio-broker-loadbalancer-tls    LoadBalancer   10.X.X.X        172.X.X.X     8884:32457/TCP   33s

TLS を使用してブローカーに接続する

サーバー証明書が構成されると、TLS が有効になります。 mosquitto を使用してテストするには:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

--cafile 引数によって、mosquitto クライアント上で TLS が有効になり、クライアントは指定されたファイルによって発行されたすべてのサーバー証明書を信頼する必要があることが指定されます。構成された TLS サーバー証明書の発行者を格納するファイルを指定する必要があります。

$HOST を適切なホストに置き換えます。

同じクラスター内から接続する場合は、指定されたサービス名 (例では my-new-tls-listener) またはサービス CLUSTER-IP に置き換えます。
クラスターの外部から接続する場合、サービス EXTERNAL-IP を指定します。

必要に応じて、必ず認証方法を指定してください。

既定のルート CA と発行者

作業の開始に役立つように、Azure IoT Operations は TLS サーバー証明書のための既定の "quickstart" という CA 証明書と発行者を使用してデプロイされます。この発行者を開発とテストに使うことができます。詳細については、「TLS サーバー証明書の既定のルート CA と発行者」を参照してください。

運用環境では、前のセクションで説明したように、信頼された CA の証明書を使用して CA 発行者を構成する必要があります。

手動の証明書管理で TLS を構成する

特定の TLS 証明書を使うように MQTT ブローカーを手動で構成するには、Kubernetes シークレットへの参照を使って BrokerListener リソース内でこれを指定し、kubectl を使ってデプロイします。この記事では、テスト用の自己署名証明書を使用して TLS を構成する例を示します。

Step CLI を使用して証明機関を作成する

Step は、独自のプライベート CA を作成および管理するときにすぐに起動して実行できる証明書マネージャーです。

Step CLI をインストールし、ルート証明機関 (CA) の証明書とキーを作成します。
```
step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key
```

ルート CA によって署名された中間 CA 証明書とキーを作成します。

step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

サーバー証明書を作成する

手順 CLI を使用して、中間 CA によって署名されたサーバー証明書を作成します。

step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure

ここで、mqtts-endpoint と localhost は、それぞれ Kubernetes およびローカルクライアントにおける MQTT ブローカーのフロントエンドのサブジェクトの別名 (SAN) です。インターネット経由で接続するには、--san と外部 IP を追加します。 --no-password --insecure フラグは、パスワードプロンプトをスキップして秘密キーのパスワード保護を無効にするためにテスト目的で使用されます。その理由は、秘密キーが Kubernetes シークレットに格納されるためです。運用環境では、パスワードを使用し、秘密キーを Azure Key Vault などの安全な場所に格納します。

証明書キーアルゴリズムの要件

EC キーと RSA キーの両方がサポートされていますが、チェーン内のすべての証明書で同じキーアルゴリズムを使用する必要があります。独自の CA 証明書をインポートする場合、サーバー証明書では CA と同じキーアルゴリズムを使ってください。

サーバー証明書チェーンを Kubernetes シークレットとしてインポートする

完全なサーバー証明書チェーンを作成します。ここでは証明書の順序が重要です。サーバー証明書はファイルの最初、中間は 2 番目になります。
```
cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt
```
kubectl を使用して、サーバー証明書チェーンとサーバーキーを持つ Kubernetes シークレットを作成します。
```
kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key
```

ポートの TLS 手動証明書管理を有効にする

手動証明書管理を使用してポート 8884 で TLS を有効にする BrokerListener リソースの例を次に示します。

Azure portal で、IoT Operations インスタンスに移動します。
[Azure IoT Operations リソース] で、[MQTT ブローカー] を選択します。
リスナーを選択または作成します。サービスの種類ごとにリスナーを 1 つだけ作成できます。同じサービスの種類のリスナーが既にある場合は、既存のリスナーにポートをさらに追加できます。この例に従って、リスナーサービス名を mqtts-endpoint として指定します。

リスナーに TLS 設定を追加するには、既存のポートで [TLS] を選択するか、新しいポートを追加します。

次の情報を入力します :

設定	説明
ポート	BrokerListener が MQTT 接続をリッスンするポート番号。必須。
認証	認証リソース参照。
承認	認可リソース参照。
TLS	追加ボタンを選択します。
シークレット名	X.509 クライアント証明書を含む Kubernetes シークレット。

[適用] を選択し、TLS 設定を保存します。

BrokerListener リソースの tls 設定を変更して、Kubernetes シークレットを参照する手動 TLS 構成を指定します。 TLS サーバー証明書に使用されるシークレットの名前をメモします (前の例の server-cert-secret)。

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerServiceName string = 'mqtts-endpoint'
param listenerName string = '<LISTENER_NAME>' // Match the SAN in the server certificate

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 loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceName: listenerServiceName
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8885 // Avoid port conflict with default listener at 18883
        tls: {
          mode: 'Manual'
          manual: {
            secretRef: 'server-cert-secret'
          }
        }
      }
    ]
  }
}

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

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

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: loadbalancer-tls
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  ports:
  - port: 8885 # Avoid port conflict with default listener at 18883
    tls:
      mode: Manual
      manual:
        secretRef: server-cert-secret

BrokerListener リソースが作成されると、オペレーターは自動的に Kubernetes サービスを作成し、リスナーをデプロイします。 kubectl get svc を実行して、サービスの状態を確認できます。

TLS を使用してブローカーに接続する

mosquitto クライアントとの TLS 接続をテストするには、メッセージを発行し、パラメータ --cafile にルート CA 証明書を渡します。

mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt

MQTT ブローカー認証が有効になっている場合は、必ずユーザー名やパスワードなどを指定してください。

Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT

ヒント

localhost を使用するには、ホストコンピューターでポートを使用できる必要があります。たとえば、kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations のようにします。 K3d のような一部の Kubernetes ディストリビューションでは、k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer で転送されたポートを追加できます。

Note

ブローカーに接続するには、すべてのクライアントに信頼のルート (信頼バンドルとも呼ばれます) を配布する必要があります。この場合、信頼のルートは、Step CLI によって作成された自己署名ルート CA です。クライアントがサーバー証明書チェーンを検証するには、信頼のルートの配布が必要です。 MQTT クライアントが Kubernetes クラスター上のワークロードである場合は、ルート CA を使用して ConfigMap を作成し、ポッドにマウントする必要もあります。

サーバー証明書に対して外部 IP を使用する

TLS を使ってインターネット経由で接続するには、MQTT ブローカーのサーバー証明書に SAN として外部ホスト名と IP アドレスが含まれている必要があります。運用環境では、これは通常、DNS 名または既知の IP アドレスです。ただし、開発/テスト中は、デプロイ前に割り当てられているホスト名または外部 IP がわからない場合があります。これを解決するには、まずサーバー証明書なしでリスナーをデプロイし、外部 IP を使ってサーバー証明書とシークレットを作成して、シークレットをリスナーにインポートします。

TLS リスナーのサンプル manual-tls-listener をデプロイしようとしても、参照先の Kubernetes シークレット server-cert-secret が存在しない場合は、関連付けられたサービスが作成されますが、ポッドは起動しません。サービスが作成されるのは、オペレーターがリスナーの外部 IP を予約する必要があるためです。

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

ただし、サーバー証明書をインポートする場合、これは想定された動作です。正常性マネージャーログに、MQTT ブローカーがサーバー証明書を待機中であることが示されています。

kubectl logs -l app=health-manager -n azure-iot-operations

...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.

Note

一般に、分散システムでは、ポッドログは決定論的ではないため、慎重に使用する必要があります。このような情報を表示する正しい方法は、Kubernetes イベントとカスタムリソースの状態 (バックログ内) を使用することです。前の手順は、一時的な回避策と考えてください。

フロントエンドポッドが稼働していない場合でも、外部 IP は既に使用できます。

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

ここから、前と同じ手順に従って、--san でこの外部 IP を使用してサーバー証明書を作成し、同じ方法で Kubernetes シークレットを作成します。シークレットが作成されると、リスナーに自動的にインポートされます。

次の方法で共有

BrokerListener を使用して MQTT ブローカー通信をセキュリティで保護する

既定の BrokerListener

既定のブローカーリスナーを変更しない

新しいブローカーリスナーを作成する

例: 2 つのポートを持つ新しいリスナーを作成する

サービスの種類

サービスの種類ごとに 1 つのリスナー

サービス名

Port

リスナー間で同じポートを使う

WebSocket のサポート

自動の証明書管理で TLS を構成する

cert-manager のインストールを確認する

TLS サーバー証明書の発行者を作成する

ルート証明書を Kubernetes シークレットとして設定する

ルート証明書を配布する

CA 証明書に基づいて発行者を作成する

ポートの TLS 自動証明書管理を有効にする

省略可能: サーバー証明書のパラメーターを構成する

デプロイの検証

TLS を使用してブローカーに接続する

既定のルート CA と発行者

手動の証明書管理で TLS を構成する

Step CLI を使用して証明機関を作成する

サーバー証明書を作成する

証明書キーアルゴリズムの要件

サーバー証明書チェーンを Kubernetes シークレットとしてインポートする

ポートの TLS 手動証明書管理を有効にする

TLS を使用してブローカーに接続する

サーバー証明書に対して外部 IP を使用する

フィードバック

その他のリソース

次の方法で共有

BrokerListener を使用して MQTT ブローカー通信をセキュリティで保護する

既定の BrokerListener

既定のブローカー リスナーを変更しない

新しいブローカー リスナーを作成する

例: 2 つのポートを持つ新しいリスナーを作成する

サービスの種類

サービスの種類ごとに 1 つのリスナー

サービス名

Port

リスナー間で同じポートを使う

WebSocket のサポート

自動の証明書管理で TLS を構成する

cert-manager のインストールを確認する

TLS サーバー証明書の発行者を作成する

ルート証明書を Kubernetes シークレットとして設定する

ルート証明書を配布する

CA 証明書に基づいて発行者を作成する

ポートの TLS 自動証明書管理を有効にする

省略可能: サーバー証明書のパラメーターを構成する

デプロイの検証

TLS を使用してブローカーに接続する

既定のルート CA と発行者

手動の証明書管理で TLS を構成する

Step CLI を使用して証明機関を作成する

サーバー証明書を作成する

証明書キー アルゴリズムの要件

サーバー証明書チェーンを Kubernetes シークレットとしてインポートする

ポートの TLS 手動証明書管理を有効にする

TLS を使用してブローカーに接続する

サーバー証明書に対して外部 IP を使用する

関連するコンテンツ

フィードバック

その他のリソース

既定のブローカーリスナーを変更しない

新しいブローカーリスナーを作成する

証明書キーアルゴリズムの要件