Freigeben über

Sichere MQTT-Brokerkommunikation mit BrokerListener

Wichtig

Diese Seite enthält Anweisungen zum Verwalten von Azure IoT Operations-Komponenten mithilfe von Kubernetes-Bereitstellungsmanifesten, die sich in der Vorschau befinden. Dieses Feature ist mit mehreren Einschränkungen versehen und sollte nicht für Produktionsworkloads verwendet werden.

Lesen Sie die ergänzenden Nutzungsbedingungen für Microsoft Azure Previews für rechtliche Bestimmungen, die für Azure-Features gelten, die sich in Der Betaversion, Vorschau oder auf andere Weise noch nicht in der allgemeinen Verfügbarkeit befinden.

Eine BrokerListener-Ressource entspricht einem Netzwerkendpunkt, der den Broker über das Netzwerk für Clients verfügbar macht. Sie können für jeden Broker eine oder mehrere BrokerListener-Ressourcen mit mehreren Ports und jeweils unterschiedlicher Zugriffssteuerung verwenden.

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

Tipp

Die standardmäßige MQTT-Brokerbereitstellung ist ein Cluster-IP-Dienst, bei dem Clients eine Verbindung mit dem TLS-Protokoll (Transport Layer Security) herstellen und sich mit Dienstkontotoken authentifizieren müssen. Clients, die sich von außerhalb des Clusters verbinden , benötigen zusätzliche Konfiguration , bevor sie eine Verbindung herstellen können.

Brokerlistener verfügen über die folgenden Merkmale:

Eine Liste aller verfügbaren Einstellungen finden Sie in der BrokerListener-API-Referenz.

Standard-BrokerListener

Wenn Sie Azure IoT Operations bereitstellen, erstellt die Bereitstellung eine BrokerListener-Ressource mit dem Namen "Standard". Dieser Listener wird für die verschlüsselte interne Kommunikation zwischen IoT Einsatz-Komponenten verwendet. Der Standardlistener ist Teil des Standardbrokers.

Vorsicht

Um die interne Kommunikation von IoT Einsatz nicht zu stören, lassen Sie den Standardlistener unverändert und für den internen Gebrauch reserviert. Erstellen Sie für die externe Kommunikation einen neuen Listener. Wenn Sie den ClusterIp-Dienst verwenden müssen, fügen Sie dem Standardlistener weitere Ports hinzu, ohne die vorhandenen Einstellungen zu ändern.

Führen Sie die folgenden Schritte aus, um den Standardlistener anzuzeigen oder zu bearbeiten:

  1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.

  2. Wählen Sie unter "Komponenten" den MQTT-Broker aus.

    Screenshot der Verwendung des Azure-Portals zum Anzeigen der Azure IoT Operations MQTT-Konfiguration.

  3. Wählen Sie in der Listenerliste des Brokers den Standardlistener aus.

    Screenshot der Verwendung des Azure-Portals zum Anzeigen oder Bearbeiten des Standardbrokerlisteners.

  4. Überprüfen Sie die Listenereinstellungen, aber ändern Sie keine der vorhandenen Einstellungen. Erstellen Sie stattdessen einen neuen Port, und konfigurieren Sie diesen nach Bedarf.

Vermeiden Sie es, den Standardbrokerlistener zu ändern.

Um die interne Kommunikation von IoT Einsatz nicht zu stören, lassen Sie den Standardlistener unverändert und für den internen Gebrauch reserviert. Erstellen Sie für die externe Kommunikation einen neuen Listener.

Da der Standardbrokerlistener den Diensttyp ClusterIpverwendet, und Sie können nur einen Listener pro Diensttyp verwenden, fügen Sie dem Standardlistener weitere Ports hinzu, ohne die vorhandenen Einstellungen zu ändern, wenn Sie den ClusterIp Dienst verwenden müssen.

Erstellen neuer Brokerlistener

Um einen neuen Listener zu erstellen, geben Sie die folgenden Einstellungen an:

Beispiel: Erstellen eines neuen Listeners mit zwei Ports

