Freigeben über

Konfigurieren der MQTT-Brokerauthentifizierung

  • 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, wenn ein allgemein verfügbares Release verfügbar wird. 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.

Der MQTT-Broker unterstützt mehrere Authentifizierungsmethoden für Clients, und Sie können jeden Listener so konfigurieren, dass dieser über ein eigenes Authentifizierungssystem mit BrokerAuthentication-Ressourcen verfügt.

StandardbrokerAuthentication-Ressource

Azure IoT Einsatz (Vorschau) stellt eine standardmäßige BrokerAuthentication-Ressource namens authn bereit, die mit dem Standardlistener listener im Namespace azure-iot-operations verknüpft ist. Er ist so konfiguriert, dass nur Kubernetes-Dienstkonto-Token (SATs) für die Authentifizierung verwendet werden. Führen Sie Folgendes aus, um dies zu prüfen:

kubectl get brokerauthentication authn -n azure-iot-operations -o yaml

Die Ausgabe zeigt die standardmäßige BrokerAuthentication-Ressource, wobei die Metadaten aus Platzgründen entfernt wurden:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: ServiceAccountToken
    serviceAccountToken:
      audiences:
      - aio-mq

Um die Konfiguration zu ändern, ändern Sie die authenticationMethods Einstellung in dieser BrokerAuthentication-Ressource oder erstellen Sie eine brandneue BrokerAuthentication-Ressource mit einem anderen Namen. Stellen Sie diese dann mithilfe von kubectl apply bereit.

Beziehung zwischen BrokerListener und BrokerAuthentication

Die folgenden Regeln gelten für die Beziehung zwischen BrokerListener und BrokerAuthentication:

  • Jede BrokerListener-Ressource kann über mehrere Ports verfügen. Jeder Port kann mit einer BrokerAuthentication-Ressource verknüpft werden.
  • Jede BrokerAuthentication kann mehrere Authentifizierungsmethoden gleichzeitig unterstützen

Authentifizierungsfluss

Die Reihenfolge der Authentifizierungsmethoden im Array bestimmt, wie MQTT-Broker Clients authentifiziert. Der MQTT-Broker versucht, mithilfe der ersten angegebenen Methode die Anmeldeinformationen des Clients zu authentifizieren, und durchläuft das Array, bis er eine Übereinstimmung findet oder das Ende erreicht.

Bei jeder Methode prüft der MQTT-Broker zunächst, ob die Anmeldeinformationen des Clients für diese Methode relevant sind. Die SAT-Authentifizierung erfordert z. B. einen Benutzernamen ab K8S-SAT und für die X.509-Authentifizierung ist ein Clientzertifikat erforderlich. Wenn die Anmeldeinformationen des Clients relevant sind, überprüft der MQTT-Broker, ob sie gültig sind. Weitere Informationen finden Sie im Abschnitt Konfigurieren der Authentifizierungsmethode.

Bei der benutzerdefinierten Authentifizierung behandelt der MQTT-Broker die Kommunikation mit dem Server für die benutzerdefinierte Authentifizierung als Anmeldeinformationen nicht relevant. Dieses Verhalten erlaubt es dem MQTT-Broker, auf andere Methoden zurückzugreifen, wenn der benutzerdefinierte Server nicht erreichbar ist.

Der Authentifizierungsfluss endet, wenn:

  • Eine der folgenden Bedingungen gilt:
    • Die Anmeldeinformationen des Clients sind für eine der Methoden relevant und gültig.
    • Die Anmeldeinformationen des Clients sind für keine der Methoden relevant.
    • Die Anmeldeinformationen des Clients sind für eine der Methoden relevant, aber ungültig.
  • Der MQTT-Broker gewährt Zugriff auf den Client basierend auf dem Ergebnis des Authentifizierungsflows oder verweigert diesen.

Der MQTT-Broker verfügt aufgrund mehrerer Authentifizierungsmethoden über einen Fallbackmechanismus. Zum Beispiel:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      custom:
        # ...
    - method: ServiceAccountToken
      serviceAccountToken:
        # ...
    - method: x509Credentials
      x509Credentials:
        # ...

