Konfigurace autorizace zprostředkovatele MQTT
Důležité
Tato stránka obsahuje pokyny ke správě komponent operací Azure IoT pomocí manifestů nasazení Kubernetes, které jsou ve verzi Preview. Tato funkce je poskytována s několika omezeními a neměla by se používat pro produkční úlohy.
Právní podmínky, které platí pro funkce Azure, které jsou ve verzi beta, verzi Preview nebo které zatím nejsou veřejně dostupné, najdete v Dodatečných podmínkách použití pro Microsoft Azure verze Preview.
Zásady autorizace určují, jaké akce můžou klienti provádět u zprostředkovatele, jako je připojení, publikování nebo přihlášení k odběru témat. Nakonfigurujte zprostředkovatele MQTT tak, aby používal jednu nebo více zásad autorizace s prostředkem BrokerAuthorization . Každý prostředek BrokerAuthorization obsahuje seznam pravidel, která určují objekty zabezpečení a prostředky pro zásady autorizace.
Propojení BrokerAuthorization s BrokerListener
Pokud chcete propojit BrokerListener s prostředkem BrokerAuthorization , zadejte authorizationRef
pole v ports
nastavení prostředku BrokerListener . Podobně jako BrokerAuthentication může být prostředek BrokerAuthorization propojený s několika porty BrokerListener . Zásady autorizace platí pro všechny porty propojeného naslouchacího procesu. V porovnání s BrokerAuthentication ale existuje jeden klíčový rozdíl:
Důležité
Pokud chcete, aby se na port naslouchacího procesu použila konfigurace BrokerAuthorization , musí být s tímto portem naslouchacího procesu propojena alespoň jedna služba BrokerAuthentication.
Další informace o BrokerListener najdete v tématu Prostředek BrokerListener.
Autorizační pravidla
Pokud chcete nakonfigurovat autorizaci, vytvořte v clusteru Kubernetes prostředek BrokerAuthorization . Následující části obsahují příklady konfigurace autorizace pro klienty, kteří používají uživatelská jména, atributy, certifikáty X.509 a tokeny účtů služby Kubernetes Service (SAT). Seznam dostupných nastavení najdete v referenčních informacích k rozhraní API pro autorizaci zprostředkovatele.
Následující příklad ukazuje, jak vytvořit prostředek BrokerAuthorization pomocí uživatelských jmen i atributů:
Na webu Azure Portal přejděte k vaší instanci ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte kartu Autorizace.
Vyberte existující zásady ověřování nebo vytvořte novou tak, že vyberete Vytvořit zásadu autorizace.
Tato autorizace zprostředkovatele umožňuje klientům s ID temperature-sensor
klienta nebo humidity-sensor
klienty organization
s atributy s hodnotou contoso
a city
hodnotou seattle
:
- Připojte se ke zprostředkovateli.
- Publikujte zprávy do témat telemetrie s vymezenými ID klienta a organizací. Příklad:
temperature-sensor
může publikovat do/telemetry/temperature-sensor
a/telemetry/contoso
.humidity-sensor
může publikovat do/telemetry/humidity-sensor
a/telemetry/contoso
.some-other-username
může publikovat do/telemetry/contoso
souboru .
- Přihlaste se k odběru témat příkazů s oborem organizace. Příklad:
temperature-sensor
může přihlásit k odběru/commands/contoso
.some-other-username
může přihlásit k odběru/commands/contoso
.
Použití uživatelského jména pro autorizaci
Chcete-li použít uživatelské jméno MQTT pro autorizaci, zadejte je jako pole v části principals.usernames
. V závislosti na metodě ověřování ale nemusí být uživatelské jméno ověřeno:
- Kubernetes SAT – Uživatelské jméno by se nemělo používat k autorizaci, protože se neověřuje pro MQTTv5 s rozšířeným ověřováním.
- X.509 – Uživatelské jméno odpovídá cn z certifikátu a lze ho použít pro autorizační pravidla.
- Vlastní – Uživatelské jméno by se mělo používat jenom pro autorizační pravidla, pokud vlastní ověřování ověří uživatelské jméno.
Pokud chcete zabránit problémům se zabezpečením, použijte uživatelské jméno MQTT pouze pro autorizaci zprostředkovatele, když je možné ověřit.
Další omezení přístupu na základě ID klienta
principals
Vzhledem k tomu, že toto pole je logické NEBO, můžete dále omezit přístup na základě ID klienta takclientIds
, že pole přidáte brokerResources
do pole. Pokud chcete například klientům s ID klientů, kteří začínají číslem budovy, připojovat a publikovat telemetrii do témat s vymezeným sestavením, použijte následující konfiguraci:
V autorizačních pravidlech zprostředkovatele pro zásady autorizace použijte následující konfiguraci:
[
{
"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"
}
]
}
}
]
Pokud clientIds
nebyla v metodě nastavena Connect
, klient s libovolným ID klienta se může připojit, pokud měl building
atribut nastavený na building22
nebo building23
. clientIds
Přidáním pole se můžou připojit jenom klienti s ID klientů, kteří začínají building22
nebo building23
se můžou připojit. Tím se zajistí nejen to, že klient má správný atribut, ale také že ID klienta odpovídá očekávanému vzoru.
Autorizace klientů, kteří používají ověřování X.509
Klienti, kteří k ověřování používají certifikáty X.509, mohou mít oprávnění pro přístup k prostředkům na základě vlastností X.509, které jsou přítomné na svém certifikátu nebo vysílají certifikáty v řetězu.
Použití atributů
Pokud chcete vytvořit pravidla založená na vlastnostech z certifikátu klienta, jeho kořenové certifikační autority nebo zprostředkující certifikační autority, definujte atributy X.509 v prostředku BrokerAuthorization . Další informace naleznete v tématu Atributy certifikátu.
Běžný název subjektu klientského certifikátu jako uživatelské jméno
Pokud chcete vytvořit zásady autorizace založené pouze na běžném názvu subjektu certifikátu klienta (CN), vytvořte pravidla založená na cn.
Pokud má klient například certifikát s předmětem CN = smart-lock
, jeho uživatelské jméno je smart-lock
. Odsud vytvořte zásady autorizace jako obvykle.
Autorizace klientů, kteří používají tokeny účtů služby Kubernetes Service
Atributy autorizace pro SAT jsou nastavené jako součást poznámek účtu služby. Pokud například chcete přidat atribut autorizace s názvem group
hodnota authz-sat
, spusťte příkaz:
kubectl annotate serviceaccount mqtt-client aio-broker-auth/group=authz-sat
Anotace atributů musí začínat aio-broker-auth/
, aby se odlišily od jiných poznámek.
Vzhledem k tomu, že aplikace má název authz-sat
autorizačního atributu , není nutné zadávat clientId
ani username
. Odpovídající prostředek BrokerAuthorization používá tento atribut jako objekt zabezpečení, například:
V autorizačních pravidlech zprostředkovatele pro zásady autorizace použijte následující konfiguraci:
[
{
"brokerResources": [
{
"clientIds": [],
"method": "Connect",
"topics": []
},
{
"clientIds": [],
"method": "Publish",
"topics": [
"odd-numbered-orders"
]
},
{
"clientIds": [],
"method": "Subscribe",
"topics": [
"orders"
]
}
],
"principals": {
"attributes": [
{
"group": "authz-sat"
}
]
}
}
]
Další informace najdete v tématu Nastavení zásad autorizace pomocí klienta Dapr.
Úložiště stavů
Zprostředkovatel MQTT poskytuje úložiště stavu, které můžou klienti použít k uložení stavu. Úložiště stavů je také možné nakonfigurovat tak, aby bylo vysoce dostupné.
Pokud chcete nastavit autorizaci pro klienty, kteří používají úložiště stavů, zadejte následující oprávnění:
- Oprávnění k publikování do tématu úložiště
$services/statestore/_any_/command/invoke/request
hodnot systémového klíče - Oprávnění k přihlášení k odběru tématu odpovědi (nastavené během počátečního publikování jako parametru)
<response_topic>/#
Klíče úložiště stavu
K úložišti stavů se přistupuje přes zprostředkovatele MQTT v tématu statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke
.
Vzhledem k tomu, že klienti mají přístup k tématu, můžete zadat klíče a úrovně přístupu v stateStoreResources
části konfigurace zprostředkovatele brokerResources
MQTT.
Formát stateStoreResources
oddílu se skládá z úrovně přístupu, indikátoru vzoru a vzoru.
stateStoreResources
Do pravidel pro zásady autorizace zahrňte oddíl.
"stateStoreResources": [
{
"method": "", // Values: read, write, readwrite
"keyType": "", //Values: string, pattern, binary. Default is pattern
"keys": [
// List of patterns to match
]
},
]
Pole method
určuje úroveň přístupu.
- Přístup pro čtení je zadán pomocí
read
, zápisu swrite
, s , a obojí sreadwrite
. - Vyžaduje se úroveň přístupu.
- Úroveň přístupu pro čtení znamená akce a
get
keynotify
. - Úroveň přístupu k zápisu znamená akce
set
,del
avdel
.
Pole keyType
určuje typ párování klíčů.
pattern
použití porovnávání vzorů ve stylu globustring
pro přesnou shodu, například když klíč obsahuje znaky, které by jinak odpovídaly vzoru (*
,?
,[0-9]
)binary
pro shodu s binárním klíčem
Pole keys
určuje klíče, které se mají shodovat. Klíče lze zadat jako vzory stylu Globu , nahrazení tokenů nebo přesné řetězce.
- Příklady stylu globu :
colors/*
: Všechny klávesy pod předponou "colors/"number[0-9]
: Libovolný klíč od "number0" do "number9"char?
: Libovolný klíč s předponou "char" a příponou s jednou číslicí, například "charA".*
: Úplný přístup ke všem klíčům.
- Klíče úložiště stavů také podporují nahrazení tokenů, pokud je
pattern
typ klíče a složené závorky jsou pro tento účel vyhrazeny. Příklady nahrazení tokenů:clients/{principal.clientId}/*
usernames/{principal.username}/*
rooms/{principal.attributes.room}/*
Tady je příklad, jak můžete vytvářet prostředky úložiště stavu:
V autorizačních pravidlech zprostředkovatele pro zásady autorizace přidejte podobnou konfiguraci:
[
{
"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"
]
}
]
}
]
Aktualizace autorizace
Prostředky autorizace zprostředkovatele je možné aktualizovat za běhu bez restartování. Všichni klienti připojení v době aktualizace zásad jsou odpojeni. Podporuje se také změna typu zásady.
kubectl edit brokerauthorization my-authz-policies
Zakázání autorizace
- Na webu Azure Portal přejděte k vaší instanci ioT Operations.
- V části Součásti vyberte Zprostředkovatele MQTT.
- Ze seznamu vyberte naslouchací proces zprostředkovatele, který chcete upravit.
- Na portu, který chcete zakázat autorizaci, vyberte v rozevíracím seznamu Autorizace možnost Žádné .
Neoprávněné publikování v MQTT 3.1.1
U MQTT 3.1.1, když je publikování odepřeno, klient obdrží PUBACK bez chyby, protože verze protokolu nepodporuje vrácení kódu chyby. MQTTv5 vrátí PUBACK s kódem důvodu 135 (neautorizováno) při odepření publikování.