Dieses Beispiel zeigt, wie Sie einen neuen Listener mit dem Diensttyp LoadBalancer erstellen. Die BrokerListener-Ressource definiert zwei Ports, die MQTT-Verbindungen von Clients akzeptieren.

  1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.

  2. Wählen Sie unter "Komponenten" den MQTT-Broker aus.

  3. Wählen Sie den MQTT-Brokerlistener für LoadBalancer>Create aus.

    Geben Sie folgende Einstellungen ein.

    Einstellung BESCHREIBUNG
    Name Name der BrokerListener-Ressource.
    Dienstname Name des Kubernetes-Diensts Leer lassen, um den Listenernamen als Dienstnamen zu verwenden.
    Dienstart LoadBalancer bereits ausgewählt.

  4. Geben Sie unter "Ports" die folgenden Einstellungen für den ersten Port ein:

    Einstellung BESCHREIBUNG
    Hafen Geben Sie 1883 ein.
    Authentifizierung Wählen Sie "Keine" aus.
    Autorisierung Wählen Sie "Keine" aus.
    Protokoll Wählen Sie MQTT aus.
    TLS Fügen Sie nichts hinzu.

  5. Wählen Sie "Porteintrag hinzufügen" aus, um einen zweiten Port hinzuzufügen, und geben Sie die folgenden Einstellungen ein:

    Einstellung BESCHREIBUNG
    Hafen Geben Sie 8883 ein.
    Authentifizierung Wählen Sie "Standard" aus.
    Autorisierung Wählen Sie "Keine" aus.
    Protokoll Wählen Sie MQTT aus.
    TLS Wählen Sie "Hinzufügen" aus.

  6. Geben Sie im TLS-Konfigurationsbereich die folgenden Einstellungen ein:

    Einstellung BESCHREIBUNG
    TLS-Modus Wählen Sie "Automatisch" aus.
    Ausstellername Geben Sie azure-iot-operations-aio-certificate-issuer ein.
    Art des Ausstellers Wählen Sie "ClusterIssuer" aus.

    Übernehmen Sie für die anderen Einstellungen die Standardwerte, und wählen Sie dann Anwenden aus.

  7. Wählen Sie "Listener erstellen" aus.

    Screenshot, der die Verwendung des Azure-Portals zum Erstellen eines MQTT-Brokers für einen Load-Balancer-Listener zeigt.

Dienstart

Jede BrokerListener-Ressource ist einem Kubernetes-Dienst zugeordnet. Der Diensttyp bestimmt, wie der Broker für das Netzwerk verfügbar gemacht wird. Die unterstützten Diensttypen sind:

  • ClusterIp: Eröffnet den Zugriff auf den Broker über eine clusterinterne IP-Adresse. Clients können innerhalb des Clusters eine Verbindung mit dem Broker herstellen. Dieser Standarddiensttyp ist für den Standardlistener.
  • NodePort: Stellt den Dienst für die IP jedes Knotens an einem statischen Port zur Verfügung. Clients können von außerhalb des Clusters eine Verbindung mit dem Broker herstellen. Dieser Diensttyp ist für Entwicklungs- und Testzwecke nützlich.
  • LoadBalancer: Macht den Broker extern verfügbar. Dem Dienst wird eine externe IP-Adresse zugewiesen, mit der Clients eine Verbindung mit dem Broker herstellen können. Dieser Diensttyp ist der am häufigsten verwendete für Produktionsbereitstellungen.

Nur ein Listener pro Diensttyp

Pro Diensttyp ist nur ein Listener erlaubt. Wenn Sie mehr Konnektivität desselben Diensttyps benötigen, fügen Sie dem vorhandenen Listener dieses Diensttyps weitere Ports hinzu.

Dienstname

Der Dienstname ist der Name des Kubernetes-Dienstes, der mit dem Broker verbunden ist. Wenn nicht anders angegeben, wird der Name des Brokerlisteners als Dienstname verwendet. Der Dienstname muss innerhalb des Namensraums eindeutig sein.

Tipp

Um Verwaltungsmehraufwand zu vermeiden, sollten Sie den Dienstnamen leer lassen. Der Listenername ist eindeutig und kann verwendet werden, um den Dienst zu identifizieren. Verwenden Sie den Servicenamen nur dann als Überschreibung, wenn Sie den Dienst nicht nach dem Listener benennen können.

Häfen

Jeder Listener kann über mehrere Ports verfügen, und jeder Port kann über eigene Einstellungen für Authentifizierung, Autorisierung, Protokoll und TLS verfügen.

Um Ihre eigene Authentifizierungs- oder Autorisierungseinstellung für einen Port zu verwenden, müssen Sie die entsprechenden Ressourcen erstellen, bevor Sie sie mit einem Listener verwenden können. Weitere Informationen finden Sie unter MQTT-Broker-Authentifizierung konfigurieren und MQTT-Broker-Autorisierung konfigurieren.