Im vorherigen Beispiel wird „Custom“ und „SAT“ angegeben. Wenn ein Client eine Verbindung herstellt, versucht der MQTT-Broker, den Client mithilfe der angegebenen Methoden in der angegebenen Reihenfolge zu authentifizieren: Custom und anschließend SAT.

  1. Der MQTT-Broker überprüft, ob die Anmeldeinformationen des Clients für die benutzerdefinierte Authentifizierung gültig sind. Da die benutzerdefinierte Authentifizierung auf einem externen Server basiert, um die Gültigkeit von Anmeldeinformationen zu ermitteln, berücksichtigt der Broker alle für die benutzerdefinierte Authentifizierung relevanten Anmeldeinformationen und leitet sie an den benutzerdefinierten Authentifizierungsserver weiter.

  2. Wenn der benutzerdefinierte Authentifizierungsserver mit Pass oder Fail dem Ergebnis antwortet, endet der Authentifizierungsfluss. Wenn der Server für die benutzerdefinierte Authentifizierung jedoch nicht verfügbar ist, greift der MQTT-Broker auf die verbleibenden angegebenen Methoden zurück. Dabei wird SAT als Nächstes verwendet.

  3. Der MQTT-Broker versucht, die Anmeldeinformationen als SAT-Anmeldeinformationen zu authentifizieren. Wenn der MQTT-Benutzername mit K8S-SAT beginnt, wertet der MQTT-Broker das MQTT-Kennwort als SAT aus.

Wenn der benutzerdefinierte Authentifizierungsserver nicht verfügbar ist und durch alle nachfolgenden Methoden festgestellt wurde, dass die angegebenen Anmeldeinformationen nicht relevant sind, verweigert der Broker die Verbindung zum Client.

Deaktivieren der Authentifizierung

Zum Testen können Sie die Authentifizierung deaktivieren, indem Sie in der ports-Einstellung einer BrokerListener-Ressource authenticationRef auslassen.

Methode zum Konfigurieren der Authentifizierung

Weitere Informationen zu den einzelnen Authentifizierungsoptionen finden Sie in den folgenden Abschnitten:

X.509-Clientzertifikat

Voraussetzungen

  • MQTT-Broker, der mit TLS aktiviert konfiguriert ist
  • Step-CLI
  • Clientzertifikate und die ausstellende Zertifikatkette in PEM-Dateien. Wenn Sie keines haben, verwenden Sie Step CLI, um einige zu generieren.
  • Vertrautheit mit Kryptografie und Ausdrücken wie Stammzertifizierungsstelle, privatem Schlüssel und Zwischenzertifikaten.

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 Ihre eigenen CA-Zertifikate importieren, stellen Sie sicher, dass das Clientzertifikat denselben Schlüsselalgorithmus verwendet wie die Zertifizierungsstellen.

Importieren eines Zertifikats für vertrauenswürdige Client-Stammzertifizierungsstellen

Zum Überprüfen des Clientzertifikats ist ein vertrauenswürdiges Stammzertifizierungsstellen-Zertifikat erforderlich. Um ein Stammzertifikat zu importieren, das zum Überprüfen von Clientzertifikaten verwendet werden kann, importieren Sie zuerst das Zertifikat PEM als ConfigMap unter dem Schlüssel client_ca.pem. Clientzertifikate müssen von dieser Zertifizierungsstelle stammen, damit der MQTT-Broker diese authentifizieren kann.

kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations

Führen Sie kubectl describe configmap aus, um zu überprüfen, ob das Stammzertifizierungsstellen-Zertifikat ordnungsgemäß importiert wurde. Das Ergebnis zeigt die gleiche Base64-Codierung der PEM-Zertifikatdatei.

$ kubectl describe configmap client-ca -n azure-iot-operations
Name:         client-ca
Namespace:    azure-iot-operations

Data
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----


BinaryData
====

Zertifikatsattribute

X509-Attribute können in der BrokerAuthentication-Ressource angegeben werden. Beispiel: Jeder Client, der über ein Zertifikat verfügt, das von der Stammzertifizierungsstelle CN = Contoso Root CA Cert, OU = Engineering, C = US oder einer Zwischenzertifizierungsstelle CN = Contoso Intermediate CA ausgestellt wurde, erhält die aufgeführten Attribute.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: x509Credentials
      x509Credentials:
        authorizationAttributes:
          root:
            subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"
            attributes:
              organization = contoso
          intermediate:
            subject = "CN = Contoso Intermediate CA"
            attributes:
              city = seattle
              foo = bar
          smart-fan:
            subject = "CN = smart-fan"
            attributes:
              building = 17

