Freigeben über

Sichere Azure IoT MQ-Vorschau-Kommunikation mit BrokerListener

  • Artikel

Wichtig

Die von Azure Arc aktivierte Azure IoT Operations Preview befindet sich derzeit in der VORSCHAU. Sie sollten diese Vorschausoftware nicht in Produktionsumgebungen verwenden.

Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Um den Netzwerkzugriff und die Sicherheit anzupassen, verwenden Sie die BrokerListener-Ressource. Ein Listener entspricht einem Netzwerkendpunkt, der den Broker für das Netzwerk verfügbar macht. Sie können für jede Brokerressource eine oder mehrere BrokerListener-Ressourcen und damit mehrere Ports mit jeweils unterschiedlicher Zugriffssteuerung verwenden.

Jeder Listener kann seine eigenen Authentifizierungs- und Autorisierungsregeln aufweisen, die festlegen, wer eine Verbindung mit dem Listener herstellen darf und welche Aktionen er mit dem Broker durchführen kann. Sie können die Ressourcen BrokerAuthentication und BrokerAuthorization verwenden, um die Richtlinien für die Zugriffssteuerung für jeden Listener anzugeben. Dank dieser Flexibilität können Sie die Berechtigungen und Rollen Ihrer MQTT-Clients je nach Bedarf und Anwendungsfall optimieren.

Die BrokerListener-Ressource weist folgende Felder auf:

Feldname Erforderlich Beschreibung
brokerRef Ja Der Name der Brokerressource, zu der dieser Listener gehört. Dieses Feld ist erforderlich und muss mit einer vorhandenen Brokerressource im selben Namespace übereinstimmen.
port Ja Die Portnummer, an der dieser Listener lauscht. Dieses Feld ist erforderlich und muss eine gültige TCP-Portnummer sein.
serviceType No Der Typ des Kubernetes-Diensts, der für diesen Listener erstellt wurde. Dieses Unterfeld ist optional und hat den Standardwert clusterIp. Muss entweder loadBalancer, clusterIp oder nodePort sein.
serviceName No Der Name des Kubernetes-Diensts, der für diesen Listener erstellt wurde. Kubernetes erstellt DNS-Einträge für diesen serviceName, die Clients zum Herstellen einer Verbindung mit IoT MQ verwenden sollten. Dieses Unterfeld ist optional und hat den Standardwert aio-mq-dmqtt-frontend. Wichtig: Wenn Sie mehrere Listener mit demselben und serviceName denselben serviceTypeListenern haben, verwenden die Listener denselben Kubernetes-Dienst. Weitere Informationen finden Sie unter Dienstname und Diensttyp.
authenticationEnabled No Ein boolesches Flag, das angibt, ob dieser Listener eine Authentifizierung von Clients erfordert. Wenn er auf true festgelegt ist, verwendet dieser Listener alle BrokerAuthentication-Ressourcen, die ihm zugeordnet sind, um die Clients zu überprüfen und zu autorisieren. Wenn dieser Listener auf false festgelegt ist, kann jeder Client eine Verbindung ohne Authentifizierung herstellen. Dieses Feld ist optional und hat den Standardwert false. Weitere Informationen zur Authentifizierung finden Sie unter Konfigurieren der Azure IoT MQ Preview-Authentifizierung.
authorizationEnabled No Ein boolesches Flag, das angibt, ob dieser Listener eine Autorisierung von Clients erfordert. Wenn er auf true festgelegt ist, verwendet dieser Listener alle BrokerAuthorization-Ressourcen, die ihm zugeordnet sind, um die Clients zu überprüfen und zu autorisieren. Wenn dieser Listener auf false festgelegt ist, kann jeder Client eine Verbindung ohne Authentifizierung herstellen. Dieses Feld ist optional und hat den Standardwert false. Weitere Informationen zur Autorisierung finden Sie unter Konfigurieren der Azure IoT MQ Preview-Autorisierung.
tls No Die TLS-Einstellungen für den Listener. Das Feld ist optional und kann ausgelassen werden, um TLS für den Listener zu deaktivieren. Legen Sie zum Konfigurieren von TLS einen der folgenden Typen fest:
* Bei Festlegung auf automatic verwendet dieser Listener den Zertifikat-Manager, um ein Zertifikat für den Listener abzurufen und zu erneuern. Um diesen Typ zu verwenden, geben Sie ein issuerRefFeld an, das auf den Zertifikat-Manager-Ausstellerverweist.
* Bei Festlegung auf manual verwendet der Listener ein manuell bereitgestelltes Zertifikat für den Listener. Geben Sie zum Verwenden dieses Typs ein secretName-Feld an, das auf eine geheime Kubernetes-Ressource verweist, die das Zertifikat und den privaten Schlüssel enthält.
* Bei Festlegung auf keyVault, verwendet der Listener ein Zertifikat aus Azure Key Vault. Um diesen Typ zu verwenden, geben Sie ein keyVaultFeld an, das auf die Azure Key Vault-Instanz und den geheimen Schlüsselverweist.
protocol No Das Protokoll, das dieser Listener verwendet. Dieses Feld ist optional und hat den Standardwert mqtt. Muss entweder mqtt oder websockets sein.