Informationen zur Verwendung von TLS finden Sie unter "Konfigurieren von TLS mit automatischer Zertifikatverwaltung " oder " Konfigurieren von TLS mit manuellen Zertifikatverwaltungsabschnitten ".

Verwendung desselben Ports für alle Listener

Die Verwendung derselben Portnummer für verschiedene Listener wird nicht unterstützt. Jede Portnummer innerhalb des IoT Einsatz-MQTT-Brokers muss eindeutig sein.

Wenn Sie beispielsweise einen Listener mit Port 1883 verwenden, können Sie keinen weiteren Listener mit Port 1883 erstellen. Ebenso verwendet der Standardlistener Port 18883, sodass Sie keinen weiteren Listener mit Port 18883 erstellen können.

WebSockets-Unterstützung

Der IoT Einsatz-MQTT-Broker unterstützt MQTT über WebSockets. Um WebSockets zu aktivieren, legen Sie das Protokoll für den Port auf WebSockets fest.

Konfigurieren der TLS mit automatischer Zertifikatverwaltung

Um TLS mit der automatischen Zertifikatverwaltung zu aktivieren, geben Sie die TLS-Einstellungen für einen Listenerport an.

Überprüfen der Installation von cert-manager

Bei der automatischen Zertifikatverwaltung verwenden Sie den cert-manager, um das TLS-Serverzertifikat zu verwalten. Standardmäßig wird cert-manager bereits zusammen mit IoT Einsatz im cert-manager-Namespace installiert. Überprüfen Sie die Installation, bevor Sie den Vorgang fortsetzen.

  1. Verwenden Sie kubectl, um nach den Pods zu suchen, die den App-Bezeichnungen von cert-manager entsprechen.

    kubectl get pods --namespace cert-manager -l 'app in (cert-manager,cainjector,webhook)'

    NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

  2. Wenn die Pods als betriebsbereit und in Ausführung angezeigt werden, ist der cert-manager installiert und kann verwendet werden.

Tipp

Um die Installation weiter zu überprüfen, überprüfen Sie die Zertifikat-Manager-Dokumentation, um die Installation zu überprüfen. Denken Sie daran, den cert-manager-Namespace zu verwenden.

Erstellen eines Zertifikatausstellers für das TLS-Serverzertifikat

Die Zertifikatausstellerressource von cert-manager definiert, wie Zertifikate automatisch ausgestellt werden. Der Cert-Manager unterstützt verschiedene Ausstellertypen nativ. Die Anwendung unterstützt außerdem einen externenissuer-Typ, um die Funktionalität über die nativ unterstützten Zertifikataussteller hinaus zu erweitern. Der MQTT-Broker kann mit jedem cert-manager-Zertifikataussteller verwendet werden.

Wichtig

Während der Erstbereitstellung wird IoT Einsatz mit einem Standardzertifikataussteller für TLS-Serverzertifikate installiert. Sie können diesen Zertifikataussteller für Entwicklungs- und Testzwecke nutzen. Weitere Informationen finden Sie unter Standardstammzertifizierungsstelle und -zertifikataussteller in Azure IoT Einsatz. Die folgenden Schritte sind nur erforderlich, wenn Sie einen anderen Zertifikataussteller verwenden möchten.

Der Ansatz zum Erstellen des Zertifikatausstellers unterscheidet sich je nach Szenario. In den folgenden Abschnitten werden Beispiele aufgeführt, die Ihnen bei den ersten Schritten helfen.

Der Zertifikataussteller ist für Entwicklungs- und Testzwecke nützlich. Er muss mit einem Zertifikat und einem privaten Schlüssel konfiguriert werden, der in einem Kubernetes-Geheimnis gespeichert ist.

Einrichten eines Stammzertifikats als Kubernetes-Geheimnis

Wenn Sie über ein vorhandenes Signaturzertifikat verfügen, erstellen Sie ein Kubernetes-Geheimnis mit dem Signaturzertifikat und den privaten Zertifizierungsstellen-PEM-Schlüsseldateien. Führen Sie den folgenden Befehl aus, um das Signaturzertifikat als Kubernetes-Geheimnis zu importieren, und überspringen Sie den nächsten Abschnitt.

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