In diesem Beispiel erhält jeder Client, der über ein Zertifikat verfügt, das von der Stammzertifizierungsstelle CN = Contoso Root CA Cert, OU = Engineering, C = US oder einer Zwischenzertifizierungsstelle CN = Contoso Intermediate CA ausgestellt wurde, die aufgeführten Attribute. Darüber hinaus erhält der Smart Fan für ihn spezifische Attribute.

Der Abgleich für Attribute beginnt immer mit dem Clientblattzertifikat und folgt dann weiter der Kette. Die Attributzuweisung wird nach der ersten Übereinstimmung beendet. Selbst wenn im vorherigen Beispiel smart-fan das Zwischenzertifikat CN = Contoso Intermediate CA aufweist, erhält es die zugehörigen Attribute nicht.

Autorisierungsregeln können mithilfe von X.509-Zertifikaten mit diesen Attributen auf Clients angewendet werden.

Aktivieren der X.509-Clientauthentifizierung

Nachdem das Zertifikat der vertrauenswürdigen Client-Stammzertifizierungsstelle und die Zertifikat-zu-Attribut-Zuordnung importiert wurden, aktivieren Sie die X.509-Clientauthentifizierung, indem Sie x509 als eine der Authentifizierungsmethoden als Teil einer BrokerAuthentication-Ressource hinzufügen, die mit einem TLS-aktivierten Listener verbunden ist. Zum Beispiel:

spec:
  authenticationMethods:
    - method: x509Credentials
      x509Credentials:
        trustedClientCaCert: client-ca
        attributes:
          secretName: x509-attributes

Verbinden des Mosquitto-Clients mit dem MQTT-Broker mit einem X.509-Clientzertifikat

Ein Client wie Mosquitto benötigt drei Dateien, um eine Verbindung mit dem MQTT-Broker mit TLS und einem X.509-Clientauthentifizierung herzustellen. Zum Beispiel:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem

Im Beispiel:

  • Der --cert-Parameter gibt die PEM-Datei des Clientzertifikats an.
  • Der --key-Parameter gibt die PEM-Datei des privaten Clientschlüssels an.
  • Der dritte Parameter --cafile ist der komplexeste: Die vertrauenswürdige Zertifikatsdatenbank, die für zwei Zwecke verwendet wird:
    • Wenn der Mosquitto-Client eine Verbindung mit dem MQTT-Broker über TLS herstellt, überprüft dieser das Serverzertifikat. Es sucht nach Stammzertifikaten in der Datenbank, um eine vertrauenswürdige Kette mit dem Serverzertifikat zu erstellen. Aus diesem Grund muss das Serverstammzertifikat in diese Datei kopiert werden.
    • Wenn der MQTT-Broker ein Clientzertifikat vom Mosquitto-Client anfordert, muss ebenfalls eine gültige Zertifikatkette an den Server gesendet werden. Der --cert-Parameter teilt mosquitto mit, welches Zertifikat gesendet werden soll, aber es reicht nicht aus. Der MQTT-Broker kann dieses Zertifikat nicht allein überprüfen, da dieser ebenfalls das Zwischenzertifikat benötigt. Mosquitto verwendet die Datenbankdatei, um die erforderliche Zertifikatkette zu erstellen. Um dies zu unterstützen, muss das cafile sowohl die Zwischen- als auch die Stammzertifikate enthalten.

Grundlegendes zum X.509-Clientauthentifizierungflow mit dem MQTT-Broker

Diagramm des X.509-Clientauthentifizierungsflusses.

