Sichere MQTT-Broker-Kommunikation mit BrokerListener

Artikel
11/21/2024

Wichtig

Diese Seite enthält Anweisungen zum Verwalten der Komponenten von „Azure IoT Einsatz“ mithilfe von Kubernetes-Bereitstellungsmanifesten. Diese Option befindet sich in der Vorschau. Dieses Feature wird mit einigen Einschränkungen bereitgestellt und sollte nicht für Produktionsworkloads verwendet werden.

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.

Ein BrokerListener 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 die Ressourcen BrokerAuthentication und BrokerAuthorization verwenden, um die Richtlinien für die Zugriffssteuerung für jeden Listener-Port 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-Broker-Bereitstellung ist ein Cluster-IP-Dienst, bei dem Clients eine Verbindung mit TLS herstellen und sich mit Dienstkontotoken authentifizieren müssen. Clients, die sich von außerhalb des Clusters verbinden, benötigen eine zusätzliche Konfiguration, bevor sie sich verbinden können.

Brokerlistener verfügen über die folgenden Merkmale:

Name: Name des Listeners Dieser Name ist auch der Kubernetes-Dienstname, sofern er nicht überschrieben wird.
Diensttyp: Sie können bis zu drei Listener haben, eine pro Diensttyp. Der Standardlistener ist der Diensttyp ClusterIp.
Ports: Jeder Listener unterstützt mehrere Ports. Ports können nicht mit verschiedenen Listenern in Konflikt geraten.
Authentifizierungs- und Autorisierungsverweise: BrokerAuthentication und BrokerAuthorization werden pro Port konfiguriert.
TLS-: Manuelle oder automatische TLS-Konfiguration wird pro Port angewendet.
Protokoll: MQTT über WebSockets können pro Port aktiviert werden.

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

Standard-BrokerListener

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

Er macht einen ClusterIp-Dienst auf Port 18883 verfügbar.
Er erfordert, dass Clients Kubernetes-Dienstkontoauthentifizierung verwenden.
Er verfügt über ein automatisch verwaltetes TLS-Zertifikat.
Er konfiguriert keine Clientautorisierungsrichtlinien.

Achtung

Um die interne Kommunikation von Azure 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.

So zeigen Sie den Standardlistener an oder bearbeiten ihn:

Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.
Wählen Sie in der Liste der Brokerlistener den Standard-Listener aus.
Überprüfen Sie die Listenereinstellungen, aber ändern Sie keine der vorhandenen Einstellungen. Erstellen Sie stattdessen einen neuen Port, und konfigurieren Sie diesen nach Bedarf.

Seien Sie vorsichtig, wenn Sie den Standardlistener mit Bicep ändern. Ändern Sie die vorhandenen Einstellungen nicht. Fügen Sie stattdessen dem Standardlistener weitere Ports hinzu. Das folgende Beispiel zeigt, wie Sie dem Standardlistener einen neuen Port hinzufügen.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-09-15-preview' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-09-15-preview' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-09-15-preview' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    // Don't change the service name or service type
    serviceType: 'ClusterIp'
    serviceName: 'aio-broker'
    ports: [
      // Don't modify the default port 18883 settings
      {
        port: 18883
        authenticationRef: 'default'
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
            privateKey: {
              algorithm: 'Ec256'
              rotationPolicy: 'Always'
            }
          }
        }
      }
      // Add more ports here, like the following example
      {
        port: 1884
        protocol: 'Mqtt'
      }
    ]
  }
}

Stellen Sie die Bicep-Datei mithilfe der Azure CLI bereit.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Verwenden Sie den folgenden Befehl, um die standardmäßige BrokerListener-Ressource anzuzeigen:

kubectl get brokerlistener default -n azure-iot-operations -o yaml

Die Ausgabe sollte in etwa so aussehen, wobei Metadaten aus Platzgründen entfernt wurden:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: default
  namespace: azure-iot-operations
  ownerReferences:
  - apiVersion: mqttbroker.iotoperations.azure.com/v1
    kind: Broker
    name: default
