Freigeben über

Konfigurieren von TLS mit manueller Zertifikatverwaltung zum Schützen der MQTT-Kommunikation in Azure IoT MQ (Vorschau)

  • 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.

Sie können TLS mit einer BrokerListener-Ressource konfigurieren, um die MQTT-Kommunikation zwischen MQTT-Broker und -Client zu sichern. Sie können TLS mit manueller oder automatischer Zertifikatverwaltung konfigurieren.

Um Azure IoT MQ (Vorschau) manuell für die Verwendung eines bestimmten TLS-Zertifikats zu konfigurieren, geben Sie es in einer BrokerListener-Ressource mit einem Verweis auf ein Kubernetes-Geheimnis an. Stellen Sie diese dann mithilfe von kubectl bereit. In diesem Artikel wird ein Beispiel zum Konfigurieren von TLS mit selbstsignierten Zertifikaten zu Testzwecken gezeigt.

Erstellen einer Zertifizierungsstelle mit Step CLI

Step ist ein Zertifikatmanager, der es Ihnen ermöglicht, einfach und schnell Ihre eigene private ZS zu erstellen und zu verwalten.

  1. Installieren Sie Step CLI und erstellen Sie ein Stammzertifizierungsstellenzertifikat und einen -schlüssel.

    step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key

  2. Erstellen Sie ein Zwischenzertifizierungsstellenzertifikat und einen -schlüssel, der von der Stammzertifizierungsstelle signiert ist.

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

Erstellen eines Serverzertifikats

Verwenden Sie Step CLI, um ein Serverzertifikat aus der Zwischenzertifizierungsstelle zu erstellen.

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

Hier sind mqtts-endpoint und localhost die alternativen Antragstellernamen (Subject Alternative Names, SANs) für das Broker-Frontend von Azure IoT MQ in Kubernetes bzw. lokalen Clients. Um eine Verbindung über das Internet herzustellen, fügen Sie einen --san mit einer externen IP hinzu. Die --no-password --insecure-Flags werden zum Testen verwendet, um Eingabeaufforderungen für Kennwörter zu überspringen und den Kennwortschutz für den privaten Schlüssel zu deaktivieren, da er in einem Kubernetes-Geheimnis gespeichert ist. Verwenden Sie für die Produktion ein Kennwort, und speichern Sie den privaten Schlüssel an einem sicheren Ort wie Azure Key Vault.

Anforderungen an den Zertifikatschlüsselalgorithmus

Sowohl EC- als auch RSA-Schlüssel werden unterstützt, es müssen aber alle Zertifikate in der Kette denselben Schlüsselalgorithmus verwenden. Wenn Sie eigene Zertifizierungsstellenzertifikate importieren, stellen Sie sicher, dass das Serverzertifikat denselben Schlüsselalgorithmus wie die Zertifizierungsstellen verwendet.

Importieren einer Serverzertifikatkette als Kubernetes-Geheimnis

  1. Erstellen Sie eine vollständige Serverzertifikatkette, bei der die Reihenfolge der Zertifikate wichtig ist: Das Serverzertifikat ist das erste in der Datei, das Zwischenzertifikat ist das zweite.

    cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.pem

  2. Erstellen Sie mithilfe von kubectl ein Kubernetes-Geheimnis mit der Zertifikatkette und dem Serverschlüssel.

    kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key

Aktivieren von TLS für einen Listener

Ändern Sie die tls-Einstellung in einer BrokerListener-Ressource, um die manuelle TLS-Konfiguration anzugeben, die auf das Kubernetes-Geheimnis verweist. Notieren Sie sich den Namen des Geheimnisses, das für das TLS-Serverzertifikat verwendet wird (server-cert-secret im vorherigen Beispiel).

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: manual-tls-listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  authenticationEnabled: false # If true, BrokerAuthentication must be configured
  authorizationEnabled: false
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  port: 8885 # Avoid port conflict with default listener at 8883
  tls:
    manual:
      secretName: server-cert-secret