Im Folgenden sind die Schritte für den Clientauthentifizierungsfluss aufgeführt:

  1. Wenn die X.509-Clientauthentifizierung aktiviert ist, müssen Clients ihr Clientzertifikat und alle Zwischenzertifikate präsentieren, damit der MQTT-Broker eine Zertifikatkette erstellen kann, die von einem seiner konfigurierten vertrauenswürdigen Zertifikate stammt.
  2. Der Lastenausgleich leitet die Kommunikation an einen der Front-End-Broker weiter.
  3. Nachdem der Front-End-Broker das Clientzertifikat erhalten hat, versucht er, eine Zertifikatkette zu erstellen, die auf eines der konfigurierten Zertifikate zurückgeht. Das Zertifikat ist für einen TLS-Handshake erforderlich. Wenn der Front-End-Broker erfolgreich eine Kette erstellt hat und die angezeigte Kette überprüft wird, wird der TLS-Handshake abgeschlossen. Der verbindungsfähige Client kann MQTT-Pakete über den integrierten TLS-Kanal an das Front-End senden.
  4. Der TLS-Kanal ist geöffnet, aber die Clientauthentifizierung oder Autorisierung ist noch nicht abgeschlossen.
  5. Der Client sendet daraufhin ein CONNECT-Paket an den MQTT-Broker.
  6. Das CONNECT-Paket wird erneut an ein Front-End weitergeleitet.
  7. Das Front-End sammelt alle Anmeldeinformationen, die der Client bisher vorgelegt hat, z. B. Benutzernamen- und Kennwortfelder, Authentifizierungsdaten aus dem CONNECT-Paket und die Clientzertifikatskette, die während des TLS-Handshake vorgelegt wird.
  8. Das Front-End sendet diese Anmeldeinformationen an den Authentifizierungsdienst. Der Authentifizierungsdienst überprüft die Zertifikatkette erneut und sammelt die Antragstellernamen aller Zertifikate in der Kette.
  9. Der Authentifizierungsdienst verwendet seine konfigurierten Autorisierungsregeln, um zu bestimmen, welche Attribute die Verbindungsclients haben. Diese Attribute bestimmen, welche Vorgänge der Client ausführen kann, einschließlich des CONNECT-Pakets selbst.
  10. Der Authentifizierungsdienst gibt die Entscheidung an den Front-End-Broker zurück.
  11. Der Front-End-Broker kennt die Attribute des Clients und weiß, ob er eine Verbindung herstellen darf. Wenn ja, wird die MQTT-Verbindung abgeschlossen und der Client kann weiterhin MQTT-Pakete senden und empfangen, die durch seine Autorisierungsregeln festgelegt sind.

Kubernetes Dienstkonto-Token

Kubernetes Dienstkonto-Token (Service Account Tokens, SATs) sind JSON-Webtoken, die Kubernetes-Dienstkonten zugeordnet sind. Clients präsentieren dem MQTT-Broker SATs, um sich selbst zu authentifizieren.

Der MQTT-Broker verwendet gebundenen Dienstkontotoken, die im Beitrag Was GKE-Benutzer über die neuen Dienstkontotoken von Kubernetes wissen müssen näher erläutert werden. Hier sind die zentralen Funktionen aus dem Beitrag:

Gebundene Token, die in Kubernetes 1.13 eingeführt wurden und in 1.21 zum Standardformat werden, bieten alle eingeschränkten Funktionen der alten Token und noch mehr:

  • Die Token selbst sind schwerer zu stehlen und zu missbrauchen. Sie sind zeit-, zielgruppen- und objektgebunden.
  • Sie verwenden ein standardisiertes Format: OpenID Connect (OIDC), mit vollständiger OIDC-Erkennung, was es den Dienstanbietern leichter macht, sie zu akzeptieren.
  • Sie werden sicherer auf Pods verteilt, indem ein neuer Kubelet-projizierter Volumetyp verwendet wird.

Der Broker überprüft Token mithilfe der Kubernetes-Tokenüberprüfungs-API. Aktivieren Sie die Kubernetes-FunktionTokenRequestProjection, um audiences (Standard seit 1.21) anzugeben. Wenn diese Funktion nicht aktiviert ist, können SATs nicht verwendet werden.

Erstellen eines Dienstkontos

Um SATs zu erstellen, erstellen Sie zuerst ein Dienstkonto. Mit dem folgenden Befehl wird ein Dienstkonto erstellt unter dem Namen mqtt-client.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Hinzufügen von Attributen für die Autorisierung

Clients, die sich über SAT authentifizieren, können ihre SATs optional mit Attributen versehen, die mit benutzerdefinierten Autorisierungsrichtlinien verwendet werden können. Weitere Informationen finden Sie unter Autorisieren von Clients, die Kubernetes Dienstkonto-Token verwenden.

Aktivieren Sie die SAT-Authentifizierung

Ändern Sie die authenticationMethods-Einstellung in einer BrokerAuthentication-Ressource, um ServiceAccountToken als gültige Authentifizierungsmethode anzugeben. audiences gibt die Liste der gültigen Zielgruppen für Token an. Wählen Sie eindeutige Werte aus, die den MQTT-Brokerdienst identifizieren. Sie müssen mindestens eine Zielgruppe angeben und alle SATs müssen einer der angegebenen Benutzergruppen entsprechen.

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountToken:
        audiences:
        - aio-mq
        -  my-audience

Übernehmen Sie Ihre Änderungen mit kubectl apply. Es kann ein paar Minuten dauern, bis die Änderungen wirksam werden.

Testen der SAT-Authentifizierung