spec:
  serviceType: ClusterIp
  serviceName: aio-broker
  ports:
  - port: 18883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: azure-iot-operations-aio-certificate-issuer
          kind: ClusterIssuer
          group: cert-manager.io
        privateKey:
          algorithm: Ec256
          rotationPolicy: Always

Um dem Standardlistener einen neuen Port 1883 ohne TLS und Authentifizierung hinzuzufügen, verwenden Sie den Befehl kubectl patch:

kubectl patch brokerlistener default -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/-", "value": {"port": 1883, "protocol": "Mqtt"}}]'

Vermeiden Sie es, den Standardbrokerlistener zu ändern.

Da der Standardbrokerlistener den Diensttyp ClusterIp verwendet und Sie nur einen Listener pro Diensttyp haben können, 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:

Name: Name des Listeners Dieser Name ist auch der Kubernetes-Dienstname, sofern er nicht überschrieben wird.
Diensttyp: Typ des Kubernetes-Dienstes Weitere Informationen finden Sie unter Diensttyp.
Ports: Liste der Ports, die überwacht werden sollen. Siehe Ports.
(Optional) Dienstname: Überschreibt den Kubernetes-Dienstnamen Weitere Informationen finden Sie unter Dienstname.

Beispiel: Erstellen eines neuen Listeners mit zwei Ports

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

Der erste Port überwacht Port 1883 ohne TLS und Authentifizierung. Diese Einrichtung eignet sich nur für Tests. Verwenden Sie diese Konfiguration nicht in der Produktion.
Der zweite Port überwacht Port 8883 mit TLS und Authentifizierung. Nur authentifizierte Clients mit einem Kubernetes-Dienstkontotoken können eine Verbindung herstellen. TLS ist auf automatischen Modus festgelegt, wobei der Zertifikat-Manager zum Verwalten des Serverzertifikats vom Standardaussteller verwendet wird. Dieses Setup ist näher an einer Produktionskonfiguration.

Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.

Wählen Sie MQTT-Brokerlistener für LoadBalancer>Erstellen 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.
Diensttyp	LoadBalancer ist bereits ausgewählt.

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

Einstellung	BESCHREIBUNG
Port	Geben Sie 1883 ein.
Authentifizierung	Wählen Sie die Option Keine aus.
Autorisierung	Wählen Sie die Option Keine aus.
Protokoll	Wählen Sie MQTT aus.
TLS	Nicht hinzufügen

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

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

Geben Sie im Bereich TLS-Konfiguration erstellen die folgenden Einstellungen ein:

Einstellung Beschreibung

TLS-Modus Wählen Sie Automatisch aus.

Issuer name 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.
Wählen Sie Listener erstellen aus.

Einstellung	Beschreibung
TLS-Modus	Wählen Sie Automatisch aus.
Issuer name	Geben Sie `azure-iot-operations-aio-certificate-issuer` ein
Art des Ausstellers	Wählen Sie ClusterIssuer aus.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = '<LISTENER_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        port: 1883
        protocol: 'Mqtt'
      }
      {
        authenticationRef: 'default'
        port: 8883
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
          }
        }
      }
    ]
  }
}

Stellen Sie die Bicep-Datei mithilfe der Azure CLI bereit.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: <LISTENER_NAME>
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: LoadBalancer
  ports:
  - port: 1883
    protocol: Mqtt
  - port: 8883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
            name: azure-iot-operations-aio-certificate-issuer
            kind: ClusterIssuer
            group: cert-manager.io

Diensttyp

Jeder BrokerListener 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: Macht den Broker für eine clusterinterne IP verfügbar. Clients können innerhalb des Clusters eine Verbindung mit dem Broker herstellen. Dies ist der Standarddiensttyp 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. Dies ist der am häufigsten verwendete Diensttyp 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 Verwaltungsaufwand zu vermeiden, sollten Sie den Servicenamen 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.

Ports

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 in den Abschnitten TLS mit automatischer Zertifikatsverwaltung konfigurieren oder TLS mit manueller Zertifikatsverwaltung konfigurieren.

Verwendung desselben Ports für alle Listener