Wenn Sie kein Signaturzertifikat haben, kann cert-manager ein Signaturzertifikat für Sie generieren. Die Verwendung von „cert-manager“ zur Erstellung eines Signaturzertifikat wird als Bootstrapping eines Zertifikatausstellers mit einem selbstsignierten Zertifikat bezeichnet.

  1. Erstellen Sie zunächst ca.yaml:

    apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

  2. Erstellen Sie mit dem folgenden Befehl das selbstsignierte Zertifizierungsstellenzertifikat:

    kubectl apply -f ca.yaml

cert-manager erstellt ein ZS-Zertifikat mithilfe seiner Standardwerte. Die Eigenschaften dieses Zertifikats können durch Bearbeiten der Zertifikatsspezifikation geändert werden. Eine Liste der gültigen Optionen finden Sie in der Zertifikat-Manager-Dokumentation.

Verteilen des Stammzertifikats

Im vorherigen Beispiel wird das Zertifizierungsstellenzertifikat in einem Kubernetes-Geheimnis mit dem Namen test-ca gespeichert. Das Zertifikat im PEM-Format kann mit dem folgenden Befehl aus dem Geheimnis abgerufen und in der Datei ca.crt gespeichert werden:

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

Dieses Zertifikat muss von allen Clients verteilt und als vertrauenswürdig eingestuft werden. Verwenden Sie z. B. das --cafile-Flag für einen Mosquitto-Client.

Erstellen eines Zertifikatausstellers basierend auf einem Zertifizierungsstellenzertifikat

cert-manager benötigt einen Zertifikataussteller, der auf dem im vorherigen Schritt generierten oder importierten Zertifizierungsstellenzertifikat basiert. Erstellen Sie die folgende Datei als issuer-ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
  namespace: azure-iot-operations
spec:
  ca:
    # Must match secretName of generated or imported CA cert
    secretName: test-ca

Erstellen Sie den Zertifikataussteller mit dem folgenden Befehl:

kubectl apply -f issuer-ca.yaml

Der vorherige Befehl erstellt einen Zertifikataussteller für die Ausgabe von TLS-Serverzertifikaten. Notieren Sie sich den Namen und die Art des Zertifikatausstellers. Im Beispiel lautet der Name my-issuer und der Typ ist Issuer. Diese Werte werden später in der BrokerListener-Ressource festgelegt.

Aktivieren von TLS mit automatischer Zertifikatverwaltung für einen Port

Im Folgenden sehen Sie ein Beispiel für eine BrokerListener-Ressource, die TLS an Port 8884 mit automatischer Zertifikatverwaltung aktiviert.

  1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.

  2. Wählen Sie unter "Komponenten" den MQTT-Broker aus.

  3. Wählen Sie einen Listener aus oder erstellen Sie einen. Pro Diensttyp kann nur ein Listener erstellt werden. Wenn Sie bereits über einen Listener desselben Diensttyps verfügen, können Sie dem vorhandenen Listener weitere Ports hinzufügen.

  4. Sie können dem Listener TLS-Einstellungen hinzufügen, indem Sie TLS auf einem vorhandenen Port auswählen oder einen neuen Port hinzufügen.

    Screenshot der Verwendung des Azure-Portals zum Erstellen eines MQTT-Brokers für einen Lastenausgleichslistener mit automatischen TLS-Zertifikaten.

    Geben Sie folgende Einstellungen ein.

    Einstellung BESCHREIBUNG
    Name Name der BrokerListener-Ressource. Geben Sie aio-broker-loadbalancer-tls ein.
    Hafen Portnummer, auf welcher der BrokerListener auf MQTT-Verbindungen lauscht. Geben Sie 8884 ein.
    Authentifizierung Die Authentifizierungsressourcenreferenz.
    Autorisierung Der Autorisierungsressourcenverweis.
    TLS Wählen Sie die Schaltfläche "Hinzufügen " aus.
    Ausstellername Name des Ausstellers cert-manager. Erforderlich.
    Art des Ausstellers Art des Ausstellers cert-manager. Erforderlich.
    Ausstellergruppe Gruppe des Ausstellers cert-manager. Erforderlich.
    Privater Schlüsselalgorithmus Algorithmus für den privaten Schlüssel.
    Richtlinie für die Rotation privater Schlüssel Richtlinie für die Rotation des privaten Schlüssels.
    DNS-Namen Alternativer Name des DNS-Antragstellers für das Zertifikat.
    IP-Adressen IP-Adressen des alternativen Namens des DNS-Antragstellers für das Zertifikat.
    Geheimnisname Kubernetes-Schlüssel, der ein X.509-Clientzertifikat enthält.
    Dauer Die Gesamtlebensdauer des TLS-Serverzertifikats beträgt standardmäßig 90 Tage.
    Verlängern vor Wann die Verlängerung des Zertifikats beginnt.

  5. Klicken Sie auf Anwenden, um die TLS-Einstellungen zu speichern.

