Konfigurieren der Authentifizierung mit Azure IoT MQ (Vorschau)

Artikel
11/15/2023

Wichtig

Die von Azure Arc aktivierte Azure IoT Operations Preview befindet sich derzeit in der VORSCHAU. Sie sollten diese Vorschausoftware nicht in Produktionsumgebungen verwenden.

Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Azure IoT MQ (Vorschau) 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: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: authn
  namespace: azure-iot-operations
spec:
  listenerRef:
    - listener
  authenticationMethods:
    - sat:
        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

BrokerListener und BrokerAuthentication sind separate Ressourcen, aber sie sind mithilfe von listenerRef verbunden. Es gelten die folgenden Regeln:

Ein BrokerListener kann nur mit einer BrokerAuthentication verbunden werden
Eine BrokerAuthentication kann mit mehreren BrokerListeners verbunden werden
Jede BrokerAuthentication kann mehrere Authentifizierungsmethoden gleichzeitig unterstützen

Authentifizierungsfluss

Die Reihenfolge der Authentifizierungsmethoden im Array bestimmt, wie Azure IoT MQ die Clients authentifiziert. Azure IoT MQ versucht, die Anmeldeinformationen des Clients mithilfe der ersten angegebenen Methode zu authentifizieren und durchläuft das Array, bis es eine Übereinstimmung findet oder das Ende erreicht.

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

Bei der benutzerdefinierten Authentifizierung behandelt Azure IoT MQ die Kommunikation mit dem benutzerdefinierten Authentifizierungsserver als nicht relevante Anmeldeinformationen. Mit diesem Verhalten kann Azure IoT MQ auf andere Methoden zurückgreifen, 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.
Azure IoT MQ gewährt oder verweigert den Zugriff auf den Client basierend auf dem Ergebnis des Authentifizierungsflusses.

Mit mehreren Authentifizierungsmethoden verfügt Azure IoT MQ über einen Alternativmechanismus. Beispiel:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  listenerRef:
    - listener
  authenticationMethods:
    - custom:
        # ...
    - sat:
        # ...
    - usernamePassword:
        # ...

Im vorherigen Beispiel wird die benutzerdefinierte Authentifizierung, SAT und die Authentifizierung über Benutzernamen/Kennwort angegeben. Wenn ein Client eine Verbindung herstellt, versucht Azure IoT MQ, den Client mithilfe der angegebenen Methoden in der angegebenen Reihenfolge benutzerdefiniertes > SAT->Benutzername-Kennwort zu authentifizieren.

Azure IoT MQ ü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.
Wenn der benutzerdefinierte Authentifizierungsserver mit Pass oder Fail dem Ergebnis antwortet, endet der Authentifizierungsfluss. Wenn der benutzerdefinierte Authentifizierungsserver jedoch nicht verfügbar ist, greift Azure IoT MQ auf die übrigen angegebenen Methoden zurück, wobei SAT die nächste ist.
Azure IoT MQ versucht, die Anmeldeinformationen als SAT-Anmeldeinformationen zu authentifizieren. Wenn der MQTT-Benutzername mit $sat beginnt, wertet Azure IoT MQ das MQTT-Kennwort als SAT aus. Andernfalls greift der Broker auf das Benutzername-Kennwort zurück und überprüft, ob der bereitgestellte MQTT-Benutzername und das Kennwort gültig sind.

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

Deaktivieren Sie zum Testen die Authentifizierung, indem Sie diese in der BrokerListener-Ressource ändern.

spec:
  authenticationEnabled: false

Methode zum Konfigurieren der Authentifizierung

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

Benutzername und Kennwort

Jeder Client verfügt über die folgenden erforderlichen Eigenschaften:

Beginnen Sie z. B. mit einem clients.toml mit Identitäten und PBKDF2-codierten Kennwörtern.

# Credential #1
# username: client1
# password: password
[client1]
password = "$pbkdf2-sha512$i=100000,l=64$HqJwOCHweNk1pLryiu3RsA$KVSvxKYcibIG5S5n55RvxKRTdAAfCUtBJoy5IuFzdSZyzkwvUcU+FPawEWFPn+06JyZsndfRTfpiEh+2eSJLkg"

[client1.attributes]
floor = "floor1"
site = "site1"

# Credential #2
# username: client2
# password: password2
[client2]
password = "$pbkdf2-sha512$i=100000,l=64$+H7jXzcEbq2kkyvpxtxePQ$jTzW6fSesiuNRLMIkDDAzBEILk7iyyDZ3rjlEwQap4UJP4TaCR+EXQXNukO7qNJWlPPP8leNnJDCBgX/255Ezw"

[client2.attributes]
floor = "floor2"
site = "site1"

Um das Kennwort mithilfe von PBKDF2 zu codieren, verwenden Sie die CLI-Erweiterung von Azure IoT Einsatz, die den az iot ops mq get-password-hash-Befehl enthält. Es generiert einen PBKDF2-Kennworthash aus einem Kennwortausdruck mithilfe des SHA-512-Algorithmus und eines 128-Bit-randomisierten Salts.

