Konfigurieren der MQTT-Brokerautorisierung

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

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 MQTT-Broker mithilfe der BrokerAuthorization-Ressource für die Verwendung einer oder mehrerer Autorisierungsrichtlinien. Jede BrokerAuthorization-Ressource enthält eine Liste von Regeln, die die Prinzipale und Ressourcen für die Autorisierungsrichtlinien angeben.

Verknüpfen von BrokerAuthorization mit BrokerListener

Um eine BrokerListener- mit einer BrokerAuthorization-Ressource zu verknüpfen, geben Sie das Feld authorizationRef in der Einstellung ports der BrokerListener-Ressource an. Ähnlich wie bei BrokerAuthentication kann die BrokerAuthorization-Ressource mit mehreren BrokerListener-Ports verknüpft werden. Die Autorisierungsrichtlinien gelten für alle verknüpften Listenerports. Es gibt jedoch einen wichtigen Unterschied im Vergleich zu BrokerAuthentication:

Wichtig

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

Weitere Informationen zu BrokerListener finden Sie unter BrokerListener-Ressource.

Autorisierungsregeln

Um die Autorisierung zu konfigurieren, erstellen Sie zuerst eine BrokerAuthorization-Ressource in Ihrem Kubernetes-Cluster. Die folgenden Abschnitte enthalten Beispiele zum Konfigurieren der Autorisierung für Clients, die Benutzernamen, Attribute, X.509-Zertifikate und Kubernetes-Dienstkontotoken (SATs) verwenden. Eine Liste der verfügbaren Einstellungen finden Sie in der API-Referenz zur Broker-Autorisierung.

Das folgende Beispiel zeigt, wie Sie eine BrokerAuthorization-Ressource mithilfe von Benutzernamen und Attributen erstellen:

Portal

1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.

2. Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.

3. Wählen Sie die Registerkarte Autorisierung.

4. Wählen Sie eine vorhandene Authentifizierungsrichtlinie aus, oder erstellen Sie eine neue, indem Sie Autorisierungsrichtlinie erstellen auswählen.

   

Bicep

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine Bicep-Datei .bicep mit folgendem Inhalt. Aktualisieren Sie die Einstellungen nach Bedarf, und ersetzen Sie die Platzhalterwerte wie <AIO_INSTANCE_NAME> durch Ihre eigenen Werte.

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

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

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

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

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            clientIds: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/telemetry/{principal.clientId}'
                '/telemetry/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
        }
      ]
    }
  }
}

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

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

Kubernetes (Vorschau)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          clientIds:
            - "temperature-sensor"
            - "humidity-sensor"
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.clientId}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

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

Diese Brokerautorisierung ermöglicht Clients mit den Client-IDs temperature-sensor oder humidity-sensor bzw. Clients mit dem Attribut organization mit dem Wert contoso oder city mit dem Wert seattle Folgendes:

• Herstellen einer Verbindung mit dem Broker.
• Veröffentlichen von Nachrichten in Telemetriethemen, für die ihre Client-IDs 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.

Verwenden des Benutzernamens für die Autorisierung

Um MQTT-Benutzernamen für die Autorisierung zu verwenden, geben Sie sie als Array unter principals.usernames an. Je nach Authentifizierungsmethode wird der Benutzername jedoch möglicherweise nicht überprüft:

• Kubernetes-SAT: Der Benutzername sollte nicht für die Autorisierung verwendet werden, da er nicht nach MQTTv5 mit erweiterter Authentifizierung überprüft wird.
• X.509: Der Benutzername entspricht dem allgemeinen Namen (CN) aus dem Zertifikat und kann für Autorisierungsregeln verwendet werden.
• Benutzerdefiniert: Der Benutzername sollte nur für Autorisierungsregeln verwendet werden, wenn er bei der benutzerdefinierten Authentifizierung überprüft wird.

Um Sicherheitsprobleme zu vermeiden, verwenden Sie den MQTT-Benutzernamen nur dann für die Brokerautorisierung, wenn er überprüft werden kann.

Weiteres Einschränken des Zugriffs basierend auf der Client-ID

Da das Feld principals ein logisches OR ist, können Sie den Zugriff basierend auf der Client-ID weiter einschränken, indem Sie das Feld clientIds zum Feld brokerResources hinzufügen. Um beispielsweise Kunden mit Kunden-IDs, die mit der Gebäudenummer beginnen, die Verbindung und Veröffentlichung von Telemetriedaten zu Themen zu ermöglichen, die sich auf ihr Gebäude beziehen, verwenden Sie die folgende Konfiguration:

Portal

Verwenden Sie in den Brokerautorisierungsregeln für Ihre Autorisierungsrichtlinie die folgende Konfiguration:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

