Freigeben über

Sichere MQTT-Broker-Kommunikation mit BrokerListener

  • Artikel

Wichtig

Die von Azure Arc unterstützte Vorschauversion von „Azure IoT Einsatz“ befindet sich derzeit in der Vorschauphase. Sie sollten diese Vorschausoftware nicht in Produktionsumgebungen verwenden.

Sie müssen eine neue Installation von Azure IoT Einsatz bereitstellen, sobald eine allgemein verfügbare Version verfügbar ist. Sie werden kein Upgrade für eine Preview-Installation durchführen können.

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 Broker-Ressource eine oder mehrere BrokerListener-Ressourcen und damit mehrere Ports mit jeweils unterschiedlicher Zugriffssteuerung verwenden.

Jeder Listenerport kann seine eigenen Authentifizierungs- und Autorisierungsregeln aufweisen, die festlegen, wer eine Verbindung mit dem Listener herstellen darf und welche Aktionen mit dem Broker durchgeführt werden können. 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.

Tipp

Sie können nur auf die MQTT-Broker-Standardbereitstellung zugreifen, indem Sie die Cluster-IP-Adresse, TLS und ein Dienstkontotoken verwenden. Clients, die sich von außerhalb des Clusters verbinden, benötigen eine zusätzliche Konfiguration, bevor sie eine Verbindung herstellen können.

Listener verfügen über die folgenden Merkmale:

  • Sie können maximal drei Listener verwenden. Ein Listener pro Diensttyp loadBalancer, clusterIp oder nodePort. Der standardmäßige BrokerListener mit dem Namen Standard ist ein Diensttyp clusterIp.
  • Jeder Listener unterstützt mehrere Ports.
  • BrokerAuthentication- und BrokerAuthorization-Verweise gelten pro Port
  • TLS-Konfiguration ist portspezifisch
  • Namen für Dienste müssen eindeutig sein
  • Ports können nicht mit verschiedenen Listenern in Konflikt geraten

Eine Liste der verfügbaren Einstellungen finden Sie in der API-Referenz zum Broker-Listener.

Standard-BrokerListener

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

So zeigen Sie den Listener an oder bearbeiten ihn:

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

  2. Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.

    Screenshot der Verwendung des Azure-Portals zum Anzeigen der MQTT-Konfiguration für Azure IoT Einsatz.

  3. Wählen Sie in der Liste der Brokerlistener den Standard-Listener aus.

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

  4. Überprüfen Sie die Listenereinstellungen, und nehmen Sie bei Bedarf Änderungen vor.

Erstellen neuer Brokerlistener

In diesem Beispiel wird gezeigt, wie Sie eine neue BrokerListener-Ressource mit dem Namen Loadbalancer-Listener für eine Broker-Ressource erstellen. Die BrokerListener-Ressource definiert zwei Ports, die MQTT-Verbindungen von Clients akzeptieren.

  • Der erste Port überwacht Port 1883 ohne TLS und Authentifizierung. Clients können ohne Verschlüsselung oder Authentifizierung eine Verbindung mit dem Broker herstellen.
  • Der zweite Port überwacht Port 18883 mit TLS und Authentifizierung. Nur authentifizierte Clients können eine Verbindung mit dem Broker mit TLS-Verschlüsselung herstellen. TLS ist auf automatic festgelegt, was bedeutet, dass der Listener „cert-manager“ verwendet, um sein Serverzertifikat abzurufen und zu erneuern.

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

  2. Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.

  3. Wählen Sie MQTT-Brokerlistener für LoadBalancer>Erstellen aus. Sie können nur einen Listener pro Diensttyp erstellen. Wenn Sie bereits über einen Listener desselben Diensttyps verfügen, können Sie dem vorhandenen Listener weitere Ports hinzufügen.

    Screenshot der Verwendung des Azure-Portals zum Erstellen des MQTT-Brokers für den Load Balancer-Listener.

    Geben Sie folgende Einstellungen ein:

    Einstellung BESCHREIBUNG
    Name Name der BrokerListener-Ressource.
    Dienstname Name des Kubernetes-Diensts, der dem BrokerListener zugeordnet ist.
    Diensttyp Typ des Brokerdiensts, z. B. LoadBalancer, NodePort oder ClusterIP.
    Port Portnummer, auf welcher der BrokerListener auf MQTT-Verbindungen lauscht.
    Authentifizierung Der Authentifizierungsressourcenverweis.
    Autorisierung Der Autorisierungsressourcenverweis.
    TLS Gibt an, ob TLS für die sichere Kommunikation aktiviert ist. Kann auf automatisch oder manuell festgelegt werden.

  4. Wählen Sie Listener erstellen aus.

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 Azure IoT Einsatz Preview im azure-iot-operations-Namespace installiert. Überprüfen Sie die Installation, bevor Sie fortfahren.

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

    kubectl get pods --namespace azure-iot-operations -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 genauer zu überprüfen, sehen Sie sich die Dokumentation Überprüfen der Installation für cert-manager an. Denken Sie daran, den azure-iot-operations-Namespace zu verwenden.

