Konfigurieren der MQTT-Brokerautorisierung

Wichtig

Diese Seite enthält Anweisungen zum Verwalten von Azure IoT Operations-Komponenten mithilfe von Kubernetes-Bereitstellungsmanifesten, die sich in der Vorschau befinden. Dieses Feature ist mit mehreren Einschränkungen versehen und sollte nicht für Produktionsworkloads verwendet werden.

Lesen Sie die ergänzenden Nutzungsbedingungen für Microsoft Azure Previews für rechtliche Bestimmungen, die für Azure-Features gelten, die sich in Der Betaversion, Vorschau oder auf andere Weise noch nicht in der allgemeinen Verfügbarkeit befinden.

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 den MQTT-Broker für die Verwendung einer oder mehrerer Autorisierungsrichtlinien mithilfe der BrokerAuthorization-Ressource. 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 einen wichtigen Unterschied im Vergleich zu BrokerAuthentication:

Wichtig

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

Weitere Informationen zu BrokerListener finden Sie in der 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 Referenz zur Brokerautorisierungs-API .

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 "Komponenten" den MQTT-Broker aus.

3. Wählen Sie die Registerkarte "Autorisierung" aus.

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

   

Azure CLI

Verwenden Sie den Befehl az iot ops broker authz apply, um eine Autorisierungsrichtlinie zu erstellen oder zu ändern.

az iot ops broker authz apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Gehen Sie in diesem Beispiel von einer Konfigurationsdatei my-authz-policy.json mit dem folgenden Inhalt aus, der im Startverzeichnis des Benutzers gespeichert ist:

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

Ein Beispielbefehl zum Erstellen einer neuen Autorisierungsrichtlinie mit dem Namen my-authz-policy lautet:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/my-authz-policy.json

Bizeps

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine .bicep-Datei 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: [
                '/sensor/{principal.clientId}'
                '/sensor/{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:
              - "/sensor/{principal.clientId}"
              - "/sensor/{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 oder Clients mit dem Attribut organization, mit den Werten contoso und city, und mit dem Wert seattle Folgendes:

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

Verwenden eines 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 möglicherweise nicht überprüft:

• Kubernetes SAT: Der Benutzername sollte nicht für die Autorisierung verwendet werden, da er nicht für MQTTv5 mit erweiterter Authentifizierung überprüft wird.
• X.509: Der Benutzername entspricht dem gemeinsamen Namen (CN) aus einem Zertifikat und kann für Autorisierungsregeln verwendet werden.
• Benutzerdefiniert: Der Benutzername sollte nur für Autorisierungsregeln verwendet werden, wenn die benutzerdefinierte Authentifizierung den Benutzernamen überprüft.

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. Verwenden Sie die folgende Konfiguration, um beispielsweise Clients mit Client-IDs zuzulassen, die mit ihrer Gebäudenummer beginnen, sich zu verbinden und in themenspezifisch auf ihr Gebäude bezogenen Bereichen zu veröffentlichen.

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}/sensor"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

Azure CLI

Verwenden Sie den Befehl az iot ops broker authz apply, um eine Autorisierungsrichtlinie zu erstellen oder zu ändern.

az iot ops broker authz apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Erstellen Sie in den Brokerautorisierungsregeln für Ihre Autorisierungsrichtlinie eine Konfigurationsdatei client-id-policy.json mit der folgenden Konfiguration, die im Heimverzeichnis des Benutzers gespeichert ist:

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

Ein Beispielbefehl zum Erstellen einer neuen Autorisierungsrichtlinie mit dem Namen client-id-authz-policy lautet:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/client-id-authz-policy.json

Bizeps

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine .bicep-Datei 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}/sensor'
              ]
            }
          ]
        }
      ]
    }
  }
}

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}/sensor"

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. Durch diese Designation 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

Sie können Clients autorisieren, die X.509-Zertifikate für die Authentifizierung verwenden , um auf Ressourcen basierend auf X.509-Eigenschaften zuzugreifen, die auf ihrem Zertifikat oder ihren ausstellenden Zertifikaten auf der Kette vorhanden sind.

Verwenden von Attributen

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