Bicep

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine Bicep-Datei .bicep mit folgendem Inhalt. Aktualisieren Sie die Einstellungen nach Bedarf, und ersetzen Sie die Platzhalterwerte wie <AIO_INSTANCE_NAME> durch Ihre eigenen Werte.

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

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

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

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

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            attributes: [
              {
                building: 'building22'
              }
              {
                building: 'building23'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
              clientIds: [
                '{principal.attributes.building}*' // client IDs must start with building22
              ]
            }
            {
              method: 'Publish'
              topics: [
                'sensors/{principal.attributes.building}/{principal.clientId}/telemetry'
              ]
            }
          ]
        }
      ]
    }
  }
}

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

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

Kubernetes (Vorschau)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
    - principals:
        attributes:
          - building: "building22"
          - building: "building23"
      brokerResources:
      - method: Connect
        clientIds:
          - "{principal.attributes.building}*" # client IDs must start with building22
      - method: Publish
        topics:
          - "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"

Wenn clientIds nicht unter der Connect-Methode festgelegt wurde, kann ein Client mit einer beliebigen Client-ID eine Verbindung herstellen, solange das Attribut building auf building22 oder building23 festgelegt ist. Durch Hinzufügen des Felds clientIds können nur Clients mit Client-IDs, die mit building22 oder building23 beginnen, eine Verbindung herstellen. Dadurch wird nicht nur sichergestellt, dass der Client über das richtige Attribut verfügt, sondern auch, dass die Client-ID dem erwarteten Muster entspricht.

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.

Attribute verwenden

Um Regeln basierend auf Eigenschaften aus dem Zertifikat eines Clients, seiner Stammzertifizierungsstelle oder Zwischenstellen zu erstellen, definieren Sie die X.509-Attribute in der BrokerAuthorization-Ressource. Weitere Informationen finden Sie unter Zertifikatattribute.

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-broker-auth/group=authz-sat

Attributanmerkungen müssen mit aio-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:

Portal

Verwenden Sie in den Brokerautorisierungsregeln für Ihre Autorisierungsrichtlinie die folgende Konfiguration:

[
  {
    "brokerResources": [
      {
        "clientIds": [],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "odd-numbered-orders"
        ]
      },
      {
        "clientIds": [],
        "method": "Subscribe",
        "topics": [
          "orders"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "group": "authz-sat"
        }
      ]
    }
  }
]

Bicep

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine Bicep-Datei .bicep mit folgendem Inhalt. Aktualisieren Sie die Einstellungen nach Bedarf, und ersetzen Sie die Platzhalterwerte wie <AIO_INSTANCE_NAME> durch Ihre eigenen Werte.

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

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

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

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

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      rules: [
        {
          principals: {
            attributes: [
              {
                group: 'authz-sat'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                'odd-numbered-orders'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                'orders'
              ]
            }
          ]
        }
      ]
    }
  }
}

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

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

Kubernetes (Vorschau)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    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).

Zustandsspeicher

Der MQTT-Broker stellt einen Zustandsspeicher bereit, den Clients zum Speichern des Zustands verwenden können. Der Zustandsspeicher kann auch mit Hochverfügbarkeit konfiguriert werden.

Um die Autorisierung für Clients einzurichten, die den Zustandsspeicher verwenden, stellen Sie die folgenden Berechtigungen bereit:

• 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)

Zustandsspeicherschlüssel

Der Zugriff auf den Zustandsspeicher erfolgt über den MQTT-Broker im Thema statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Da Clients Zugriff auf das Thema haben, können Sie Schlüssel und Zugriffsebenen unter dem Abschnitt stateStoreResources der MQTT-Brokerkonfiguration brokerResources angeben.

Das Format des Abschnitts stateStoreResources setzt sich aus Zugriffsebene, einem Musterindikator und dem Muster zusammen.

Portal

Fügen Sie den Abschnitt stateStoreResources in die Regeln für Ihre Autorisierungsrichtlinie ein.

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

Bicep

Fügen Sie in Bicep den Abschnitt stateStoreResources in Ihre Autorisierungsrichtlinie ein.

stateStoreResources: [
  {
    method: '' // Values: read, write, readwrite 
    keyType: '' //Values: string, pattern, binary. Default is pattern
    keys: [
      // List of patterns to match
    ]
  }
  {
    method: 'ReadWrite'
    keyType: 'Binary'
    keys: [
      'xxxxxxxxxxxxxxxxxxxx'
    ]
  }
]

Kubernetes

Fügen Sie in Ihrer benutzerdefinierten Ressourcendefinition den Abschnitt stateStoreResources in Ihre Autorisierungsrichtlinie ein.

stateStoreResources:
  - method:  # Values: read, write, readwrite 
    keyType: # Values: string, pattern, binary. Default is pattern
    keys:
      - # List of patterns to match

Das Feld method gibt die Zugriffsebene an.

• Lesezugriff wird mit read, Schreibzugriff mit write und beides mit readwrite angegeben.
• Die Zugriffsebene ist erforderlich.
• Die Zugriffsebene „Lesen“ impliziert die Aktionen get und keynotify.
• Die Zugriffsebene „Schreiben“ impliziert die Aktionen set, del und vdel.