Standard-BrokerListener

Wenn Sie Azure IoT Einsatz bereitstellen, erstellt die Bereitstellung auch eine BrokerListener-Ressource namens listener im Namespace azure-iot-operations. Dieser Listener ist mit der standardmäßigen Brokerressource namens broker verknüpft, die ebenfalls bei der Bereitstellung erstellt wird. Der Standardlistener macht den Broker an Port 8883 mit aktivierter TLS- und SAT-Authentifizierung verfügbar. Das TLS-Zertifikat wird automatisch von cert-manager verwaltet. Die Autorisierung ist standardmäßig deaktiviert.

Führen Sie Folgendes aus, um den Listener zu überprüfen:

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

Die Ausgabe sollte wie folgt aussehen, wobei Metadaten aus Platzgründen entfernt wurden:

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

Weitere Informationen zur standardmäßigen BrokerAuthentication-Ressource, die mit diesem Listener verknüpft ist, finden Sie unter Standardmäßige BrokerAuthentication-Ressource.

Beispiel: Erstellen neuer BrokerListener-Instanzen

In diesem Beispiel wird gezeigt, wie Sie zwei neue BrokerListener-Ressourcen für eine Brokerressource namens my-broker erstellen. Jede BrokerListener- Ressource definiert einen Port und eine TLS-Einstellung für einen Listener, der MQTT-Verbindungen von Clients akzeptiert.

  • Der erste BrokerListener-Ressource mit dem Namen my-test-listener definiert einen Listener an Port 1883 ohne TLS und ohne Authentifizierung. Clients können ohne Verschlüsselung oder Authentifizierung eine Verbindung mit dem Broker herstellen.
  • Die zweite BrokerListener-Ressource mit dem Namen my-secure-listener definiert einen Listener an Port 8883 mit aktiviertem TLS und Authentifizierung. Nur authentifizierte Clients können eine Verbindung mit dem Broker mit TLS-Verschlüsselung herstellen. Das Feld tls ist auf automatic festgelegt, was bedeutet, dass der Listener „cert-manager“ verwendet, um sein Serverzertifikat abzurufen und zu erneuern.

Um diese BrokerListener-Ressourcen zu erstellen, wenden Sie dieses YAML-Manifest auf Ihren Kubernetes-Cluster an:

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

Dienstname und Diensttyp

Wenn Sie über mehrere BrokerListener-Ressourcen mit demselben und serviceName denselben serviceTypeRessourcen verfügen, verwenden die Ressourcen denselben Kubernetes-Dienst. Dies bedeutet, dass der Dienst alle Ports aller Listener verfügbar macht. Wenn Sie z. B. zwei Listener mit demselben serviceType und serviceName, eine auf Port 1883 und die andere auf Port 8883 haben, macht der Dienst beide Ports verfügbar. Clients können eine Verbindung mit dem Broker an beiden Ports herstellen.

Beim Namen des Freigabediensts müssen zwei wichtige Regeln beachtet werden:

  1. Listener mit demselben serviceType müssen dasselbe serviceName teilen.

  2. Listener mit unterschiedlichen Müssen unterschiedliche serviceTypeserviceNamehaben.

Insbesondere ist der Dienst für den Standardlistener auf Port 8883 und clusterIp benannt aio-mq-dmqtt-frontend. In der folgenden Tabelle wird zusammengefasst, was passiert, wenn Sie einen neuen Listener für einen anderen Port erstellen:

Neuer Listener serviceType Neuer Listener serviceName Ergebnis
clusterIp aio-mq-dmqtt-frontend Der neue Listener erstellt erfolgreich, und der Dienst macht beide Ports verfügbar.
clusterIp my-service Der neue Listener kann nicht erstellt werden, da der Diensttyp mit dem Standardlistener in Konflikt tritt.
loadBalancer oder nodePort aio-mq-dmqtt-frontend Der neue Listener kann nicht erstellt werden, da der Dienstname mit dem Standardlistener in Konflikt tritt.
loadBalancer oder nodePort my-service Der neue Listener erstellt erfolgreich und ein neuer Dienst wird erstellt.

Zugehöriger Inhalt