Nachdem die BrokerListener-Ressource konfiguriert wurde, erstellt der MQTT-Broker automatisch einen neuen Dienst mit dem angegebenen Port und aktivierter TLS.

Optional: Konfigurieren von Serverzertifikatparametern

Die einzig erforderlichen Parameter sind Issuer-Name und Issuer-Art. Alle andern Eigenschaften der generierten TLS-Serverzertifikate werden automatisch ausgewählt. Der MQTT-Broker ermöglicht jedoch die Anpassung bestimmter Eigenschaften nach der gleichen Syntax wie bei cert-manager-Zertifikaten. Sie können beispielsweise den Algorithmus für den privaten Schlüssel und die Rotationsrichtlinie angeben. Diese Einstellungen befinden sich unter tls.certManagerCertificateSpec oder im TLS-Konfigurationsbereich im Azure-Portal.

Eine vollständige Liste dieser Einstellungen finden Sie unter Broker Listener CertManagerCertificateSpec API Reference.

Überprüfen der Bereitstellung

Verwenden Sie kubectl, um zu überprüfen, ob der Dienst, der der BrokerListener-Ressource zugeordnet ist, ausgeführt wird. Im vorherigen Beispiel lautet der Dienstname aio-broker-loadbalancer-tls und der Namespace azure-iot-operations. Sie können den Dienststatus mithilfe des folgenden Befehls überprüfen:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
aio-broker-loadbalancer-tls    LoadBalancer   10.X.X.X        172.X.X.X     8884:32457/TCP   33s

Herstellen einer Verbindung mit dem Broker mit TLS

Nachdem das Serverzertifikat konfiguriert wurde, ist TLS aktiviert. So führen Sie den Test mit Mosquitto durch:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

Das Argument --cafile aktiviert TLS auf dem Mosquitto-Client und gibt an, dass der Client allen Serverzertifikaten vertrauen soll, die von der angegebenen Datei ausgestellt wurden. Sie müssen eine Datei angeben, die den Zertifikataussteller des konfigurierten TLS-Serverzertifikats enthält.

Ersetzen Sie $HOST durch den entsprechenden Host:

  • Wenn Sie eine Verbindung aus demselben Cluster herstellen, ersetzen Sie ihn durch den angegebenen Dienstnamen (my-new-tls-listener als Beispiel) oder den betreffenden Dienst CLUSTER-IP.
  • Wenn Sie eine Verbindung von außerhalb des Clusters herstellen, verwenden Sie den EXTERNAL-IP-Wert des Diensts.

Denken Sie daran, bei Bedarf Authentifizierungsmethoden anzugeben.

Standardstammzertifizierungsstelle und Aussteller

Um Ihnen die ersten Schritte zu erleichtern, wird IoT Einsatz mit einem standardmäßigen Schnellstart-Signaturzertifikat und -Zertifikataussteller für TLS-Serverzertifikate bereitgestellt. Sie können diesen Zertifikataussteller für Entwicklungs- und Testzwecke nutzen. Weitere Informationen finden Sie unter Standardstammzertifizierungsstelle und Aussteller für TLS-Serverzertifikate.

Für die Produktion müssen Sie einen Zertifizierungsstellenherausgeber mit einem Zertifikat einer vertrauenswürdigen Zertifizierungsstelle konfigurieren, wie in den vorherigen Abschnitten beschrieben wurde.

Konfigurieren von TLS mit manueller Zertifikatverwaltung

Um einen MQTT-Broker manuell für die Verwendung eines bestimmten TLS-Zertifikats zu konfigurieren, geben Sie das Zertifikat in einer BrokerListener-Ressource mit einem Verweis auf ein Kubernetes-Geheimnis an, und stellen Sie es mithilfe von kubectl bereit. Dieser Artikel zeigt ein Beispiel, das TLS mit selbstsignierten Zertifikaten zum Testen konfiguriert.

Erstellen einer Zertifizierungsstelle mithilfe von Step CLI

