BrokerListener を使用して Azure IoT MQ (プレビュー) 通信をセキュリティで保護する
重要
Azure Arc によって有効にされる Azure IoT Operations Preview は、 現在プレビュー段階です。 運用環境ではこのプレビュー ソフトウェアを使わないでください。
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
ネットワーク アクセスとセキュリティをカスタマイズするには、BrokerListener リソースを使用します。 リスナーは、ブローカーをネットワークに公開するネットワーク エンドポイントに対応します。 Broker リソースごとに 1 つ以上の BrokerListener リソースを使用できるため、アクセス制御がそれぞれ異なる複数のポートを使用できます。
各リスナーには、リスナーに接続できるユーザーとブローカーで実行できるアクションを定義する独自の認証および承認規則を持つことができます。 BrokerAuthentication リソースと BrokerAuthorization リソースを使用して、各リスナーのアクセス制御ポリシーを指定できます。 この柔軟性により、MQTT クライアントのニーズとユース ケースに基づいて、MQTT クライアントのアクセス許可とロールを微調整できます。
BrokerListener リソースには、次のフィールドがあります。
| フィールド名 | 必須 | Description |
|---|---|---|
brokerRef |
はい | このリスナーが属するブローカー リソースの名前。 このフィールドは必須であり、同じ名前空間内の既存の Broker リソースと一致する必要があります。 |
port |
はい | このリスナーがリッスンするポート番号。 このフィールドは必須であり、有効な TCP ポート番号でなければなりません。 |
serviceType |
いいえ | このリスナー用に作成された Kubernetes サービスの種類。 このサブフィールドは省略可能で、既定値は clusterIp です。 loadBalancer、clusterIp または nodePort のいずれかである必要があります。 |
serviceName |
いいえ | このリスナー用に作成された Kubernetes サービスの名前。 Kubernetes は、クライアントが Azure IoT MQ (プレビュー) への接続に使用する serviceName のために、DNS レコードを作成します。 このサブフィールドは省略可能で、既定値は aio-mq-dmqtt-frontend です。 重要: 同じ serviceType と serviceName を持つ複数のリスナーがある場合、リスナーは同じ Kubernetes サービスを共有します。 詳細については、「サービス名とサービスの種類」を参照してください。 |
authenticationEnabled |
いいえ | このリスナーがクライアントからの認証を必要とするかどうかを示すブール値フラグ。 true に設定すると、このリスナーは、それに関連付けられている BrokerAuthentication リソースを使用して、クライアントを検証、認証します。 false に設定されている場合、このリスナーは、任意のクライアントが認証なしで接続できるようにします。 このフィールドは省略可能で、既定値は false です。 認証の詳細については、Azure IoT MQ プレビュー認証の構成に関するページを参照してください。 |
authorizationEnabled |
いいえ | このリスナーがクライアントからの認可を必要とするかどうかを示すブール値フラグ。 true に設定すると、このリスナーは、それに関連付けられている BrokerAuthorization リソースを使用して、クライアントを検証して許可します。 false に設定されている場合、このリスナーは、任意のクライアントが認可なしで接続できるようにします。 このフィールドは省略可能で、既定値は false です。 承認の詳細については、「Azure IoT MQ プレビュー認可を構成する」を参照してください。 |
tls |
いいえ | リスナーの TLS 設定。 フィールドは省略可能で、省略するとリスナーの TLS を無効できます。 TLS を構成するには、次のいずれかの種類を設定します。 * automatic に設定すると、このリスナーは cert-manager を使用してリスナーの証明書を取得および更新します。 この型を使用するには、cert-manager 発行者を参照する issuerRef フィールドを指定します。 * manual に設定すると、リスナーはリスナーに対して手動で指定された証明書を使用します。 この型を使用するには、証明書と秘密キーを含む Kubernetes シークレットを参照する secretName フィールドを指定します。 * keyVault に設定すると、リスナーは Azure Key Vault の証明書を使用します。 この種類を使用するには、Azure Key Vault インスタンスとシークレットを参照する keyVault フィールドを指定します。 |
protocol |
いいえ | このリスナーが使用するプロトコル。 このフィールドは省略可能で、既定値は mqtt です。 mqtt または websockets にする必要があります。 |
既定の BrokerListener
Azure IoT Operations (プレビュー) をデプロイすると、デプロイによって azure-iot-operations の名前空間に listener の名前が付けられた BrokerListener リソースも作成されます。 このリスナーは、デプロイ時にも作成される既定のブローカー リソース broker にリンクされます。 既定のリスナーは、TLS と SAT 認証が有効になっているポート 8883 でブローカーを公開します。 TLS 証明書は、cert-manager によって自動的に管理されます。 承認は既定で無効になっています。
リスナーを検査するには、次のコマンドを実行します。
kubectl get brokerlistener listener -n azure-iot-operations -o yaml
出力は次のようになります。簡潔にするために、ほとんどのメタデータが削除されています。
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
name: listener
namespace: azure-iot-operations
spec:
brokerRef: broker
authenticationEnabled: true
authorizationEnabled: false
port: 8883
serviceName: aio-mq-dmqtt-frontend
serviceType: clusterIp
tls:
automatic:
issuerRef:
group: cert-manager.io
kind: Issuer
name: mq-dmqtt-frontend
このリスナーにリンクされている既定の BrokerAuthentication リソースの詳細については、「既定の BrokerAuthentication リソース」をご覧ください。
新しい BrokerListeners の作成
この例では、my-broker という名前の Broker リソースに対して 2 つの新しい BrokerListener リソースを作成する方法を示します。 各 BrokerListener リソースは、クライアントからの MQTT 接続を受け入れるリスナーのポートと TLS 設定を定義します。
- my-test-listener という名前の最初の BrokerListener リソースは、TLS と認証をオフにせず、ポート 1883 でリスナーを定義します。 クライアントは、暗号化または認証なしでブローカーに接続できます。
- my-secure-listener という名前の 2 つ目の BrokerListener リソースは、TLS と認証が有効になっているポート 8883 でリスナーを定義します。 TLS 暗号化を使用してブローカーに接続できるのは、認証されたクライアントだけです。
tlsフィールドがautomaticの場合は、リスナーが cert-manager を使用してサーバー証明書を取得、更新することを意味します。
これらの BrokerListener リソースを作成するには、次の YAML マニフェストを Kubernetes クラスターに適用します。
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
name: my-test-listener
namespace: azure-iot-operations
spec:
authenticationEnabled: false
authorizationEnabled: false
brokerRef: broker
port: 1883
---
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
name: my-secure-listener
namespace: azure-iot-operations
spec:
authenticationEnabled: true
authorizationEnabled: false
brokerRef: broker
port: 8883
tls:
automatic:
issuerRef:
name: e2e-cert-issuer
kind: Issuer
group: cert-manager.io
サービス名とサービスの種類
重要: 同じ serviceType と serviceName を持つ複数の BrokerListener がある場合、それらのリソースは同じ Kubernetes サービスを共有します。 これは、サービスがすべてのリスナーのすべてのポートを公開することを意味します。 たとえば、同じ serviceType と serviceName を持つ 2 つのリスナーがあり、1 つはポート 1883 で、もう 1 つはポート 8883 にある場合、サービスは両方のポートを公開します。 クライアントは、どちらのポートでもブローカーに接続できます。
サービス名を共有するときは、次の 2 つの重要な規則に従う必要があります。
同じ
serviceTypeを持つリスナーは、同じserviceNameを共有する必要があります。異なる
serviceTypeを持つリスナーは、異なるserviceNameを持つ必要があります。
特に、ポート 8883 の既定のリスナーのサービスは clusterIp であり、aio-mq-dmqtt-frontend という名前付けられます。 次の表は、別のポートで新しいリスナーを作成した場合の動作をまとめたものです。
新しいリスナー serviceType |
新しいリスナー serviceName |
結果 |
|---|---|---|
clusterIp |
aio-mq-dmqtt-frontend |
新しいリスナーが正常に作成され、サービスは両方のポートを公開します。 |
clusterIp |
my-service |
サービスの種類が既定のリスナーと競合するため、新しいリスナーの作成に失敗します。 |
loadBalancer または nodePort |
aio-mq-dmqtt-frontend |
サービス名が既定のリスナーと競合するため、新しいリスナーの作成に失敗します。 |
loadBalancer または nodePort |
my-service |
新しいリスナーが正常に作成され、新しいサービスが作成されます。 |