Sichere Azure IoT MQ-Vorschau-Kommunikation mit BrokerListener
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 serviceType Listenern 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 issuerRef Feld 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 keyVault Feld 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 aufautomatic
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 serviceType
Ressourcen 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:
Listener mit demselben
serviceType
müssen dasselbeserviceName
teilen.Listener mit unterschiedlichen Müssen unterschiedliche
serviceType
serviceName
haben.
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
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für