Delen via


MQTT-brokerautorisatie configureren

Belangrijk

Deze pagina bevat instructies voor het beheren van Azure IoT Operations-onderdelen met behulp van Kubernetes-implementatiemanifesten, die in preview zijn. Deze functie is voorzien van verschillende beperkingen en mag niet worden gebruikt voor productieworkloads.

Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Autorisatiebeleid bepaalt welke acties de clients op de broker kunnen uitvoeren, zoals verbinding maken, publiceren of abonneren op onderwerpen. Configureer MQTT-broker om een of meer autorisatiebeleidsregels te gebruiken met de BrokerAuthorization-resource . Elke BrokerAuthorization-resource bevat een lijst met regels waarmee de principals en resources voor het autorisatiebeleid worden opgegeven.

Als u een BrokerListener wilt koppelen aan een BrokerAuthorization-resource , geeft u het authorizationRef veld op in de ports instelling van de BrokerListener-resource . Net als bij BrokerAuthentication kan de BrokerAuthorization-resource worden gekoppeld aan meerdere BrokerListener-poorten . Het autorisatiebeleid is van toepassing op alle gekoppelde listenerpoorten. Er is echter één belangrijk verschil in vergelijking met BrokerAuthentication:

Belangrijk

Als u wilt dat de BrokerAuthorization-configuratie van toepassing is op een listenerpoort, moet ten minste één BrokerAuthentication ook zijn gekoppeld aan die listenerpoort.

Zie de BrokerListener-resource voor meer informatie over BrokerListener.

Autorisatieregels

Als u autorisatie wilt configureren, maakt u een BrokerAuthorization-resource in uw Kubernetes-cluster. De volgende secties bevatten voorbeelden van het configureren van autorisatie voor clients die gebruikmaken van gebruikersnamen, kenmerken, X.509-certificaten en Kubernetes Service Account Tokens (SAT's). Zie de naslaginformatie over de Broker Authorization-API voor een lijst met de beschikbare instellingen.

In het volgende voorbeeld ziet u hoe u een BrokerAuthorization-resource maakt met zowel gebruikersnamen als kenmerken:

  1. Navigeer in Azure Portal naar uw IoT Operations-exemplaar.

  2. Selecteer MQTT Broker onder Azure IoT Operations-resources.

  3. Selecteer het tabblad Autorisatie .

  4. Kies een bestaand verificatiebeleid of maak een nieuw verificatiebeleid door autorisatiebeleid maken te selecteren.

    Schermopname van Azure Portal om brokerautorisatieregels te maken.

Met deze brokerautorisatie kunnen clients met client-id's temperature-sensor of humidity-sensorclients met kenmerken organization met waarde contoso en city waarde seattle:

  • Maak verbinding met de broker.
  • Publiceer berichten naar telemetrieonderwerpen met hun client-id's en organisatie. Bijvoorbeeld:
    • temperature-sensor kan publiceren naar /telemetry/temperature-sensor en /telemetry/contoso.
    • humidity-sensor kan publiceren naar /telemetry/humidity-sensor en /telemetry/contoso.
    • some-other-username kan publiceren naar /telemetry/contoso.
  • Abonneren op opdrachten waarvoor een bereik is bereikt met hun organisatie. Bijvoorbeeld:
    • temperature-sensor kan zich abonneren op /commands/contoso.
    • some-other-username kan zich abonneren op /commands/contoso.

Gebruikersnaam gebruiken voor autorisatie

Als u de MQTT-gebruikersnaam voor autorisatie wilt gebruiken, geeft u deze op als een matrix onder principals.usernames. Afhankelijk van de verificatiemethode kan de gebruikersnaam echter niet worden geverifieerd:

  • Kubernetes SAT : gebruikersnaam mag niet worden gebruikt voor autorisatie omdat deze niet is geverifieerd voor MQTTv5 met verbeterde verificatie.
  • X.509 - Gebruikersnaam komt overeen met de CN van het certificaat en kan worden gebruikt voor autorisatieregels.
  • Aangepast : gebruikersnaam mag alleen worden gebruikt voor autorisatieregels als aangepaste verificatie de gebruikersnaam valideert.

Als u beveiligingsproblemen wilt voorkomen, gebruikt u alleen de MQTT-gebruikersnaam voor brokerautorisatie wanneer deze kan worden geverifieerd.

Toegang verder beperken op basis van client-id

Omdat het principals veld een logische OR is, kunt u de toegang verder beperken op basis van client-id door het clientIds veld toe te voegen aan het brokerResources veld. Gebruik bijvoorbeeld de volgende configuratie om clients met client-id's toe te staan die beginnen met het gebouwnummer om telemetrie te verbinden en te publiceren naar onderwerpen binnen het bereik van hun gebouw:

Gebruik de volgende configuratie in de brokerautorisatieregels voor uw autorisatiebeleid:

[
  {
    "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"
        }
      ]
    }
  }
]

Als de clientIds client niet is ingesteld onder de Connect methode, kan een client met een client-id verbinding maken zolang het building kenmerk is ingesteld op building22 of building23. Door het clientIds veld toe te voegen, worden alleen clients met client-id's toegevoegd die beginnen met building22 of building23 verbinding kunnen maken. Dit zorgt ervoor dat de client niet alleen het juiste kenmerk heeft, maar ook dat de client-id overeenkomt met het verwachte patroon.

Clients autoriseren die X.509-verificatie gebruiken

Clients die X.509-certificaten voor verificatie gebruiken, kunnen worden geautoriseerd voor toegang tot resources op basis van X.509-eigenschappen die aanwezig zijn op hun certificaat of hun verlenende certificaten in de keten.

Kenmerken gebruiken