Erstellen eines Zertifikatausstellers für das TLS-Serverzertifikat

Die Ressource Aussteller von cert-manager definiert, wie Zertifikate automatisch ausgestellt werden. cert-manager unterstützt nativ mehrere Zertifikatausstellertypen. Die Anwendung unterstützt außerdem einen externen Zertifikatausstellertyp, 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 ersten Bereitstellung wird Azure IoT Operations 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 Operations. 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 Zertifizierungsstellenzertifikat verfügen, erstellen Sie ein Kubernetes-Geheimnis mit dem Zertifizierungsstellenzertifikat und den privaten PEM-Schlüsseldateien. Führen Sie den folgenden Befehl aus. Dadurch haben Sie das Stammzertifikat als Kubernetes-Geheimnis eingerichtet und können den nächsten Abschnitt überspringen.

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

Wenn Sie nicht über ein Zertifizierungsstellenzertifikat verfügen, kann cert-manager ein Zertifikat der Stammzertifizierungsstelle für Sie generieren. Die Verwendung von cert-manager zum Generieren eines Zertifikats der Stammzertifizierungsstelle 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 Zertifizierungsstellenzertifikat 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 Dokumentation von cert-manager.

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 aus dem Geheimnis abgerufen und mit dem folgenden Befehl in einer ca.crt-Datei 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 der TLS-Serverzertifikate. Notieren Sie sich den Namen und die Art des Zertifikatausstellers. Im Beispiel lauten der Name my-issuer und die Art 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 auf Port 8884 mit automatischer Zertifikatverwaltung aktiviert.

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

  2. Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.

  3. Wählen Sie einen Listener aus oder erstellen Sie einen. Sie können nur einen Listener pro Diensttyp erstellen. 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 des Azure-Portals bei der Erstellung des MQTT-Brokers für den Load Balancer-Listener mit automatischen TLS-Zertifikaten.

    Geben Sie folgende Einstellungen ein:

    Einstellung BESCHREIBUNG
    Port Portnummer, auf welcher der BrokerListener auf MQTT-Verbindungen lauscht. Erforderlich.
    Authentifizierung Der Authentifizierungsressourcenverweis.
    Autorisierung Der Autorisierungsressourcenverweis.
    TLS Wählen Sie die Schaltfläche Hinzufügen aus.
    Issuer name 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.
    Duration Die insgesamte Lebensdauer des TLS-Serverzertifikats beträgt standardmäßig 90 Tage.
    Verlängern vor Wann die Verlängerung des Zertifikats beginnt.

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

Herstellen einer Verbindung mit dem Broker mit TLS

Nachdem das Serverzertifikat konfiguriert wurde, ist TLS aktiviert. So testen Sie es mit mosquitto:

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 eine Verbindung innerhalb desselben Clusters hergestellt wird, ersetzen Sie den Wert durch den vergebenen Dienstnamen (im Beispiel my-new-tls-listener) oder den CLUSTER-IP-Dienst.
  • Wenn eine Verbindung von außerhalb des Clusters hergestellt wird, verwenden Sie den EXTERNAL-IP-Dienst.

Denken Sie daran, bei Bedarf Authentifizierungsmethoden anzugeben.

Standardstammzertifizierungsstelle und Aussteller

Um Ihnen den Einstieg zu erleichtern, wird Azure IoT Operations mit einer standardmäßigen „Schnellstart“-Stammzertifizierungsstelle und einem -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 den MQTT-Broker 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 Front-End des MQTT-Brokers 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.crt

  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 mit manueller Zertifikatverwaltung für einen Port

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

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

  2. Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.

  3. Wählen Sie einen Listener aus oder erstellen Sie einen. Sie können nur einen Listener pro Diensttyp erstellen. 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 des Azure-Portals bei der Erstellung des MQTT-Brokers für den Load Balancer-Listener mit manuellen TLS-Zertifikaten.

    Geben Sie folgende Einstellungen ein:

    Einstellung BESCHREIBUNG
    Port Portnummer, auf welcher der BrokerListener auf MQTT-Verbindungen lauscht. Erforderlich.
    Authentifizierung Der Authentifizierungsressourcenverweis.
    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 Speichern, 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 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 MQTT-Broker-Authentifizierung aktiviert ist.

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 in Form eines alternativen Antragstellernamens (SAN) besitzen. 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.X.X.X        172.X.X.X     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 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 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