Um Autorisierungsrichtlinien ausschließlich basierend auf dem Betreff-CN des Clientzertifikats zu erstellen, erstellen Sie Regeln, die auf dem CN beruhen.

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-Wert 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"
        }
      ]
    }
  }
]

Azure CLI

Verwenden Sie den Befehl az iot ops broker authz apply, um eine Autorisierungsrichtlinie zu erstellen oder zu ändern.

az iot ops broker authz apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Gehen Sie in diesem Beispiel von einer Konfigurationsdatei my-authz-policy.json mit dem folgenden Inhalt aus, der im Startverzeichnis des Benutzers gespeichert ist:

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

Ein Beispielbefehl zum Erstellen einer neuen Autorisierungsrichtlinie mit dem Namen my-authz-policy lautet:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/my-authz-policy.json

Bizeps

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine .bicep-Datei 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 zu einem Beispiel finden Sie unter "Einrichten einer Autorisierungsrichtlinie mit Dapr Client".

Zustandsspeicher

Der MQTT-Broker bietet einen Zustandsspeicher , den Clients zum Speichern des Zustands verwenden können. Der Zustandsspeicher kann auch für 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
    ]
  },
]

Azure CLI

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
    ]
  },
]

Bizeps

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 (Englisch)

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 angegeben. Schreibzugriff wird mit write angegeben. Lese- und Schreibzugriff wird 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: für Globmusterabgleich
• string: für genauen Abgleich, z. B. wenn ein Schlüssel Zeichen enthält, die andernfalls als Muster (*, ?, [0-9]) abgeglichen werden
• binary: zum Abgleich mit einem Binärschlüssel

Das Feld keys gibt die Schlüssel an, die abgeglichen werden sollen. Die Schlüssel können nach Globmuster, als Tokenersatz 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}/sensor/*"
        ]
      },
      {
        "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"
        ]
      }
    ]
  }
]

Azure CLI

Gehen Sie in diesem Beispiel von einer Konfigurationsdatei aus, die im Startverzeichnis des Benutzers benannt state-store-authz-policy.json ist. Fügen Sie in den Brokerautorisierungsregeln für Ihre Autorisierungsrichtlinie eine ähnliche Konfiguration hinzu:

{
  "authorizationPolicies": {
    "cache": "Enabled",
    "rules": [
      {
        "brokerResources": [
          {
            "clientIds": [
              "{principal.attributes.building}*"
            ],
            "method": "Connect"
          },
          {
            "method": "Publish",
            "topics": [
              "sensors/{principal.attributes.building}/{principal.clientId}/sensor/*"
            ]
          },
          {
            "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"
            ]
          }
        ]
      }
    ]
  }
}

Ein Beispielbefehl zum Erstellen einer neuen Autorisierungsrichtlinie mit dem Namen state-store-authz-policy lautet:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/state-store-authz-policy.json

Bizeps

Um eine Autorisierungsrichtlinie zu bearbeiten, erstellen Sie eine .bicep-Datei 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: [
                '/sensor/{principal.username}'
                '/sensor/{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 (Englisch)

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 Runtime 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 "Komponenten" den MQTT-Broker aus.
3. Wählen Sie in der Liste den Brokerlistener aus, den Sie bearbeiten möchten.
4. Wählen Sie im Port, an dem Sie die Autorisierung deaktivieren möchten, im Dropdownmenü " Keine" aus.

Azure CLI

Verwenden Sie den Befehl "az iot ops broker listener port add ", um die Autorisierung für einen Port zu deaktivieren. Um die Authentifizierung zu deaktivieren, schließen Sie den --authz-ref Parameter nicht ein.

az iot ops broker listener port add --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker default --listener <ListenerName> --port <ListenerServicePort>

Im folgenden Beispiel wird die Autorisierung für Port 8884 für den Listener mit dem Namen aio-broker-loadbalancerdeaktiviert:

az iot ops broker listener port add --resource-group myResourceGroupName --instance myAioInstanceName --broker default --listener aio-broker-loadbalancer --authn-ref default --port 8884

Bizeps

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

• BrokerListener-Ressource
• Konfigurieren der Authentifizierung für einen BrokerListener
• Lernprogramm: TLS-, X.509-Clientauthentifizierung und attributbasierte Zugriffssteuerung (ABAC)-Autorisierung