Als u regels wilt maken op basis van eigenschappen van het certificaat van een client, de basis-CA of tussenliggende CA, definieert u de X.509-kenmerken in de BrokerAuthorization-resource . Zie Certificaatkenmerken voor meer informatie.

Met de algemene naam van het clientcertificaat als gebruikersnaam

Als u alleen autorisatiebeleid wilt maken op basis van de algemene naam van het clientcertificaat (CN), maakt u regels op basis van de CN.

Als een client bijvoorbeeld een certificaat met onderwerp CN = smart-lockheeft, is smart-lockde gebruikersnaam . Maak van daaruit autorisatiebeleid als normaal.

Clients autoriseren die kubernetes-serviceaccounttokens gebruiken

Autorisatiekenmerken voor SAT's worden ingesteld als onderdeel van de aantekeningen van het serviceaccount. Als u bijvoorbeeld een autorisatiekenmerk met de naam group waarde authz-satwilt toevoegen, voert u de opdracht uit:

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

Kenmerkaantekeningen moeten beginnen om aio-broker-auth/ deze te onderscheiden van andere aantekeningen.

Omdat de toepassing een autorisatiekenmerk heeft dat wordt aangeroepen authz-sat, hoeft u geen clientId of username. De bijbehorende BrokerAuthorization-resource gebruikt dit kenmerk als principal, bijvoorbeeld:

Gebruik in de Broker-autorisatieregels voor uw autorisatiebeleid de volgende configuratie:

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

Zie Autorisatiebeleid instellen met Dapr-client voor meer informatie met een voorbeeld.

Statusarchief

MQTT-broker biedt een statusarchief dat clients kunnen gebruiken om de status op te slaan. De statusopslag kan ook worden geconfigureerd om maximaal beschikbaar te zijn.

Als u autorisatie wilt instellen voor clients die gebruikmaken van het statusarchief, geeft u de volgende machtigingen op:

  • Machtiging om te publiceren naar het archiefonderwerp met de systeemsleutelwaarde $services/statestore/_any_/command/invoke/request
  • Machtiging om u te abonneren op het antwoordonderwerp (ingesteld tijdens de eerste publicatie als parameter) <response_topic>/#

Sleutels voor statusopslag

Het statusarchief wordt geopend via de MQTT-broker op onderwerp statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Omdat clients toegang hebben tot het onderwerp, kunt u sleutels en toegangsniveaus opgeven onder de stateStoreResources sectie van de MQTT-brokerconfiguratie brokerResources .

De stateStoreResources sectie-indeling bestaat uit toegangsniveau, een patroonindicator en het patroon.

Neem de stateStoreResources sectie op in de regels voor uw autorisatiebeleid.

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

Het method veld geeft het toegangsniveau op.

  • Leestoegang is opgegeven met read, schrijftoegang met writeen beide met readwrite.
  • Toegangsniveau is vereist.
  • Leestoegangsniveau impliceert de acties van get en keynotify.
  • Schrijftoegangsniveau impliceert de acties van set, delen vdel.

In keyType het veld wordt het type sleutelkoppeling opgegeven.

  • patternom een glob-stijlpatroon te gebruiken dat overeenkomt met
  • string om exacte overeenkomst uit te voeren, bijvoorbeeld wanneer een sleutel tekens bevat die anders kunnen worden vergeleken als een patroon (*, ?, [0-9])
  • binary overeenkomen met een binaire sleutel

In keys het veld worden de sleutels opgegeven die overeenkomen. De sleutels kunnen worden opgegeven als glob-stijlpatronen , tokenvervangingen of exacte tekenreeksen.

  • Voorbeelden van glob-stijl :
    • colors/*: Alle toetsen onder het voorvoegsel 'kleuren/'
    • number[0-9]: Een willekeurige sleutel van 'number0' naar 'number9'
    • char?: Elke sleutel met voorvoegsel "char" en één cijferachtervoegsel, zoals "charA"
    • *: Volledige toegang tot alle sleutels.
  • Sleutels voor statusopslag ondersteunen ook het vervangen van tokens wanneer het sleuteltype is pattern en accolades zijn gereserveerd voor dit doel. Voorbeelden van tokenvervanging:
    • clients/{principal.clientId}/*
    • usernames/{principal.username}/*
    • rooms/{principal.attributes.room}/*

Hier volgt een voorbeeld van hoe u resources voor de statusopslag kunt ontwerpen:

Voeg in de Broker-autorisatieregels voor uw autorisatiebeleid een vergelijkbare configuratie toe:

[
  {
    "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"
        ]
      }
    ]
  }
]

Autorisatie bijwerken

Brokerautorisatiebronnen kunnen tijdens runtime worden bijgewerkt zonder opnieuw op te starten. Alle clients die zijn verbonden op het moment van de update van het beleid, worden verbroken. Het wijzigen van het beleidstype wordt ook ondersteund.

kubectl edit brokerauthorization my-authz-policies

Autorisatie uitschakelen

  1. Navigeer in Azure Portal naar uw IoT Operations-exemplaar.
  2. Selecteer MQTT Broker onder Azure IoT Operations-resources.
  3. Selecteer de brokerlistener die u wilt bewerken in de lijst.
  4. Selecteer Geen in de vervolgkeuzelijst autorisatie op de poort die u wilt uitschakelen.

Niet-geautoriseerde publicatie in MQTT 3.1.1

Met MQTT 3.1.1 ontvangt de client, wanneer een publicatie wordt geweigerd, de PUBACK zonder fout omdat de protocolversie geen ondersteuning biedt voor het retourneren van foutcodes. MQTTv5 retourneert PUBACK met redencode 135 (niet geautoriseerd) wanneer publiceren wordt geweigerd.