Sdílet prostřednictvím

Konfigurace autorizace Azure IoT MQ Preview

  • Článek

Důležité

Azure IoT Operations Preview – Služba Azure Arc je aktuálně ve verzi PREVIEW. Tento software ve verzi Preview byste neměli používat v produkčních prostředích.

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 Azure IoT MQ Preview tak, aby používala jednu nebo více zásad autorizace s prostředkem BrokerAuthorization .

Pro každý naslouchací proces můžete nastavit jednu BrokerAuthorization . Každý prostředek BrokerAuthorization obsahuje seznam pravidel, která určují objekty zabezpečení a prostředky pro zásady autorizace.

Důležité

Pokud chcete, aby se naslouchací proces použila konfigurace BrokerAuthorization , musí být s tímto naslouchacím procesem propojena alespoň jedna funkce BrokerAuthentication .

Konfigurace BrokerAuthorization pro naslouchací procesy

Specifikace prostředku BrokerAuthorization má následující pole:

Název pole Požadováno Popis
listenerRef Ano Názvy prostředků BrokerListener, které se vztahují k této autorizační zásadě. Toto pole je povinné a musí odpovídat existujícímu prostředku BrokerListener ve stejném oboru názvů.
authorizationPolicies Ano Toto pole definuje nastavení pro zásady autorizace, například enableCache a pravidla.
enableCache No Jestli chcete povolit ukládání do mezipaměti pro zásady autorizace. Pokud je tato možnost nastavená, truezprostředkovatel ukládá výsledky autorizace do mezipaměti pro každou kombinaci klienta a tématu, aby se zlepšil výkon a snížila latence. Pokud je falsetato možnost nastavená, zprostředkovatel vyhodnocuje zásady autorizace pro každou žádost klienta a tématu, aby se zajistila konzistence a přesnost. Toto pole je volitelné a výchozí hodnota falseje .
pravidla No Seznam pravidel, která určují objekty zabezpečení a prostředky pro zásady autorizace. Každé pravidlo má tato dílčí pole: objekty zabezpečení a brokerResources.
Objekty Ano Toto dílčí pole definuje identity, které představují klienty, jako jsou uživatelská jména, id klienta a atributy.
Uživatelských jmen No Seznam uživatelských jmen, která odpovídají klientům. U uživatelských jmen se rozlišují malá a velká písmena a musí odpovídat uživatelským jménům poskytnutým klienty během ověřování.
clientids No Seznam ID klientů, které odpovídají klientům. ID klientů rozlišují malá a velká písmena a musí odpovídat ID klientům poskytnutým klienty během připojení.
atributy No Seznam párů klíč-hodnota, které odpovídají atributům klientů. V atributech se rozlišují malá a velká písmena a musí odpovídat atributům, které klienti během ověřování poskytují.
brokerResources Ano Toto dílčí pole definuje objekty, které představují akce nebo témata, jako jsou metody a témata.
metoda Ano Typ akce, kterou můžou klienti provádět u zprostředkovatele. Toto dílčí pole je povinné a může to být jedna z těchto hodnot: Připojení: Tato hodnota označuje, že se klienti mohou připojit ke zprostředkovateli. Publikování: Tato hodnota označuje, že klienti mohou publikovat zprávy do témat na zprostředkovateli. Přihlášení k odběru: Tato hodnota označuje, že klienti se mohou přihlásit k odběru témat na zprostředkovateli.
Témata No Seznam témat nebo vzorů témat, které odpovídají tématům, která můžou klienti publikovat nebo přihlásit k odběru. Toto dílčí pole se vyžaduje, pokud je metoda Přihlášení k odběru nebo publikování.

Následující příklad ukazuje, jak vytvořit prostředek BrokerAuthorization , který definuje zásady autorizace pro naslouchací proces s názvem my-listener.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "my-listener" # change to match your listener name as needed
  authorizationPolicies:
    enableCache: true
    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}"

Tato autorizace zprostředkovatele umožňuje klientům s uživatelskými jmény temperature-sensor nebo humidity-sensorklienty organization s atributy s hodnotou contoso a city hodnotou seattle:

  • Připojení zprostředkovateli.
  • Publikujte zprávy do témat telemetrie s vymezenými uživatelskými jmény 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/contososouboru .
  • 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.

Pokud chcete vytvořit tento prostředek BrokerAuthorization, použijte manifest YAML na cluster Kubernetes.

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.

S vlastnostmi řetězu certifikátů pomocí atributů

K vytvoření pravidel založených na vlastnostech z certifikátu klienta, jeho kořenové certifikační autority nebo zprostředkující certifikační autority se vyžaduje soubor TOML mapování atributů certifikátu. Příklad:

[root]
subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"

[root.attributes]
organization = "contoso"

[intermediate]
subject = "CN = Contoso Intermediate CA"

[intermediate.attributes]
city = "seattle"
foo = "bar"

[smart-fan]
subject = "CN = smart-fan"

[smart-fan.attributes]
building = "17"

V tomto příkladu každý klient, který má certifikát vydaný kořenovou certifikační autoritou nebo zprostředkující certifikační autoritou CN = Contoso Root CA Cert, OU = Engineering, C = USCN = Contoso Intermediate CA , obdrží uvedené atributy. Kromě toho inteligentní ventilátor přijímá atributy specifické pro něj.

Porovnávání atributů vždy začíná od klientského certifikátu typu list a pak pokračuje po řetězu. Přiřazení atributu se zastaví po první shodě. V předchozím příkladu, i když smart-fan má zprostředkující certifikát CN = Contoso Intermediate CA, nezískute přidružené atributy.

Pokud chcete mapování použít, vytvořte soubor TOML mapování certifikátu na atribut jako tajný klíč Kubernetes a odkazujte na něj authenticationMethods.x509.attributes pro prostředek BrokerAuthentication.

Autorizační pravidla se pak dají použít pro klienty používající certifikáty X.509 s těmito atributy.

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

Anotace atributů musí začínat aio-mq-broker-auth/ , aby se odlišily od jiných poznámek.

Vzhledem k tomu, že aplikace má název authz-satautorizač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:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "az-mqtt-non-tls-listener"
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Další informace najdete v tématu Nastavení zásad autorizace pomocí klienta Dapr.

Distribuované úložiště stavů

Azure IoT MQ Broker poskytuje distribuované úložiště stavu (DSS), které můžou klienti používat k ukládání stavu. DsS je také možné nakonfigurovat tak, aby byla vysoce dostupná.

Pokud chcete nastavit autorizaci pro klienty, kteří používají DSS, 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>/#

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

Pokud chcete zakázat autorizaci, nastavte authorizationEnabled: false v prostředku BrokerListener. Pokud je zásada nastavená tak, aby umožňovala všem klientům, mají všichni ověření klienti přístup ke všem operacím.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: "my-listener"
  namespace: azure-iot-operations
spec:
  brokerRef: "my-broker"
  authenticationEnabled: false
  authorizationEnabled: false
  port: 1883

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

Související obsah