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.
BrokerAuthorization koppelen aan BrokerListener
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:
Navigeer in Azure Portal naar uw IoT Operations-exemplaar.
Selecteer MQTT Broker onder Azure IoT Operations-resources.
Selecteer het tabblad Autorisatie .
Kies een bestaand verificatiebeleid of maak een nieuw verificatiebeleid door autorisatiebeleid maken te selecteren.
Met deze brokerautorisatie kunnen clients met client-id's temperature-sensor
of humidity-sensor
clients 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-lock
heeft, is smart-lock
de 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-sat
wilt 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 metwrite
en beide metreadwrite
. - Toegangsniveau is vereist.
- Leestoegangsniveau impliceert de acties van
get
enkeynotify
. - Schrijftoegangsniveau impliceert de acties van
set
,del
envdel
.
In keyType
het veld wordt het type sleutelkoppeling opgegeven.
pattern
om een glob-stijlpatroon te gebruiken dat overeenkomt metstring
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
- Navigeer in Azure Portal naar uw IoT Operations-exemplaar.
- Selecteer MQTT Broker onder Azure IoT Operations-resources.
- Selecteer de brokerlistener die u wilt bewerken in de lijst.
- 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.