Freigeben über

Konfigurieren der Autorisierung mit Azure IoT MQ (Vorschau)

  • Artikel

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.

Mithilfe von Autorisierungsrichtlinien wird bestimmt, welche Aktionen die Clients mit dem Broker ausführen können, wie etwa Verbinden, Veröffentlichen oder Abonnieren von Themen. Konfigurieren Sie Azure IoT MQ (Vorschau) mithilfe der BrokerAuthorization-Ressource für die Verwendung einer oder mehrerer Autorisierungsrichtlinien.

Sie können für jeden Listener eine BrokerAuthorization festlegen. Jede BrokerAuthorization-Ressource enthält eine Liste von Regeln, die die Prinzipale und Ressourcen für die Autorisierungsrichtlinien angeben.

Wichtig

Damit die BrokerAuthorization-Konfiguration auf einen Listener angewendet werden kann, muss mindestens eine BrokerAuthentication ebenfalls mit dem betreffenden Listener verknüpft sein.

Konfigurieren von BrokerAuthorization für Listener

Die Spezifikation einer BrokerAuthorization-Ressource weist die folgenden Felder auf:

Feldname Erforderlich Beschreibung
listenerRef Ja Die Namen der BrokerListener-Ressourcen, die diese Autorisierungsrichtlinie anwendet. Dieses Feld ist erforderlich und muss mit einer vorhandenen BrokerListener-Ressource im selben Namespace übereinstimmen.
authorizationPolicies Ja Dieses Feld definiert die Einstellungen für die Autorisierungsrichtlinien, z. B. enableCache und rules.
enableCache No Gibt an, ob die Zwischenspeicherung für die Autorisierungsrichtlinien aktiviert werden soll. Bei Festlegung auf true speichert der Broker die Autorisierungsergebnisse für jede Client- und Themenkombination zwischen, um die Leistung zu verbessern und die Latenz zu verringern. Beim Wert false wertet der Broker die Autorisierungsrichtlinien für jede Client- und Themenanforderung aus, um Konsistenz und Genauigkeit sicherzustellen. Dieses Feld ist optional und hat den Standardwert false.
Regeln No Eine Liste von Regeln, die die Prinzipale und Ressourcen für die Autorisierungsrichtlinien angeben. Jede Regel weist diese Unterfelder auf: principals und brokerResources.
Prinzipale Ja In diesem Unterfeld werden die Identitäten definiert, die die Clients darstellen, z. B. usernames, clientids und attributes.
usernames No Eine Liste der Benutzernamen, die den Clients entsprechen. Bei den Benutzernamen wird die Groß-/Kleinschreibung beachtet. Sie müssen mit den Benutzernamen übereinstimmen, die von den Clients während der Authentifizierung übergeben werden.
clientids No Eine Liste der Client-IDs, die den Clients entsprechen. Bei den Client-IDs wird die Groß-/Kleinschreibung beachtet. Sie müssen mit den Client-IDs übereinstimmen, die von den Clients während der Verbindung übergeben werden.
Attributen No Eine Liste der Schlüssel-Wert-Paare, die den Attributen der Clients entsprechen. Bei den Attributen wird die Groß-/Kleinschreibung beachtet. Sie müssen mit den Attributen übereinstimmen, die von den Clients während der Authentifizierung übergeben werden.
brokerResources Ja In diesem Unterfeld werden die Objekte definiert, die die Aktionen oder Themen darstellen, z. B. method und topics.
Methode Ja Der Typ von Aktion, den die Clients mit dem Broker ausführen können. Dieses Unterfeld ist erforderlich und kann einen der folgenden Werte aufweisen: Connect: Dieser Wert gibt an, dass die Clients eine Verbindung mit dem Broker herstellen können. Publish: Dieser Wert gibt an, dass die Clients Nachrichten in Themen im Broker veröffentlichen können. Subscribe: Dieser Wert gibt an, dass die Clients Themen im Broker abonnieren können.
topics Nein Eine Liste von Themen oder Themenmustern, die mit den Themen übereinstimmen, die von den Clients veröffentlicht oder abonniert werden können. Dieses Unterfeld ist erforderlich, wenn die Methode Abonnieren oder Veröffentlichen ist.

Das folgende Beispiel zeigt, wie Sie eine BrokerAuthorization-Ressource erstellen, die die Autorisierungsrichtlinien für einen Listener mit dem Namen my-listener definiert.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "my-listener" # change to match your listener name as needed
  authorizationPolicies:
    enableCache: true
    rules:
      - principals:
          usernames:
            - temperature-sensor
            - humidity-sensor
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.username}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Diese Brokerautorisierung ermöglicht Clients mit Benutzernamen temperature-sensor oder humidity-sensor bzw. Clients mit Attributen organization mit Wert contoso und city mit Wert seattle Folgendes:

  • Herstellen einer Verbindung mit dem Broker.
  • Veröffentlichen von Nachrichten in Telemetriethemen, für die ihre Benutzernamen und ihre Organisation als Geltungsbereich festgelegt sind. Beispiel:
    • temperature-sensor kann auf /telemetry/temperature-sensor und /telemetry/contoso veröffentlichen.
    • humidity-sensor kann auf /telemetry/humidity-sensor und /telemetry/contoso veröffentlichen.
    • some-other-username kann auf /telemetry/contoso veröffentlichen.
  • Abonnieren von Befehlsthemen mit dem Geltungsbereich ihrer Organisation. Beispiel:
    • temperature-sensor kann /commands/contoso abonnieren.
    • some-other-username kann /commands/contoso abonnieren.