Schritt ist ein Zertifikat-Manager, der Sie schnell auf dem Laufenden halten kann, wenn Sie Ihre eigene private Zertifizierungsstelle erstellen und verwalten.

  1. Installieren Sie Step CLI, und erstellen Sie ein Zertifikat und einen Schlüssel der Stammzertifizierungsstelle.

    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 über die Zwischenzertifizierungsstelle und den zugehörigen Schlüssel 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 alternative Antragstellernamen (Subject Alternative Names, SANs) für das Front-End des MQTT-Brokers in Kubernetes bzw. auf lokalen Clients. Um eine Verbindung über das Internet herzustellen, fügen Sie eine --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, in der die Reihenfolge der Zertifikate wichtig ist. Das Serverzertifikat kommt an erster und das Zwischenzertifikat an zweiter Stelle in der Datei.

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

  2. Erstellen Sie mithilfe von kubectl ein Kubernetes-Geheimnis mit der Serverzertifikatkette 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 mit manueller Zertifikatverwaltung für einen Port

Im Folgenden sehen Sie ein Beispiel für eine BrokerListener-Ressource, die TLS an Port 8884 mit manueller Zertifikatverwaltung aktiviert.

  1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.

  2. Wählen Sie unter "Komponenten" den MQTT-Broker aus.

  3. Wählen Sie einen Listener aus oder erstellen Sie einen. Pro Diensttyp kann nur ein Listener erstellt werden. Wenn Sie bereits über einen Listener desselben Diensttyps verfügen, können Sie dem vorhandenen Listener weitere Ports hinzufügen. Um dem Beispiel zu folgen, geben Sie den Namen des Listener-Dienstes als mqtts-endpoint an.

  4. Sie können dem Listener TLS-Einstellungen hinzufügen, indem Sie TLS auf einem vorhandenen Port auswählen oder einen neuen Port hinzufügen.

    Screenshot, der die Nutzung des Azure-Portals zeigt, um einen MQTT-Broker für den Load-Balancer-Listener mit manuellen TLS-Zertifikaten zu erstellen.

    Geben Sie folgende Einstellungen ein.

    Einstellung BESCHREIBUNG
    Hafen Portnummer, auf welcher der BrokerListener auf MQTT-Verbindungen lauscht. Erforderlich.
    Authentifizierung Die Authentifizierungsressourcenreferenz.
    Autorisierung Der Autorisierungsressourcenverweis.
    TLS Wählen Sie die Schaltfläche "Hinzufügen " aus.
    Geheimnisname Kubernetes-Schlüssel, der ein X.509-Clientzertifikat enthält.

  5. Klicken Sie auf Anwenden, um die TLS-Einstellungen zu speichern.

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 Sie 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

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

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. Z. B. 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.

Um eine Verbindung mit dem Broker herzustellen, müssen Sie Stammvertrauensstellung, auch als Vertrauensbundle bezeichnet, an alle Clients verteilen. In diesem Fall ist der Vertrauensanker die von Step CLI erstellte selbstsignierte Stammzertifizierungsstelle. Die Verteilung der Stammvertrauensstellung ist erforderlich, damit der Client die Serverzertifikatkette überprüft. Wenn es sich bei Ihren MQTT-Clients um Workloads im Kubernetes-Cluster handelt, müssen Sie auch eine ConfigMap mit der Stammzertifizierungsstelle erstellen und in Ihren Pod einbinden.

Verwenden einer externen IP für das Serverzertifikat

Um eine Verbindung mit TLS über das Internet herzustellen, muss das Serverzertifikat des MQTT-Brokers einen externen Hostnamen oder eine IP-Adresse in Form eines alternativen Antragstellernamens (SAN) besitzen. In der Produktion ist diese Information in der Regel ein DNS-Name oder eine bekannte IP-Adresse. Während der Test-/Entwicklungsphase wissen Sie möglicherweise nicht, welcher Hostname oder welche externe IP-Adresse vor der Bereitstellung zugewiesen wurde. Um dieses Problem zu lösen, stellen Sie den Listener zuerst ohne das Serverzertifikat bereit, erstellen Sie das Serverzertifikat und das Geheimnis mit der externen IP, und importieren Sie das Geheimnis 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.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

Dieses Verhalten wird während des Serverzertifikatimports erwartet. In den Protokollen des Integritätsmanagers wird erwähnt, dass der MQTT-Broker 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.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

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

Verwandte Inhalte