Nachdem die BrokerListener-Ressource erstellt wurde, erstellt der Operator automatisch einen Kubernetes-Dienst und stellt den Listener bereit. Sie sollten den Status des Diensts überprüfen, indem Sie kubectl get svc ausführen.

Herstellen einer Verbindung mit dem Broker mit TLS

Um die TLS-Verbindung mit dem Mosquitto Client zu testen, veröffentlichen Sie eine Nachricht und übergeben das Zertifikat der Stammzertifizierungsstelle im Parameter --cafile.

$ mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt
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

Tipp

Um localhost zu verwenden, muss der Port auf dem Hostcomputer verfügbar sein. Beispiel: kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Bei einigen Kubernetes-Verteilungen wie K3d können Sie mit k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer einen weitergeleiteten Port hinzufügen.

Hinweis

Um eine Verbindung mit dem Broker herzustellen, müssen Sie Stammvertrauensstellung, auch als Vertrauensbundle bezeichnet, an die Clients verteilen. In diesem Fall ist die Stammvertrauensstellung die im Schritt „CLI“ erstellte selbstsignierte Stammzertifizierungsstelle. Die Verteilung der Stammvertrauensstellung ist erforderlich, damit der Client die Serverzertifikatkette überprüft. Wenn Ihre MQTT-Clients Workloads im Kubernetes-Cluster sind, müssen Sie auch eine ConfigMap mit der Stammzertifizierungsstelle erstellen und in Ihrem Pod bereitstellen.

Denken Sie daran, den Benutzernamen, das Kennwort usw. anzugeben, wenn die MQ-Authentifizierung aktiviert ist.

Verwenden einer externen IP für das Serverzertifikat

Um eine Verbindung mit TLS über das Internet herzustellen, muss das Serverzertifikat von Azure IoT MQ einen externen Hostnamen in Form eines alternativen Antragstellernamens haben. In der Produktion ist dies in der Regel ein DNS-Name oder eine gut bekannte IP-Adresse. Während Dev/Test wissen Sie möglicherweise jedoch nicht, welchen Hostnamen oder welche externe IP vor der Bereitstellung zugewiesen wird. Um dieses Problem zu lösen, stellen Sie den Listener zuerst ohne das Serverzertifikat bereit. Dann erstellen Sie das Serverzertifikat und das Geheimnis mit der externen IP. Schließlich importieren Sie den geheimen Schlüssel in den Listener.

Wenn Sie versuchen, den TLS-Listener manual-tls-listener des Beispiels bereitzustellen, das referenzierte Kubernetes-Geheimnis server-cert-secret aber nicht vorhanden ist, wird der zugeordnete Dienst zwar erstellt, die Pods werden jedoch nicht gestartet. Der Dienst wird erstellt, da der Operator die externe IP für den Listener reservieren muss.

$ kubectl get svc mqtts-endpoint -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.43.93.6      172.18.0.2    8885:30674/TCP      1m15s

Dieses Verhalten ist jedoch erwartbar, und kann während des Importieren des Serverzertifikats ignoriert werden. In den Protokollen des Integritäts-Managers wird erwähnt, dass Azure IoT MQ auf das Serverzertifikat wartet.

$ 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.

Hinweis

Im Allgemeinen sind Pods-Protokolle in einem verteilten System nicht deterministisch und sollten mit Vorsicht verwendet werden. Die richtige Art für das Auftauchen solcher Informationen besteht in Kubernetes-Ereignissen und dem benutzerdefiniertem Ressourcenstatus, der sich im Backlog befindet. Betrachten Sie den vorherigen Schritt als vorübergehende Problemumgehung.

Auch wenn die Front-End-Pods nicht gestartet sind, ist die externe IP bereits verfügbar.

$ kubectl get svc mqtts-endpoint -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.43.93.6      172.18.0.2    8885:30674/TCP      1m15s

Führen Sie hier die gleichen Schritte wie zuvor aus, um auf dieselbe Weise ein Serverzertifikat mit dieser externen IP in --san und das Kubernetes-Geheimnis zu erstellen. Nachdem der geheime Schlüssel erstellt wurde, wird er automatisch in den Listener importiert.

Zugehöriger Inhalt