Zum Erstellen dieser BrokerAuthorization-Ressource wenden Sie das YAML-Manifest auf Ihren Kubernetes-Cluster an.

Autorisieren von Clients, die X.509-Authentifizierung verwenden

Clients, die X.509-Zertifikate für die Authentifizierung verwenden, können für den Zugriff auf Ressourcen auf der Grundlage von X.509-Eigenschaften autorisiert werden, die in ihrem Zertifikat oder deren ausstellenden Zertifikaten weiter oben in der Kette vorhanden sind.

Mit Eigenschaften der Zertifikatkette mithilfe von Attributen

Zum Erstellen von Regeln auf der Grundlage von Eigenschaften aus dem Zertifikat eines Clients, dessen Stammzertifizierungsstelle oder einer Zwischenzertifizierungsstelle ist eine TOML-Datei mit Zertifikat-zu-Attribut-Zuordnungen erforderlich. Beispiel:

[root]
subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"

[root.attributes]
organization = "contoso"

[intermediate]
subject = "CN = Contoso Intermediate CA"

[intermediate.attributes]
city = "seattle"
foo = "bar"

[smart-fan]
subject = "CN = smart-fan"

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

Erstellen Sie zum Anwenden der Zuordnung eine TOML-Datei mit der Zertifikat-zu-Attribut-Zuordnung als Kubernetes-Geheimnis, und verweisen Sie in authenticationMethods.x509.attributes für die BrokerAuthentication-Ressource darauf.

Anschließend können Autorisierungsregeln auf Clients mit X.509-Zertifikaten mithilfe dieser Attribute angewendet werden.

Mit allgemeinem Clientzertifikat-Antragstellernamen als Benutzername

Zum Erstellen von Autorisierungsrichtlinien, die ausschließlich auf dem allgemeinen Client-Zertifikat-Antragstellernamen (CN) beruhen, erstellen Sie Regeln im Ausgang vom CN.

Wenn ein Client beispielsweise über ein Zertifikat mit Antragsteller CN = smart-lock verfügt, lautet sein Benutzername smart-lock. Erstellen Sie von dort aus Autorisierungsrichtlinien wie gewohnt.

Autorisieren von Clients, die Kubernetes-Dienstkontotoken verwenden

Autorisierungsattribute für SATs werden als Teil der Dienstkontoanmerkungen festgelegt. Um beispielsweise ein Autorisierungsattribut namens group mit dem Wert authz-sat hinzuzufügen, führen Sie diesen Befehl aus:

kubectl annotate serviceaccount mqtt-client aio-mq-broker-auth/group=authz-sat

Attributanmerkungen müssen mit aio-mq-broker-auth/ beginnen, um sie von anderen Anmerkungen zu unterscheiden.

Da die Anwendung über ein Autorisierungsattribut mit dem Namen authz-sat verfügt, muss kein clientId oder username angegeben werden. Die entsprechende BrokerAuthorization-Ressource verwendet dieses Attribut als Prinzipal. Beispiel:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "az-mqtt-non-tls-listener"
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Weitere Informationen und ein Beispiel finden Sie unter Set up Authorization Policy with Dapr Client (Einrichten einer Autorisierungsrichtlinie mit dem Dapr-Client).

Verteilter Zustandsspeicher

Der Azure IoT MQ-Broker stellt einen verteilten Zustandsspeicher (Distributed State Store, DSS) bereit, den Clients zum Speichern des Zustands verwenden können. Der DSS kann auch so konfiguriert werden, dass er hoch verfügbar ist.

Um die Autorisierung für Clients einzurichten, die den DSS verwenden, geben Sie die folgenden Berechtigungen an:

  • Berechtigung zum Veröffentlichen im Thema $services/statestore/_any_/command/invoke/request des Systemschlüsselwertspeichers
  • Berechtigung zum Abonnieren des Antwortthemas <response_topic>/# (während der ersten Veröffentlichung als Parameter festgelegt)

Aktualisieren der Autorisierung

Brokerautorisierungsressourcen können zur Laufzeit ohne Neustart aktualisiert werden. Alle Clients, die zum Zeitpunkt der Aktualisierung der Richtlinie verbunden sind, werden getrennt. Das Ändern des Richtlinientyps wird ebenfalls unterstützt.

kubectl edit brokerauthorization my-authz-policies

Deaktivieren der Autorisierung

Zum Deaktivieren der Autorisierung legen Sie in der BrokerListener-Ressource authorizationEnabled: false fest. Wenn die Richtlinie für das Zulassen aller Clients festgelegt ist, können alle authentifizierten Clients auf alle Vorgänge zugreifen.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: "my-listener"
  namespace: azure-iot-operations
spec:
  brokerRef: "my-broker"
  authenticationEnabled: false
  authorizationEnabled: false
  port: 1883

Nicht autorisiertes Veröffentlichen in MQTT 3.1.1

Wenn bei MQTT 3.1.1 eine Veröffentlichung abgelehnt wird, empfängt der Client einen PUBACK ohne Fehler, da die Protokollversion die Rückgabe von Fehlercodes nicht unterstützt. MQTTv5 gibt PUBACK mit Ursachencode 135 (Nicht autorisiert) zurück, wenn eine Veröffentlichung abgelehnt wird.

Zugehöriger Inhalt