Testen der Konnektivität mit Azure IoT MQ Vorschauversion mit MQTT-Clients
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.
In diesem Artikel werden verschiedene Möglichkeiten zum Testen der Konnektivität mit Azure IoT MQ (Vorschauversion) mit MQTT-Clients in einer Nichtproduktionsumgebung gezeigt.
Standardmäßig gilt für Azure IoT MQ (Vorschau):
Stellt einen TLS-fähigen Listener auf Port 8883 mit ClusterIp als Diensttyp bereit. ClusterIp bedeutet, dass der Broker nur über den Kubernetes-Cluster zugänglich ist. Um von außerhalb des Clusters auf den Broker zuzugreifen, müssen Sie einen Dienst vom Typ LoadBalancer oder NodePort konfigurieren.
Akzeptiert nur Kubernetes-Dienstkonten für die Authentifizierung für Verbindungen aus dem Cluster. Um eine Verbindung von außerhalb des Clusters herzustellen, müssen Sie eine andere Authentifizierungsmethode konfigurieren.
Achtung
Für Produktionsszenarien sollten Sie die TLS- und Dienstkontenauthentifizierung verwenden, um Ihre IoT-Lösung zu schützen. Weitere Informationen finden Sie unter:
- Konfigurieren von TLS mit automatischer Zertifikatverwaltung zum Schützen der MQTT-Kommunikation in Azure IoT MQ (Vorschau)
- Konfigurieren der Authentifizierung in Azure IoT MQ (Vorschau)
- Stellen Sie Kubernetes-Dienste für externe Geräte bereit, indem Sie die Portweiterleitung oder einen virtuellen Switch mit Azure Kubernetes Services Edge Essentials verwenden.
Bevor Sie beginnen, installieren Sie IoT-Vorgänge oder setzen Sie sie ein. Verwenden Sie die folgenden Optionen, um die Konnektivität zu IoT MQ mit MQTT-Clients in einer Nichtproduktionsumgebung zu testen.
Herstellen einer Verbindung von einem Pod innerhalb des Clusters mit Standardkonfiguration
Die erste Option besteht darin, eine Verbindung aus dem Cluster herzustellen. Diese Option verwendet die Standardkonfiguration und erfordert keine zusätzlichen Updates. Die folgenden Beispiele zeigen, wie eine Verbindung innerhalb des Clusters mit einfachem Alpine Linux und einem gängigen MQTT-Client unter Verwendung des Dienstkontos und des Standard-Root-ZS-Zertifikats hergestellt wird.
Erstellen Sie eine Datei namens „
client.yaml“ mit der folgenden Konfiguration:apiVersion: v1 kind: Pod metadata: name: mqtt-client # Namespace must match IoT MQ BrokerListener's namespace # Otherwise use the long hostname: aio-mq-dmqtt-frontend.azure-iot-operations.svc.cluster.local namespace: azure-iot-operations spec: # Use the "mqtt-client" service account which comes with default deployment # Otherwise create it with `kubectl create serviceaccount mqtt-client -n azure-iot-operations` serviceAccountName: mqtt-client containers: # Mosquitto and mqttui on Alpine - image: alpine name: mqtt-client command: ["sh", "-c"] args: ["apk add mosquitto-clients mqttui && sleep infinity"] volumeMounts: - name: mq-sat mountPath: /var/run/secrets/tokens - name: trust-bundle mountPath: /var/run/certs volumes: - name: mq-sat projected: sources: - serviceAccountToken: path: mq-sat audience: aio-mq # Must match audience in BrokerAuthentication expirationSeconds: 86400 - name: trust-bundle configMap: name: aio-ca-trust-bundle-test-only # Default root CA certVerwenden Sie
kubectl apply -f client.yaml, um die Konfiguration bereitzustellen. Der Startvorgang sollte nur ein paar Sekunden dauern.Sobald der Pod läuft, verwenden Sie
kubectl exec, um Befehle innerhalb des Pods auszuführen.Um beispielsweise eine Nachricht im Broker zu veröffentlichen, öffnen Sie eine Shell innerhalb des Pods:
kubectl exec --stdin --tty mqtt-client --namespace azure-iot-operations -- shFühren Sie innerhalb der Shell des Pods den folgenden Befehl aus, um eine Nachricht im Broker zu veröffentlichen:
mosquitto_pub --host aio-mq-dmqtt-frontend --port 8883 --message "hello" --topic "world" --username '$sat' --pw $(cat /var/run/secrets/tokens/mq-sat) --debug --cafile /var/run/certs/ca.crtDie Ausgabe sollte in etwa wie folgt aussehen:
Client (null) sending CONNECT Client (null) received CONNACK (0) Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes)) Client (null) sending DISCONNECTDer Mosquitto-Client verwendet das bei
/var/run/secrets/tokens/mq-sathinterlegte Dienstkontotoken zur Authentifizierung beim Broker. Das Token ist 24 Stunden lang gültig. Der Client verwendet auch das Standard-Root-ZS-Zertifikat, das auf/var/run/certs/ca.crtgespeichert ist, um die TLS-Zertifikatskette des Brokers zu überprüfen.Führen Sie zum Abonnieren des Themas den folgenden Befehl aus:
mosquitto_sub --host aio-mq-dmqtt-frontend --port 8883 --topic "world" --username '$sat' --pw $(cat /var/run/secrets/tokens/mq-sat) --debug --cafile /var/run/certs/ca.crtDie Ausgabe sollte in etwa wie folgt aussehen:
Client (null) sending CONNECT Client (null) received CONNACK (0) Client (null) sending SUBSCRIBE (Mid: 1, Topic: world, QoS: 0, Options: 0x00) Client (null) received SUBACK Subscribed (mid: 1): 0Der Mosquitto-Client verwendet dasselbe Dienstkontotoken und Root-ZS-Zertifikat, um sich beim Broker zu authentifizieren und das Thema zu abonnieren.
Sie können auch „mqttui“ verwenden, um mithilfe des Dienstkontotokens eine Verbindung mit dem Broker herzustellen. Das
--insecure-Flag ist erforderlich, da mqttui die Überprüfung der TLS-Zertifikatkette nicht mit einem benutzerdefinierten Root-ZS-Zertifikat unterstützt.Achtung
Die Verwendung von
--insecurewird für Produktionsszenarien nicht empfohlen. Verwenden Sie dies nur zu Test- oder Entwicklungszwecken.mqttui --broker mqtts://aio-mq-dmqtt-frontend:8883 --username '$sat' --password $(cat /var/run/secrets/tokens/mq-sat) --insecureFühren Sie zum Entfernen des Pods
kubectl delete pod mqtt-client -n azure-iot-operationsaus.
Verbinden Sie Clients von außerhalb des Clusters mit dem Standard-TLS-Port
TLS-Vertrauenskette
Da der Broker TLS verwendet, muss der Client der TLS-Zertifikatkette des Brokers vertrauen. Dazu müssen Sie den Client so konfigurieren, dass er dem vom Broker verwendeten Zertifikat der Stammzertifizierungsstelle vertraut.
Um das Standardzertifikat der Stammzertifizierungsstelle zu verwenden, laden Sie es aus der aio-ca-trust-bundle-test-only-ConfigMap herunter:
kubectl get configmap aio-ca-trust-bundle-test-only -n azure-iot-operations -o jsonpath='{.data.ca\.crt}' > ca.crt
Verwenden Sie die heruntergeladene ca.crt-Datei, um Ihren Client so zu konfigurieren, dass er der TLS-Zertifikatkette des Brokers vertraut.
Authentifizieren mit dem Broker
Standardmäßig akzeptiert IoT MQ nur Kubernetes-Dienstkonten für die Authentifizierung für Verbindungen aus dem Cluster. Um eine Verbindung von außerhalb des Clusters herzustellen, müssen Sie eine andere Authentifizierungsmethode wie X.509 oder Benutzername und Kennwort konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der Authentifizierung.
Das Deaktivieren der Authentifizierung dient nur zu Testzwecken
Um die Authentifizierung zu Testzwecken zu deaktivieren, bearbeiten Sie die BrokerListener-Ressource, und legen Sie das Feld authenticationEnabled auf false:
Achtung
Das Deaktivieren der Authentifizierung sollte nur zu Testzwecken mit einem Testcluster verwendet werden, auf den nicht über das Internet zugegriffen werden kann.
kubectl patch brokerlistener listener -n azure-iot-operations --type='json' -p='[{"op": "replace", "path": "/spec/authenticationEnabled", "value": false}]'
Portkonnektivität
Einige Kubernetes-Verteilungen können IoT MQ einem Port auf dem Hostsystem (localhost) zur Verfügung stellen. Sie sollten diese Vorgehensweise verwenden, da es für Clients auf demselben Host einfacher ist, auf IoT MQ zuzugreifen.
Um z. B. einen K3d-Cluster mit Zuordnung des standardmäßigen MQTT-Ports 8883 von IoT MQ zu localhost:8883 zu erstellen:
k3d cluster create --port '8883:8883@loadbalancer'
Damit diese Methode jedoch mit IoT MQ funktioniert, müssen Sie sie so konfigurieren, dass anstelle von Cluster-IP ein Lastenausgleichsmodul verwendet wird. Dazu gibt es zwei Möglichkeiten: Erstellen eines Lastenausgleichs oder Patchen des vorhandenen Standardressourcendiensttyps „BrokerListener“ zum Lastenausgleich.
Option 1: Erstellen eines Lastenausgleichs
Erstellen Sie eine Datei namens „
loadbalancer.yaml“ mit der folgenden Konfiguration:apiVersion: v1 kind: Service metadata: name: iotmq-public-svc spec: type: LoadBalancer ports: - name: mqtt1 port: 8883 targetPort: 8883 selector: app: broker app.kubernetes.io/instance: broker app.kubernetes.io/managed-by: dmqtt-operator app.kubernetes.io/name: dmqtt tier: frontendWenden Sie die Konfiguration an, um einen Lastenausgleichsdienst zu erstellen:
kubectl apply -f loadbalancer.yaml
Option 2: Patchen des Standardlastenausgleichs
Bearbeiten Sie die
BrokerListener-Ressource und ändern Sie das FeldserviceTypeinloadBalancer.kubectl patch brokerlistener listener --namespace azure-iot-operations --type='json' --patch='[{"op": "replace", "path": "/spec/serviceType", "value": "loadBalancer"}]'Warten Sie, bis der Dienst aktualisiert wird.
kubectl get service aio-mq-dmqtt-frontend --namespace azure-iot-operationsDie Ausgabe sollte in etwa wie folgt aussehen:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE aio-mq-dmqtt-frontend LoadBalancer 10.43.107.11 XXX.XX.X.X 8883:30366/TCP 14hSie können die externe IP-Adresse verwenden, um eine Verbindung mit IoT MQ über das Internet herzustellen. Stellen Sie sicher, dass Sie die externe IP-Adresse anstelle von
localhostverwenden.mosquitto_pub --qos 1 --debug -h XXX.XX.X.X --message hello --topic world --username client1 --pw password --cafile ca.crt
Tipp
Sie können die externe IP-Adresse verwenden, um eine Verbindung mit IoT MQ von außerhalb des Clusters herzustellen. Wenn Sie den K3d-Befehl mit der Option für die Portweiterleitung verwendet haben, können Sie localhost nutzen, um eine Verbindung mit IoT MQ herzustellen. So stellen Sie z. B. eine Verbindung mit dem mosquitto-Client her:
mosquitto_pub --qos 1 --debug -h localhost --message hello --topic world --username client1 --pw password --cafile ca.crt --insecure
In diesem Beispiel verwendet der Mosquitto-Client Benutzername und Kennwort für die Authentifizierung beim Broker gemeinsam mit dem Zertifikat der Stammzertifizierungsstelle, um die TLS-Zertifikatkette des Brokers zu überprüfen. Hier ist das --insecure-Flag erforderlich, da das standardmäßige TLS-Zertifikat, das für das Lastenausgleichsmodul ausgestellt wurde, nur für den Standarddienstnamen des Lastenausgleichs (aio-mq-dmqtt-frontend) und zugewiesene IPs und nicht für localhost gültig ist.
Machen Sie den IoT-MQ-Port niemals ohne Authentifizierung und TLS für das Internet zugänglich. Dies ist gefährlich und kann zu unbefugtem Zugriff auf Ihre IoT-Geräte führen und unerwünschten Datenverkehr zu Ihrem Cluster bringen.
Informationen zum Hinzufügen von Localhost zum alternativen Antragstellernamen (SAN) des Zertifikats, um die Verwendung des unsicheren Flags zu vermeiden, finden Sie unter Konfigurieren von Serverzertifikatparametern.
Verwenden der Portweiterleitung
Bei Minikube-, Kind- und anderen Clusteremulationssystemen wird möglicherweise keine externe IP automatisch zugewiesen. Sie kann z. B. als ausstehender Zustand angezeigt werden.
Um auf den Broker zuzugreifen, leiten Sie den Broker, der Port 8883 überwacht, an den Host weiter.
kubectl port-forward --namespace azure-iot-operations service/aio-mq-dmqtt-frontend 8883:mqtts-8883Verwenden Sie 127.0.0.1, um eine Verbindung mit dem Broker an Port 8883 mit derselben Authentifizierungs- und TLS-Konfiguration wie im Beispiel ohne Portweiterleitung herzustellen.
Portweiterleitung ist auch nützlich, um IoT MQ lokal auf Ihrem Entwicklungscomputer zu testen, ohne die Konfiguration des Brokers ändern zu müssen.
Weitere Informationen finden Sie unter Verwenden der Portweiterleitung für den Zugriff auf Anwendungen in einem Cluster für Minikube und im Abschnitt zum Bereitstellen von Kubernetes-Diensten für externe Geräte für Azure Kubernetes Services Edge Essentials.
Kein TLS und keine Authentifizierung
Der Grund dafür, dass IoT MQ standardmäßig TLS- und Dienstkontenauthentifizierung verwendet, besteht darin, eine sichere standardmäßige Erfahrung bereitzustellen, die die unbeabsichtigte Gefährdung Ihrer IoT-Lösung gegenüber Angreifern minimiert. Sie sollten TLS und Authentifizierung in der Produktion nicht deaktivieren.
Achtung
Nicht in der Produktion verwenden. Das Offenlegen von IoT MQ im Internet ohne Authentifizierung und TLS kann zu nicht autorisierten Zugriffen und sogar zu DDOS-Angriffen führen.
Wenn Sie die Risiken verstehen und einen unsicheren Port in einer gut kontrollierten Umgebung verwenden müssen, können Sie TLS und Authentifizierung zu Testzwecken wie folgt deaktivieren:
Erstellen Sie eine neue
BrokerListener-Ressource ohne TLS-Einstellungen:apiVersion: mq.iotoperations.azure.com/v1beta1 kind: BrokerListener metadata: name: non-tls-listener namespace: azure-iot-operations spec: brokerRef: broker serviceType: loadBalancer serviceName: my-unique-service-name authenticationEnabled: false authorizationEnabled: false port: 1883Die Felder
authenticationEnabledundauthorizationEnabledsind auffalsefestgelegt, dass Authentifizierung und Autorisierung deaktiviert werden. Das Feldportist auf1883festgelegt, sodass der gemeinsame MQTT-Port verwendet wird.Warten Sie, bis der Dienst aktualisiert wird.
kubectl get service my-unique-service-name --namespace azure-iot-operationsDie Ausgabe sollte in etwa wie folgt aussehen:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-unique-service-name LoadBalancer 10.43.144.182 XXX.XX.X.X 1883:31001/TCP 5m11sDer neue Port 1883 ist verfügbar.
Verwenden Sie mosquitto-Client, um eine Verbindung mit dem Broker herzustellen:
mosquitto_pub --qos 1 --debug -h localhost --message hello --topic worldDie Ausgabe sollte in etwa wie folgt aussehen:
Client mosq-7JGM4INbc5N1RaRxbW sending CONNECT Client mosq-7JGM4INbc5N1RaRxbW received CONNACK (0) Client mosq-7JGM4INbc5N1RaRxbW sending PUBLISH (d0, q1, r0, m1, 'world', ... (5 bytes)) Client mosq-7JGM4INbc5N1RaRxbW received PUBACK (Mid: 1, RC:0) Client mosq-7JGM4INbc5N1RaRxbW sending DISCONNECT
Zugehöriger Inhalt
Feedback
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 unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für