Die Verwendung derselben Portnummer für verschiedene Listener wird nicht unterstützt. Jede Portnummer muss innerhalb des Azure IoT Einsatz MQTT-Brokers 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 Azure 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 Azure IoT Einsatz Preview im cert-manager-Namespace installiert. Überprüfen Sie die Installation, bevor Sie fortfahren.

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

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 cert-manager-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.

Entwicklung oder Test
Produktion

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.

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

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

Sehen Sie sich für die Produktion die Dokumentation von cert-manager an, um zu erfahren, welcher Zertifikataussteller für Sie am besten geeignet ist. Für Vault Issuer ist dies beispielsweise:

Stellen Sie HashiCorp-Vault in einer Umgebung Ihrer Wahl, z. B. Kubernetes, bereit. Initialisieren Sie den Tresor entsprechend und heben Sie die Versiegelung auf.
Erstellen und konfigurieren Sie die PKI-Geheimnisengine, indem Sie Ihr Zertifizierungsstellenzertifikat importieren.
Konfigurieren Sie den Vault mit einer Rolle und einer Richtlinie, um Serverzertifikate auszustellen.

Nachfolgend finden eine Beispielrolle. Beachten Sie, dass ExtKeyUsageServerAuth dafür sorgt, dass das Serverzertifikat funktioniert:
```
vault write pki/roles/my-issuer \
  allow_any_name=true \
  client_flag=false \
  ext_key_usage=ExtKeyUsageServerAuth \
  no_store=true \
  max_ttl=240h
```
Beispielrichtlinie für die Rolle:
```
path "pki/sign/my-issuer" {
  capabilities = ["create", "update"]
}
```
Richten Sie die Authentifizierung zwischen cert-manager und Key Vault mithilfe einer Methode Ihrer Wahl ein, z. B. SAT.
Konfigurieren Sie den cert-manager Vault Issuer.

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.

Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.
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.

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

Geben Sie folgende Einstellungen ein:

Einstellung	BESCHREIBUNG
Name	Name der BrokerListener-Ressource. Geben Sie `aio-broker-loadbalancer-tls` ein.
Port	Portnummer, auf welcher der BrokerListener auf MQTT-Verbindungen lauscht. Geben Sie 8884 ein.
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.

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

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-loadbalancer-tls'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8884
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'my-issuer'
              kind: 'Issuer'
            }
          }
        }
      }
    ]
  }
}

Stellen Sie die Bicep-Datei mithilfe der Azure CLI bereit.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Ändern Sie die tls-Einstellung in einer BrokerListener-Ressource, um einen TLS-Port und Aussteller für die Frontends anzugeben.

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-loadbalancer-tls # Avoid conflicts with default service name 'aio-broker'
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer
  ports:
  - port: 8884 # Avoid conflicts with default port 18883
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: my-issuer
          kind: Issuer

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

Optional: Konfigurieren von Serverzertifikatparametern

Die einzigen erforderlichen Parameter sind der Name des Ausstellers und die Art des Ausstellers. 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 finden Sie unter tls.certManagerCertificateSpec oder im TLS-Konfigurationsbereich im Azure-Portal.

Eine vollständige Liste dieser Einstellungen finden Sie in der API-Referenz Broker Listener CertManagerCertificateSpec.

Überprüfen der Bereitstellung

Verwenden Sie kubectl, um zu überprüfen, ob der Dienst, der der BrokerListener-Ressource zugeordnet ist, ausgeführt wird. Im obigen Beispiel lauten 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 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 Einsatz mit einer standardmäßigen „Schnellstart“-Signaturzertifikat 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 und stellen Sie es mit kubectl bereit. Dieser Artikel zeigt ein Beispiel, das TLS mit selbstsignierten Zertifikaten zum Testen konfiguriert.

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.

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

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

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

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.

Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.
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. Um dem Beispiel zu folgen, geben Sie den Namen des Listener-Dienstes als mqtts-endpoint an.

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

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.

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

Ä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).

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerServiceName string = 'mqtts-endpoint'
param listenerName string = '<LISTENER_NAME>' // Match the SAN in the server certificate

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceName: listenerServiceName
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8885 // Avoid port conflict with default listener at 18883
        tls: {
          mode: 'Manual'
          manual: {
            secretRef: 'server-cert-secret'
          }
        }
      }
    ]
  }
}