Die SAT-Authentifizierung muss von einem Client verwendet werden, der sich im selben Cluster wie der MQTT-Broker befindet. Ausschließlich erweiterte Authentifizierungsfelder sind zulässig. Legen Sie die Authentifizierungsmethode auf K8S-SAT und Authentifizierungsdaten auf das Token fest.

Der folgende Befehl legt einen Pod fest, der den mosquitto-Client enthält, und bindet die in den vorherigen Schritten erstellte SAT in den Pod ein.

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
spec:
  serviceAccountName: mqtt-client
  containers:
  - image: efrecon/mqtt-client
    name: mqtt-client
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: mqtt-client-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: mqtt-client-token
    projected:
      sources:
      - serviceAccountToken:
          path: mqtt-client-token
          audience: my-audience
          expirationSeconds: 86400

Hier muss das serviceAccountName-Feld in der Pod-Konfiguration mit dem Dienstkonto übereinstimmen, das dem verwendeten Token zugeordnet ist. Außerdem muss das serviceAccountToken.audience-Feld in der Pod-Konfiguration eines der audiences-Felder sein, die in der BrokerAuthentication-Ressource konfiguriert sind.

Starten Sie im Pod eine Shell, sobald der Pod erstellt wurde:

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

Führen Sie innerhalb der Shell des Pods den folgenden Befehl aus, um eine Nachricht im Broker zu veröffentlichen:

mosquitto_pub --host aio-mq-dmqtt-frontend --port 8883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/mq-sat)

Die Ausgabe sollte in etwa wie folgt aussehen:

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

Der Mosquitto-Client verwendet das bei /var/run/secrets/tokens/mq-sat hinterlegte Dienstkontotoken zur Authentifizierung beim Broker. Das Token ist 24 Stunden lang gültig. Der Client verwendet auch das Standard-Root-ZS-Zertifikat, das auf /var/run/certs/ca.crt gespeichert ist, um die TLS-Zertifikatskette des Brokers zu überprüfen.

Aktualisieren von Dienstkontotoken

Dienstkontotoken sind für einen begrenzten Zeitraum gültig und mit expirationSeconds konfiguriert. Kubernetes aktualisiert das Token jedoch automatisch, bevor es abläuft. Das Token wird im Hintergrund aktualisiert, und der Client muss nichts weiter tun, als es erneut abzurufen.

Wenn der Client z. B. ein Pod ist, der das als Volume bereitgestellte Token verwendet, wie im Beispiel SAT-Authentifizierung testen, ist das aktuelle Token unter demselben Pfad /var/run/secrets/tokens/mqtt-client-tokenverfügbar. Beim Herstellen einer neuen Verbindung kann der Client das aktuelle Token abrufen und zum Authentifizieren verwenden. Der Client muss auch über einen Mechanismus zum Behandeln von MQTT-Fehlern vom Typ „Nicht autorisiert“ verfügen, indem das aktuelle Token abgerufen und das Herstellen der Verbindung erneut versucht wird.

Benutzerdefinierte Authentifizierung

Erweitern Sie die Clientauthentifizierung über die angebotenen Authentifizierungsmethoden hinaus mit einer benutzerdefinierten Authentifizierung. Er ist steckbar, da der Dienst alles sein kann, solange er sich an die API hält.

Wenn ein Client eine Verbindung mit dem MQTT-Broker herstellt und die benutzerdefinierte Authentifizierung aktiviert ist, delegiert der MQTT-Broker die Überprüfung von Clientanmeldeinformationen an einen Server für die benutzerdefinierte Authentifizierung mit einer HTTP-Anforderung zusammen mit allen Anmeldeinformationen, die der Client präsentiert. Der benutzerdefinierte Authentifizierungsserver antwortet mit Genehmigung oder Ablehnung für den Client mit den Attributen zur Autorisierung des Clients.

Erstellen eines benutzerdefinierten Authentifizierungsdiensts

Der Server für die benutzerdefinierte Authentifizierung wird separat vom MQTT-Broker implementiert und bereitgestellt.

Ein Beispiel für einen benutzerdefinierten Authentifizierungsserver und Anweisungen finden Sie auf GitHub. Verwenden Sie dieses Beispiel als Vorlage und Ausgangspunkt für die Implementierung Ihrer eigenen benutzerdefinierten Authentifizierungslogik.

API

Die API zwischen dem MQTT-Broker und dem Server für die benutzerdefinierte Authentifizierung folgen der API-Spezifikation für die benutzerdefinierte Authentifizierung. Die OpenAPI-Spezifikation ist auf GitHub verfügbar.

HTTPS mit TLS-Verschlüsselung ist erforderlich

Der MQTT-Broker sendet Anforderungen mit vertraulichen Clientanmeldeinformationen an den Server für die benutzerdefinierten Authentifizierung. Um diese Anmeldeinformationen zu schützen, muss die Kommunikation zwischen dem MQTT-Broker und dem Server für die benutzerdefinierte Authentifizierung mit TLS verschlüsselt werden.

Der Server für die benutzerdefinierte Authentifizierung muss ein Serverzertifikat präsentieren, und der MQTT-Broker muss für die Überprüfung des Serverzertifikats über ein Zertifikat einer vertrauenswürdigen Stammzertifizierungsstelle verfügen. Optional erfordert der Server für die benutzerdefinierte Authentifizierung möglicherweise, dass der MQTT-Broker ein Clientzertifikat für die Authentifizierung selbst präsentiert.

Aktivieren der benutzerdefinierten Authentifizierung für einen Listener

Ändern Sie die authenticationMethods-Einstellung in einer BrokerAuthentication-Ressource, um custom als gültige Authentifizierungsmethode anzugeben. Geben Sie dann die Parameter an, welche für die Kommunikation mit einem benutzerdefinierten Authentifizierungsserver erforderlich sind.

Dieses Beispiel zeigt alle möglichen Parameter. Die genauen Parameter, die erforderlich sind, hängen von den Anforderungen jedes benutzerdefinierten Servers ab.

spec:
  authenticationMethods:
    - custom:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Trusted CA certificate for validating custom authentication server certificate.
        # Required unless the server certificate is publicly-rooted.
        caCert: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretName: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Trennen der Verbindung mit Clients nach Ablauf der Anmeldeinformationen

Der MQTT-Broker trennt die Verbindung mit Clients, wenn ihre Anmeldeinformationen ablaufen. Das Trennen der Verbindung nach Ablauf der Anmeldeinformationen gilt für alle Clients, die eine Verbindung mit dem Front-End des MQTT-Brokers herstellen. Dazu gehört:

  • Trennen der Verbindung mit über SATs authentifizierte Clients, wenn ihr SAT abläuft
  • Trennen der Verbindung mit über X.509 authentifizierte Clients, wenn ihr Clientzertifikat abläuft
  • Trennen der Verbindung mit über die benutzerdefinierte Authentifizierung authentifizierte Clients basierend auf der vom Server für die benutzerdefinierte Authentifizierung zurückgegebenen Ablaufzeit

Beim Trennen der Verbindung wird die Netzwerkverbindung des Clients unterbrochen. Der Client empfängt kein MQTT DISCONNECT-Paket. Der Broker protokolliert jedoch eine Meldung, dass er die Verbindung mit dem Client getrennt hat.

MQTT-Clients der Version 5, die mit SATs authentifiziert wurden, und die benutzerdefinierte Authentifizierung können mit neuen Anmeldeinformationen erneut authentifiziert werden, bevor ihre anfänglichen Anmeldeinformationen ablaufen. X.509-Clients können nicht erneut authentifiziert werden und müssen die Verbindung erneut herstellen, da die Authentifizierung in der TLS-Schicht erfolgt.

Clients können sich erneut authentifizieren, indem sie ein AUTH-Paket von Version 5 von MQTT senden.

SAT-Clients senden einen AUTH-Client mit den Feldern method: K8S-SAT, data: <token>. Clients für die benutzerdefinierte Authentifizierung legen die Methode und das Datenfeld so fest, wie es der Server für die benutzerdefinierte Authentifizierung erfordert.

Durch die erfolgreiche erneute Authentifizierung wird der Ablauf der Anmeldeinformationen des Clients mit dem Ablauf der neuen Anmeldeinformationen aktualisiert, und der Broker sendet ein Success AUTH-Paket. Fehler bei der Authentifizierung aufgrund vorübergehender Probleme führen dazu, dass der Broker ein ContinueAuthentication AUTH-Paket sendet. Beispiel: Der Server für die benutzerdefinierte Authentifizierung ist nicht verfügbar. Der Client kann zu einem späteren Zeitpunkt einen erneuten Versuch starten. Andere Authentifizierungsfehler führen dazu, dass der Broker ein DISCONNECT-Paket sendet und die Netzwerkverbindung des Clients schließt.

Zugehöriger Inhalt