Das Feld keyType gibt den Typ des Schlüsselabgleichs an.

• pattern: Musterabgleich der Form Glob
• string: genauer Abgleich, z. B. wenn ein Schlüssel Zeichen enthält, die andernfalls als Muster (*, ?, [0-9]) abgeglichen werden
• binary: Abgleich mit einem Binärschlüssel

Das Feld keys gibt die Schlüssel an, die abgeglichen werden sollen. Die Schlüssel können nach dem Glob-Muster, als Tokenersetzungen oder als genaue Zeichenfolgen angegeben werden.

• Beispiele für den Glob-Stil:
  • colors/*: alle Schlüssel unter dem Präfix „colors/“
  • number[0-9]: ein beliebiger Schlüssel zwischen „number0“ und „number9“
  • char?: ein beliebiger Schlüssel mit dem Präfix „char“ und einem Suffix aus einem einzelnen Zeichen, z. B. „charA“
  • *: Vollzugriff auf alle Schlüssel
• Zustandsspeicherschlüssel unterstützen auch die Tokenersetzung, wenn der Schlüsseltyp pattern ist. Nur für diesen Zweck sind geschweifte Klammern zulässig. Beispiele für die Tokenersetzung:
  • clients/{principal.clientId}/*
  • usernames/{principal.username}/*
  • rooms/{principal.attributes.room}/*

Im Folgenden finden Sie ein Beispiel dafür, wie Sie Zustandsspeicherressourcen erstellen können:

Portal

Fügen Sie in den Brokerautorisierungsregeln für Ihre Autorisierungsrichtlinie eine ähnliche Konfiguration hinzu:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect"
      },
      {
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/telemetry/*"
        ]
      },
      {
        "method": "Subscribe",
        "topics": [
          "commands/{principal.attributes.organization}"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "17",
          "organization": "contoso"
        }
      ],
      "usernames": [
        "temperature-sensor",
        "humidity-sensor"
      ]
    },
    "stateStoreResources": [
      {
        "method": "Read",
        "keyType": "Pattern",
        "keys": [
          "myreadkey",
          "myotherkey?",
          "mynumerickeysuffix[0-9]",
          "clients/{principal.clientId}/*"
        ]
      },
      {
        "method": "ReadWrite",
        "keyType": "Binary",
        "keys": [
          "xxxxxxxxxxxxxxxxxxxx"
        ]
      }
    ]
  }
]

Bicep

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine Bicep-Datei .bicep mit folgendem Inhalt. Aktualisieren Sie die Einstellungen nach Bedarf, und ersetzen Sie die Platzhalterwerte wie <AIO_INSTANCE_NAME> durch Ihre eigenen Werte.

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

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

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

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

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      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}'
              ]
            }
          ]
          stateStoreResources: [
            {
              method: 'Read'
              keyType: 'Pattern'
              keys: [
                'myreadkey'
                'myotherkey?'
                'mynumerickeysuffix[0-9]'
                'clients/{principal.clientId}/*'
              ]
            }
            {
              method: 'ReadWrite'
              keyType: 'Binary'
              keys: [
                'xxxxxxxxxxxxxxxxxxxx'
              ]
            }
          ]
        }
      ]
    }
  }
}

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

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

Kubernetes

stateStoreResources:
  - method: Read # Read includes Get, Notify
    keyType: "pattern" # string, pattern, binary
    keys:
      - "myreadkey" # explicit read access on key: myreadkey
      - "myotherkey?" # single digit wildcard
      - "mynumerickeysuffix[0-9]" # single digit number range
      - "clients/{principal.clientId}/*" # use token substitution and a wildcard for per-client sandboxing
  - method: ReadWrite  # ReadWrite access includes Get, Notify, Set, Del
    keyType: "binary" # binary keys have exact match, no patterns
    keys:
      - "xxxxxxxxxxxxxxxxxxxx"  # base-64 encoded binary key.

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

Portal

1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
2. Wählen Sie unter Azure IoT Einsatz-Ressourcen die Option MQTT-Broker aus.
3. Wählen Sie in der Liste den Brokerlistener aus, den Sie bearbeiten möchten.
4. Wählen Sie für den Port, an dem Sie die Autorisierung deaktivieren möchten, in der Dropdownliste für die Aktualisierung die Option Keine aus.

Bicep

Zum Deaktivieren der Autorisierung lassen Sie authorizationRef in der ports-Einstellung Ihrer BrokerListener-Ressource aus.

Kubernetes (Vorschau)

Zum Deaktivieren der Autorisierung lassen Sie authorizationRef in der ports-Einstellung Ihrer BrokerListener-Ressource aus.

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

• Informationen zur BrokerListener-Ressource
• Konfigurieren der Authentifizierung für einen BrokerListener