az iot ops mq get-password-hash --phrase TestPassword

Die Ausgabe zeigt den zu kopierenden PBKDF2-Kennworthash:

{
  "hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}

Speichern Sie die Datei dann unter passwords.toml und importieren Sie diese in ein Kubernetes-Geheimnis unter diesem Schlüssel.

kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations

Einschließen eines Verweises auf den geheimen Schlüssel in der benutzerdefinierten BrokerAuthentication-Ressource

spec:
  authenticationMethods:
    - usernamePassword:
        secretName: passwords-db

Es kann ein paar Minuten dauern, bis die Änderungen wirksam werden.

Sie können Azure Key Vault anstelle von Kubernetes-Geheimnissen verwenden, um Geheimnisse für Azure IoT MQ zu verwalten. Weitere Informationen finden Sie unter Verwalten von Geheimnissen mithilfe von Azure Key Vault- oder Kubernetes-Geheimnissen.

X.509-Clientzertifikat

Voraussetzungen

Azure IoT MQ, konfiguriert mit aktiviertem TLS.
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 in dieser Zertifizierungsstelle für Azure IoT MQ verwurzelt sein, um sie zu authentifizieren.

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

Importieren Sie die Zertifikat-zu-Attribut-Zuordnung

Um Autorisierungsrichtlinien für Clients zu verwenden, die Eigenschaften für die X.509-Zertifikate verwenden, erstellen Sie eine TOML-Datei mit Zertifikat-zu-Attribut-Zuordnung, und importieren Sie diese als Kubernetes-Geheimnis unter dem Schlüssel x509Attributes.toml. Diese Datei ordnet den Antragstellernamen des Clientzertifikats den Attributen zu, die in Autorisierungsrichtlinien verwendet werden können. Dies ist auch dann erforderlich, wenn Sie keine Autorisierungsrichtlinien verwenden.

kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations

Informationen zur Syntax der Attributsdatei finden Sie unter Autorisieren von Clients, welche die X.509-Authentifizierung verwenden.

Wie bei der Authentifizierung mit Benutzernamen und Kennwort können Sie diesen Geheimschlüssel mithilfe von Azure Key Vault anstelle von Kubernetes-Geheimnissen verwalten. Weitere Informationen finden Sie unter Verwalten von Geheimnissen mithilfe von Azure Key Vault- oder Kubernetes-Geheimnissen.

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:
    - x509:
        trustedClientCaCert: client-ca
        attributes:
          secretName: x509-attributes

Verbinden des Mosquitto-Clients mit Azure IoT MQ (Vorschau) mit X.509-Clientzertifikat

Ein Client wie mosquitto benötigt drei Dateien, um eine Verbindung mit Azure IoT MQ mit TLS und X.509-Clientauthentifizierung herzustellen. 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 mosquitto-Client eine Verbindung mit Azure IoT MQ über TLS herstellt, überprüft er 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 das Azure IoT MQ ein Clientzertifikat vom mosquitto-Client anfordert, muss auch 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. Azure IoT MQ kann dieses Zertifikat nicht allein überprüfen, da es auch 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-Clientauthentifizierungsflow von Azure IoT MQ (Vorschau)

Diagramm des X.509-Clientauthentifizierungsflusses.

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

Wenn die X.509-Clientauthentifizierung aktiviert ist, müssen Clients ihr Clientzertifikat und alle Zwischenzertifikate vorlegen, damit Azure IoT MQ eine Zertifikatkette erstellen kann, die auf eines seiner konfigurierten vertrauenswürdigen Zertifikate zurückgeht.
Der Lastenausgleich leitet die Kommunikation an einen der Front-End-Broker weiter.
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.
Der TLS-Kanal ist geöffnet, aber die Clientauthentifizierung oder Autorisierung ist noch nicht abgeschlossen.
Der Client sendet dann ein CONNECT-Paket an Azure IoT MQ.
Das CONNECT-Paket wird erneut an ein Front-End weitergeleitet.
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.
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.
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.
Der Authentifizierungsdienst gibt die Entscheidung an den Front-End-Broker zurück.
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 legen dem Azure IoT MQ MQTT-Broker SATs vor, um sich zu authentifizieren.

Azure IoT MQ verwendet -gebundene Dienstkonto-Token, die im Beitrag Was GKE-Benutzer über die neuen Dienstkonto-Tokens von Kubernetes wissen müssen beschrieben sind. 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 sat 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 Brokerdienst von Azure IoT MQ identifizieren. Sie müssen mindestens eine Zielgruppe angeben und alle SATs müssen einer der angegebenen Benutzergruppen entsprechen.

spec:
  authenticationMethods:
    - sat:
        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 Azure IoT MQ befindet. 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.

Nachdem der Pod erstellt wurde, starten Sie eine Shell im Pod:

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

Das Token wird unter dem Pfad bereitgestellt, das in der Konfiguration /var/run/secrets/tokens des vorherigen Beispiels angegeben wurde. Rufen Sie das Token ab und verwenden Sie es zum Authentifizieren.

token=$(cat /var/run/secrets/tokens/mqtt-client-token)

mosquitto_pub -h aio-mq-dmqtt-frontend -V mqttv5 -t hello -m world -u '$sat' -P "$token"

Der MQTT-Benutzername muss auf $sat festgelegt werden. Das MQTT-Kennwort muss auf den SAT selbst festgelegt werden.

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 Azure IoT MQ herstellt und die benutzerdefinierte Authentifizierung aktiviert ist, delegiert Azure IoT MQ die Überprüfung von Clientanmeldeinformationen an einen benutzerdefinierten Authentifizierungsserver mit einer HTTP-Anforderung zusammen mit allen Anmeldeinformationen, die der Client vorlegt. Der benutzerdefinierte Authentifizierungsserver antwortet mit Genehmigung oder Ablehnung für den Client mit den Attributen zur Autorisierung des Clients.

Erstellen eines benutzerdefinierten Authentifizierungsdiensts

Der benutzerdefinierte Authentifizierungsserver wird gesondert von Azure IoT MQ 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 (Anwendungsprogrammierschnittstelle) zwischen Azure IoT MQ und dem benutzerdefinierten Authentifizierungsserver entspricht der API-Spezifikation für benutzerdefinierte Authentifizierung. Die OpenAPI-Spezifikation ist auf GitHub verfügbar.

HTTPS mit TLS-Verschlüsselung ist erforderlich

Azure IoT MQ sendet Anforderungen, die vertrauliche Clientanmeldeinformationen enthalten, an den benutzerdefinierten Authentifizierungsserver. Um diese Anmeldeinformationen zu schützen, muss die Kommunikation zwischen Azure IoT MQ und dem benutzerdefinierten Authentifizierungsserver mit TLS verschlüsselt werden.

Der benutzerdefinierte Authentifizierungsserver muss ein Serverzertifikat aufweisen und Azure IoT MQ muss über ein vertrauenswürdiges Stammzertifizierungsstellen-Zertifikat für die Überprüfung des Serverzertifikats verfügen. Optional kann der benutzerdefinierte Authentifizierungsserver verlangen, dass Azure IoT MQ ein Clientzertifikat vorlegt, um sich zu authentifizieren.

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 Azure IoT MQ 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

Share via

Konfigurieren der Authentifizierung mit Azure IoT MQ (Vorschau)

StandardbrokerAuthentication-Ressource

Beziehung zwischen BrokerListener und BrokerAuthentication

Authentifizierungsfluss

Deaktivieren der Authentifizierung

Methode zum Konfigurieren der Authentifizierung

Benutzername und Kennwort

X.509-Clientzertifikat

Voraussetzungen

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

Importieren Sie die Zertifikat-zu-Attribut-Zuordnung

Aktivieren der X.509-Clientauthentifizierung

Verbinden des Mosquitto-Clients mit Azure IoT MQ (Vorschau) mit X.509-Clientzertifikat

Grundlegendes zum X.509-Clientauthentifizierungsflow von Azure IoT MQ (Vorschau)

Kubernetes Dienstkonto-Token

Erstellen eines Dienstkontos

Hinzufügen von Attributen für die Autorisierung

Aktivieren Sie die SAT-Authentifizierung

Testen der SAT-Authentifizierung

Aktualisieren von Dienstkontotoken

Benutzerdefinierte Authentifizierung

Erstellen eines benutzerdefinierten Authentifizierungsdiensts

API

HTTPS mit TLS-Verschlüsselung ist erforderlich

Aktivieren der benutzerdefinierten Authentifizierung für einen Listener

Zusätzliche Ressourcen

Share via

Konfigurieren der Authentifizierung mit Azure IoT MQ (Vorschau)

StandardbrokerAuthentication-Ressource

Beziehung zwischen BrokerListener und BrokerAuthentication

Authentifizierungsfluss

Deaktivieren der Authentifizierung

Methode zum Konfigurieren der Authentifizierung

Benutzername und Kennwort

X.509-Clientzertifikat

Voraussetzungen

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

Importieren Sie die Zertifikat-zu-Attribut-Zuordnung

Aktivieren der X.509-Clientauthentifizierung

Verbinden des Mosquitto-Clients mit Azure IoT MQ (Vorschau) mit X.509-Clientzertifikat

Grundlegendes zum X.509-Clientauthentifizierungsflow von Azure IoT MQ (Vorschau)

Kubernetes Dienstkonto-Token

Erstellen eines Dienstkontos

Hinzufügen von Attributen für die Autorisierung

Aktivieren Sie die SAT-Authentifizierung

Testen der SAT-Authentifizierung

Aktualisieren von Dienstkontotoken

Benutzerdefinierte Authentifizierung

Erstellen eines benutzerdefinierten Authentifizierungsdiensts

API

HTTPS mit TLS-Verschlüsselung ist erforderlich

Aktivieren der benutzerdefinierten Authentifizierung für einen Listener

Zugehöriger Inhalt

Zusätzliche Ressourcen