Stellen Sie die Bicep-Datei mithilfe von Azure CLI bereit.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: loadbalancer-tls
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  ports:
  - port: 8885 # Avoid port conflict with default listener at 18883
    tls:
      mode: Manual
      manual:
        secretRef: 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

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. 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 alle Clients verteilen. In diesem Fall ist die Stammvertrauensstellung die von „Step 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.

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 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, erstellen Sie das Serverzertifikat und das Geheimnis mit der externen IP, und 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 während des Importieren des Serverzertifikats erwartbar. 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.

Freigeben über

Sichere MQTT-Broker-Kommunikation mit BrokerListener

Standard-BrokerListener

Vermeiden Sie es, den Standardbrokerlistener zu ändern.

Erstellen neuer Brokerlistener

Beispiel: Erstellen eines neuen Listeners mit zwei Ports

Diensttyp

Nur ein Listener pro Diensttyp

Dienstname

Ports

Verwendung desselben Ports für alle Listener

WebSockets-Unterstützung

Konfigurieren der TLS mit automatischer Zertifikatverwaltung

Überprüfen der Installation von cert-manager

Erstellen eines Zertifikatausstellers für das TLS-Serverzertifikat

Einrichten eines Stammzertifikats als Kubernetes-Geheimnis

Verteilen des Stammzertifikats

Erstellen eines Zertifikatausstellers basierend auf einem Zertifizierungsstellenzertifikat

Aktivieren von TLS mit automatischer Zertifikatverwaltung für einen Port

Optional: Konfigurieren von Serverzertifikatparametern

Überprüfen der Bereitstellung

Herstellen einer Verbindung mit dem Broker mit TLS

Standardstammzertifizierungsstelle und Aussteller

Konfigurieren von TLS mit manueller Zertifikatverwaltung

Erstellen einer Zertifizierungsstelle mit Step CLI

Erstellen eines Serverzertifikats

Anforderungen an den Zertifikatschlüsselalgorithmus

Importieren einer Serverzertifikatkette als Kubernetes-Geheimnis

Aktivieren von TLS mit manueller Zertifikatverwaltung für einen Port

Herstellen einer Verbindung mit dem Broker mit TLS

Verwenden einer externen IP für das Serverzertifikat

Feedback

Zusätzliche Ressourcen

Freigeben über

Sichere MQTT-Broker-Kommunikation mit BrokerListener

Standard-BrokerListener

Vermeiden Sie es, den Standardbrokerlistener zu ändern.

Erstellen neuer Brokerlistener

Beispiel: Erstellen eines neuen Listeners mit zwei Ports

Diensttyp

Nur ein Listener pro Diensttyp

Dienstname

Ports

Verwendung desselben Ports für alle Listener

WebSockets-Unterstützung

Konfigurieren der TLS mit automatischer Zertifikatverwaltung

Überprüfen der Installation von cert-manager

Erstellen eines Zertifikatausstellers für das TLS-Serverzertifikat

Einrichten eines Stammzertifikats als Kubernetes-Geheimnis

Verteilen des Stammzertifikats

Erstellen eines Zertifikatausstellers basierend auf einem Zertifizierungsstellenzertifikat

Aktivieren von TLS mit automatischer Zertifikatverwaltung für einen Port

Optional: Konfigurieren von Serverzertifikatparametern

Überprüfen der Bereitstellung

Herstellen einer Verbindung mit dem Broker mit TLS

Standardstammzertifizierungsstelle und Aussteller

Konfigurieren von TLS mit manueller Zertifikatverwaltung

Erstellen einer Zertifizierungsstelle mit Step CLI

Erstellen eines Serverzertifikats

Anforderungen an den Zertifikatschlüsselalgorithmus

Importieren einer Serverzertifikatkette als Kubernetes-Geheimnis

Aktivieren von TLS mit manueller Zertifikatverwaltung für einen Port

Herstellen einer Verbindung mit dem Broker mit TLS

Verwenden einer externen IP für das Serverzertifikat

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen