Konfigurieren der MQTT-Brokerauthentifizierung
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.
Der MQTT-Broker unterstützt mehrere Authentifizierungsmethoden für Clients, und Sie können jeden Listenerport so konfigurieren, dass dieser über eigene Authentifizierungseinstellungen mit einer BrokerAuthentication-Ressource verfügt. Eine Liste der verfügbaren Einstellungen finden Sie in der API-Referenz zur Broker-Authentifizierung.
Verknüpfen von BrokerListener und BrokerAuthentication
Die folgenden Regeln gelten für die Beziehung zwischen BrokerListener- und BrokerAuthentication-Ressourcen:
- 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.
- Bei Ports ohne verknüpfte BrokerAuthentication-Ressource ist die Authentifizierung deaktiviert.
Um einen BrokerListener-Port mit einer BrokerAuthentication-Ressource zu verknüpfen, geben Sie das Feld authenticationRef in der Einstellung ports der BrokerListener-Ressource an. Weitere Informationen finden Sie unter BrokerListener-Ressource.
StandardbrokerAuthentication-Ressource
Azure IoT Einsatz stellt eine BrokerAuthentication-Standardressource namens default bereit, die mit dem Standardlistener im azure-iot-operations-Namespace verknüpft ist. Sie verwendet nur Kubernetes Service Account Tokens (SATs) für die Authentifizierung.
Wichtig
Die Authentifizierungsmethode des Dienstkontotokens (SAT) in der standardmäßigen BrokerAuthentication-Ressource ist erforderlich, damit Komponenten in Azure IoT Einsatz ordnungsgemäß funktionieren. Vermeiden Sie das Aktualisieren oder Löschen der standardmäßigen BrokerAuthentication-Ressource.
Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Komponenten den MQTT-Broker aus.
Wählen Sie die Registerkarte Authentifizierung aus.
Wählen Sie in der Liste der Authentifizierungsrichtlinie den Standard-Richtliniennamen aus.
Um neue Authentifizierungsmethoden hinzuzufügen, wählen Sie Methode hinzufügen aus.
Authentifizierungsfluss
Die Reihenfolge der angegebenen Authentifizierungsmethoden bestimmt, wie der MQTT-Broker Clients authentifiziert. Der MQTT-Broker versucht, mithilfe der ersten angegebenen Methode die Anmeldeinformationen des Clients zu authentifizieren, und durchläuft die angegebenen Methoden, 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 Authentifizierungsserver 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.
Zum Beispiel:
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
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 Reihenfolge benutzerdefiniert und dann SAT zu authentifizieren.
- 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.
- Wenn der benutzerdefinierte Authentifizierungsserver mit
PassoderFaildem 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. - Der MQTT-Broker versucht, die Anmeldeinformationen als SAT-Anmeldeinformationen zu authentifizieren.
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 Clientverbindung.
Methode zum Konfigurieren der Authentifizierung
Sie können Authentifizierungsmethoden wie X.509 oder SAT sowie benutzerdefinierte Authentifizierungsrichtlinien hinzufügen.
So fügen Sie einer Richtlinie eine Authentifizierungsmethode hinzu:
Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Komponenten den MQTT-Broker aus.
Wählen Sie die Registerkarte Authentifizierung aus.
Wählen Sie eine vorhandene Authentifizierungsrichtlinie aus, oder erstellen Sie eine neue.
Fügen Sie eine neue Methode hinzu, indem Sie Methode hinzufügen auswählen.
Wählen Sie in der Dropdownliste den Methodentyp und dann Details hinzufügen aus, um die Methode zu konfigurieren.
Weitere Informationen zu den einzelnen Authentifizierungsoptionen finden Sie in den nächsten Abschnitt für die jeweilige Methode.
Weitere Informationen zum Aktivieren sicherer Einstellungen durch Konfigurieren einer Azure Key Vault-Instanz und Aktivieren von Workloadidentitäten finden Sie unter Aktivieren sicherer Einstellungen in einer Azure IoT Einsatz-Bereitstellung.
X.509
Tipp
Ein End-to-End-Beispiel für die Konfiguration der X.509-Authentifizierung finden Sie im Tutorial: TLS, X.509-Clientauthentifizierung und attributbasierte Zugriffssteuerungsautorisierung (ABAC).
Mit der X.509-Authentifizierung verwendet der MQTT-Broker ein vertrauenswürdiges Zertifizierungsstellenzertifikat, um Clientzertifikate zu validieren. Diese vertrauenswürdige Zertifizierungsstelle kann eine Stamm- oder Zwischenzertifizierungsstelle sein. Der Broker überprüft die Clientzertifikatkette anhand des vertrauenswürdigen Zertifizierungsstellenzertifikats. Wenn die Kette gültig ist, wird der Client authentifiziert.
Um die X.509-Authentifizierung mit einem vertrauenswürdigen Zertifizierungsstellenzertifikat zu verwenden, müssen die folgenden Anforderungen erfüllt sein:
- TLS: Da X.509 auf TLS-Clientzertifikaten basiert, muss TLS für Ports mit X.509-Authentifizierung aktiviert werden.
- Schlüsselalgorithmus: Sowohl EC- als auch RSA-Schlüssel werden unterstützt, es müssen aber alle Zertifikate in der Kette denselben Schlüsselalgorithmus verwenden.
- Format: Das Zertifizierungsstellenzertifikat muss im PEM-Format vorliegen.
Tipp
Das PEM-Format ist ein gängiges Format für Zertifikate und Schlüssel. PEM-Dateien sind base64-codierte ASCII-Dateien mit Headern wie -----BEGIN CERTIFICATE----- und -----BEGIN EC PRIVATE KEY-----.
Wenn Sie über ein Zertifikat in einem anderen Format verfügen, können Sie es mithilfe von OpenSSL in PEM konvertieren. Weitere Informationen finden Sie unter Konvertieren von Zertifikaten in ein gewünschtes Format.
Abrufen eines vertrauenswürdigen Zertifizierungsstellenzertifikats
In einer Produktionseinrichtung wird das Zertifizierungsstellenzertifikat von der Public Key-Infrastruktur (PKI) einer Organisation oder einer öffentlichen Zertifizierungsstelle bereitgestellt.
Erstellen Sie zum Testen ein selbstsigniertes Zertifizierungsstellenzertifikat mit OpenSSL. Führen Sie beispielsweise den folgenden Befehl aus, um ein selbstsigniertes Zertifizierungsstellenzertifikat mit einem RSA-Schlüssel, einem Distinguished Name CN=Contoso Root CA Cert und einer Gültigkeit von 365 Tagen zu generieren:
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
Derselbe Befehl mit Step CLI, einem praktischen Tool zum Verwalten von Zertifikaten, lautet:
step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
--not-after 8760h
Diese Befehle erstellen ein Zertifizierungsstellenzertifikat ca.pem und einen privaten Schlüssel ca-key.pem im PEM-Format. Das Zertifizierungsstellenzertifikat ca.pem kann in den MQTT-Broker für die X.509-Authentifizierung importiert werden.
Importieren eines vertrauenswürdigen ZS-Zertifikat
Um mit der X.509-Authentifizierung zu beginnen, importieren Sie das vertrauenswürdige Zertifizierungsstellenzertifikat in eine ConfigMap im azure-iot-operations-Namespace. Um ein vertrauenswürdiges Zertifizierungsstellenzertifikat ca.pem in eine ConfigMap mit dem Namen client-ca zu importieren, führen Sie Folgendes aus:
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
In diesem Beispiel wird das Zertifizierungsstellenzertifikat unter dem Schlüssel ca.pem importiert. Der MQTT-Broker vertraut allen Zertifizierungsstellenzertifikaten in der ConfigMap, sodass der Name des Schlüssels irrelevant ist.
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
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----
BinaryData
====
Konfigurieren der X.509-Authentifizierungsmethode
Nachdem das Zertifikat der vertrauenswürdigen Zertifizierungsstelle importiert wurde, aktivieren Sie die X.509-Clientauthentifizierung, indem Sie es als Authentifizierungsmethode in einer BrokerAuthentication-Ressource hinzufügen. Stellen Sie sicher, dass diese Ressource mit einem TLS-aktivierten Listenerport verknüpft ist.
Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Komponenten den MQTT-Broker aus.
Wählen Sie die Registerkarte Authentifizierung aus.
Wählen Sie eine vorhandene Authentifizierungsrichtlinie aus, oder erstellen Sie eine neue.
Fügen Sie eine neue Methode hinzu, indem Sie Methode hinzufügen auswählen.
Wählen Sie in der Dropdownliste den Methodentyp X.509 aus, und wählen Sie dann Details hinzufügen aus, um die Methode zu konfigurieren.
Geben Sie im Detailbereich der X.509-Authentifizierung den Namen des vertrauenswürdigen CA-Zertifikats „ConfigMap“ im JSON-Format an.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Ersetzen Sie
<TRUSTED_CA_CONFIGMAP>mit dem Namen der ConfigMap, die das vertrauenswürdige Zertifizierungsstellenzertifikat enthält. Beispiel:"trustedClientCaCert": "client-ca".
Fügen Sie optional Autorisierungsattribute für Clients hinzu, die X.509-Zertifikate verwenden. Weitere Informationen finden Sie unter Zertifikatattribute für die Autorisierung.
Wählen Sie Übernehmen aus, um die Änderungen zu speichern.
Optional: Zertifikatattribute für die Autorisierung
X.509-Attribute können in der BrokerAuthentication-Ressource angegeben werden, um Clients basierend auf ihren Zertifikateigenschaften zu autorisieren. Die Attribute werden im Feld authorizationAttributes definiert.
Zum Beispiel:
Fügen Sie im Azure-Portal beim Konfigurieren der X.509-Authentifizierungsmethode die Autorisierungsattribute im Detailbereich X.509 im JSON-Format hinzu.
{
"trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
"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"
}
},
"smartfan": {
"subject": "CN = smart-fan",
"attributes": {
"building": "17"
}
}
}
}
In diesem Beispiel erhält jeder Client, der über ein Zertifikat verfügt, das von der Stammzertifizierungsstelle mit dem Distinguished Name CN = Contoso Root CA Cert, OU = Engineering, C = US oder einer Zwischenzertifizierungsstelle mit dem Distinguished Name CN = Contoso Intermediate CA ausgestellt wurde, die aufgeführten Attribute. Darüber hinaus erhält das Smart Fan-Clientzertifikat 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. Weitere Informationen finden Sie unter Autorisieren von Clients, die X.509-Authentifizierung verwenden.
Aktivieren der X.509-Authentifizierung für einen Listenerport
Nachdem Sie das vertrauenswürdige Zertifizierungsstellenzertifikat importiert und die BrokerAuthentication-Ressource konfiguriert haben, verknüpfen Sie es mit einem TLS-fähigen Listenerport. Dieser Schritt ist wichtig, da die X.509-Authentifizierung für die Clientzertifikatüberprüfung auf TLS basiert.
Informationen zum Abrufen eines TLS-aktivierten Listenerports finden Sie unter Aktivieren der manuellen TLS-Zertifikatverwaltung für einen Port und Aktivieren der automatischen TLS-Zertifikatverwaltung für einen Port.
Hinweis
Das Aktivieren von TLS für einen Brokerlistenerport bedeutet, dass der Broker ein Serverzertifikat für die TLS-Verschlüsselung verwendet. Wenn Clients eine Verbindung mit diesem Port herstellen, müssen sie dem Serverzertifikat vertrauen, indem sie das Zertifizierungsstellenzertifikat haben, das es in ihrem Vertrauensspeicher angemeldet hat. Dieser Prozess wird als Vertrauensverteilung oder Bündelung bezeichnet. Es ist wichtig, den Unterschied zwischen Serverüberprüfung und Clientüberprüfung zu verstehen:
- Clientüberprüfung: Der MQTT-Broker (Server) überprüft das Clientzertifikat anhand des im
trustedClientCaCert-Feld für die X.509-Clientauthentifizierung angegebenen vertrauenswürdigen Zertifizierungsstellenzertifikats. - Servervalidierung: Clients (z. B. Mosquitto oder MQTTX) überprüfen das Serverzertifikat des MQTT-Brokers anhand des vertrauenswürdigen Zertifizierungsstellenzertifikats in ihrem Vertrauensspeicher. Verwenden Sie für Mosquitto-Clients den
--cafile-Parameter, um die Zertifikatdatei der Zertifizierungsstelle anzugeben. Fügen Sie für MQTTX das Zertifizierungsstellenzertifikat in den Einstellungen zum Vertrauensspeicher hinzu.
Stellen Sie nach dem Aktivieren der X.509-Authentifizierung sicher, dass Clients dem Serverzertifikat des Brokers vertrauen, indem Sie das serverseitige Zertifizierungsstellenzertifikat in ihrem Vertrauensspeicher haben. Verwechseln Sie nicht das Vertrauen des serverseitigen Zertifizierungsstellenzertifikats mit dem clientseitigen Zertifizierungsstellenzertifikat, das für die Clientauthentifizierung verwendet wird, die im trustedClientCaCert-Feld angegeben ist.
Ein vollständiges Beispiel finden Sie im Tutorial: TLS-, X.509-Clientauthentifizierung und attributbasierte Zugriffssteuerungsautorisierung (ABAC).
Verbinden des Mosquitto-Clients mit dem MQTT-Broker mit einem X.509-Clientzertifikat
Ein Client wie Mosquitto benötigt zwei Dateien, um eine Verbindung mit dem MQTT-Broker mit TLS und X.509-Clientauthentifizierung herzustellen.
- Der
--cert-Parameter gibt die PEM-Datei des Clientzertifikats an. Diese Datei sollte auch alle Zwischenzertifikate enthalten, damit der MQTT-Broker die vollständige Zertifikatkette erstellen kann. - Der
--key-Parameter gibt die PEM-Datei des privaten Clientschlüssels an.
Falls der MQTT-Broker ein selbstsigniertes Zertifizierungsstellenzertifikat verwendet, um sein TLS-Serverzertifikat auszustellen, ist der --cafile-Parameter erforderlich. Diese Datei enthält das Zertifizierungsstellenzertifikat (auch als Trust Bundle bezeichnet), das der Mosquitto-Client zum Überprüfen des Serverzertifikats des Brokers beim Herstellen einer Verbindung über TLS verwendet. Wenn der Aussteller des Serverzertifikats des MQTT-Brokers Teil des Systemstammspeichers ist (z. B. bekannte öffentliche Zertifizierungsstellen), kann der --cafile-Parameter weggelassen werden.
Zum Beispiel:
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem
Grundlegendes zum X.509-Clientauthentifizierungflow mit dem MQTT-Broker
Im Folgenden sind die Schritte für die Clientauthentifizierung aufgeführt:
- Wenn die X.509-Clientauthentifizierung aktiviert ist, müssen Clients ein Clientzertifikat und alle Zwischenzertifikate präsentieren, damit der MQTT-Broker eine Zertifikatkette erstellen kann, die von einem seiner konfigurierten vertrauenswürdigen Zertifikate stammt.
- 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. Wenn der Front-End-Broker erfolgreich eine Kette erstellt hat und die angezeigte Kette überprüft wird, wird der TLS-Handshake abgeschlossen. Der Client, der die Verbindung herstellt, kann MQTT-Pakete über den 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 daraufhin ein CONNECT-Paket an den MQTT-Broker.
- Das CONNECT-Paket wird erneut an ein Front-End weitergeleitet.
- Das Front-End sammelt alle Anmeldeinformationen, die der Client bisher vorgelegt hat, z. B. 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. In diesem Fall wird die MQTT-Verbindung fertig gestellt, 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 das Kubernetes-Feature TokenRequestProjection, 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
Optional: Hinzufügen von Attributen für die Autorisierung
Clients, die sich über SAT authentifizieren, können ihre Dienstkonten optional mit Attributen versehen, die mit Autorisierungsrichtlinien verwendet werden können. Um diese Anmerkungen von anderen zu unterscheiden, beginnen sie mit dem aio-broker-auth/-Präfix.
Sie können ein Dienstkonto mithilfe von kubectl annotate mit Anmerkungen versehen:
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
Sie können auch die Anmerkungen zur Manifestdatei des Dienstkontos hinzufügen:
apiVersion: v1
kind: ServiceAccount
metadata:
name: <SERVICE_ACCOUNT_NAME>
namespace: azure-iot-operations
annotations:
aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>
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.
- Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
- Wählen Sie unter Komponenten den MQTT-Broker aus.
- Wählen Sie die Registerkarte Authentifizierung aus.
- Wählen Sie eine vorhandene Authentifizierungsrichtlinie aus, oder erstellen Sie eine neue.
- Fügen Sie eine neue Methode hinzu, indem Sie Methode hinzufügen auswählen.
- Wählen Sie in der Dropdownliste den Methodentyp Kubernetes SAT aus, und wählen Sie dann Details hinzufügen aus, um die Methode zu konfigurieren.
Testen der SAT-Authentifizierung
Bei der SAT-Authentifizierung werden erweiterte Authentifizierungsfelder von MQTT v5 verwendet. Der Client muss die erweiterte Authentifizierungsmethode auf K8S-SAT und die erweiterten Authentifizierungsdaten auf das Token festlegen.
Ein Beispiel unter Verwendung von Mosquitto (einige Felder wurden aus Platzgründen weggelassen):
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
Hier ist <TOKEN> das Token des Dienstkontos. Führen Sie zum Abrufen eines Testtokens Folgendes aus:
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
Hier ist <SERVICE_ACCOUNT> der Name des von Ihnen erstellten Dienstkontos und <AUDIENCE> eine der Zielgruppen, die in der BrokerAuthentication-Ressource konfiguriert wurden.
Ein Beispiel für das Konfigurieren eines Kubernetes-Pods für die Verwendung der SAT-Authentifizierung finden Sie unter Herstellen einer Verbindung mit dem Standardlistener im Cluster.
In der Podkonfiguration muss das Feld serviceAccountName mit dem Dienstkonto übereinstimmen, das dem verwendeten Token zugeordnet ist, und das Feld serviceAccountToken.audience muss eine der in der BrokerAuthentication-Ressource konfigurierten audiences sein.
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/broker-satverfü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 mit aktivierter benutzerdefinierter Authentifizierung herstellt, sendet der Broker eine HTTPS-Anforderung an einen benutzerdefinierten Authentifizierungsserver mit den Anmeldeinformationen des Clients. Der Server antwortet dann mit Genehmigung oder Ablehnung, einschließlich der Autorisierungsattribute 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.
Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
Wählen Sie unter Komponenten den MQTT-Broker aus.
Wählen Sie die Registerkarte Authentifizierung aus.
Wählen Sie eine vorhandene Authentifizierungsrichtlinie aus, oder erstellen Sie eine neue.
Fügen Sie eine neue Methode hinzu, indem Sie Methode hinzufügen auswählen.
Wählen Sie den Methodentyp benutzerdefiniert aus der Dropdownliste aus, und wählen Sie dann Details hinzufügen aus, um die Methode zu konfigurieren.
Deaktivieren der Authentifizierung
Zum Testen können Sie die Authentifizierung für einen Port des Brokerlistener deaktivieren. Die Deaktivierung der Authentifizierung wird für Produktionsumgebungen nicht empfohlen.
- Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
- Wählen Sie unter "Komponenten" den MQTT-Brokeraus.
- Wählen Sie den Brokerlistener aus, den Sie in der Liste bearbeiten möchten.
- Wählen Sie am Port, an dem Sie die Authentifizierung deaktivieren möchten, die Option Keine in der Dropdownliste für die Authentifizierung aus.
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 mit dem Grund ReAuth 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 (z. B. weil der benutzerdefinierte Authentifizierungsserver nicht verfügbar ist) führen dazu, dass der Broker ein ContinueAuthentication AUTH-Paket sendet. 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.