Share via

Konfigurowanie autoryzacji usługi Azure IoT MQ (wersja zapoznawcza)

  • Artykuł

Ważne

Usługa Azure IoT Operations Preview — włączona przez usługę Azure Arc jest obecnie dostępna w wersji zapoznawczej. Nie należy używać tego oprogramowania w wersji zapoznawczej w środowiskach produkcyjnych.

Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

Zasady autoryzacji określają, jakie akcje mogą wykonywać klienci na brokerze, takie jak łączenie, publikowanie lub subskrybowanie tematów. Skonfiguruj usługę Azure IoT MQ w wersji zapoznawczej, aby używać jednej lub wielu zasad autoryzacji z zasobem BrokerAuthorization .

Dla każdego odbiornika można ustawić jedną wartość BrokerAuthorization . Każdy zasób BrokerAuthorization zawiera listę reguł określających podmioty zabezpieczeń i zasoby zasad autoryzacji.

Ważne

Aby konfiguracja BrokerAuthorization miała zastosowanie do odbiornika, co najmniej jeden brokerAuthentication musi być również połączony z tym odbiornikiem.

Konfigurowanie brokerAuthorization dla odbiorników

Specyfikacja zasobu BrokerAuthorization ma następujące pola:

Nazwa pola Wymagania opis
listenerRef Tak Nazwy zasobów BrokerListener, które mają zastosowanie te zasady autoryzacji. To pole jest wymagane i musi być zgodne z istniejącym zasobem BrokerListener w tej samej przestrzeni nazw.
authorizationPolicies Tak To pole definiuje ustawienia zasad autoryzacji, takie jak enableCache i reguły.
enableCache Nie. Czy włączyć buforowanie dla zasad autoryzacji. Jeśli ustawiono wartość true, broker buforuje wyniki autoryzacji dla każdego klienta i kombinacji tematu w celu zwiększenia wydajności i zmniejszenia opóźnienia. Jeśli ustawiono falsewartość , broker ocenia zasady autoryzacji dla każdego klienta i żądania tematu, aby zapewnić spójność i dokładność. To pole jest opcjonalne i domyślnie ma wartość false.
rules Nie. Lista reguł określających podmioty zabezpieczeń i zasoby zasad autoryzacji. Każda reguła ma następujące pola podrzędne: podmioty zabezpieczeń i brokerResources.
Podmiotów Tak To pole podrzędne definiuje tożsamości reprezentujące klientów, takie jak nazwy użytkowników, identyfikatory klienta i atrybuty.
Nazwy użytkownika Nie. Lista nazw użytkowników, które są zgodne z klientami. W nazwach użytkowników uwzględniana jest wielkość liter i musi być zgodna z nazwami użytkownika udostępnianymi przez klientów podczas uwierzytelniania.
clientids Nie. Lista identyfikatorów klientów, które są zgodne z klientami. Identyfikatory klientów są uwzględniane w wielkości liter i muszą być zgodne z identyfikatorami klienta dostarczonymi przez klientów podczas nawiązywania połączenia.
atrybuty Nie. Lista par klucz-wartość, które pasują do atrybutów klientów. Atrybuty są uwzględniane w wielkości liter i muszą być zgodne z atrybutami udostępnianymi przez klientów podczas uwierzytelniania.
brokerResources Tak To pole podrzędne definiuje obiekty reprezentujące akcje lub tematy, takie jak metoda i tematy.
metoda Tak Typ akcji, którą klienci mogą wykonać na brokerze. To pole podrzędne jest wymagane i może być jedną z następujących wartości: Połączenie: Ta wartość wskazuje, że klienci mogą łączyć się z brokerem. Publikuj: ta wartość wskazuje, że klienci mogą publikować komunikaty w tematach na brokerze. Subskrybuj: ta wartość wskazuje, że klienci mogą subskrybować tematy w brokerze.
Tematy Nie. Lista tematów lub wzorców tematów pasujących do tematów, do których klienci mogą publikować lub subskrybować. To pole podrzędne jest wymagane, jeśli metoda to Subskrybuj lub Publikuj.

W poniższym przykładzie pokazano, jak utworzyć zasób BrokerAuthorization , który definiuje zasady autoryzacji dla odbiornika o nazwie 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}"

Ta autoryzacja brokera umożliwia klientom z nazwami temperature-sensor użytkowników lub humidity-sensor, lub klientami z atrybutami organization z wartością contoso i city wartością seattle, do:

  • Połączenie do brokera.
  • Publikowanie komunikatów w tematach telemetrii o określonym zakresie przy użyciu ich nazw użytkowników i organizacji. Na przykład: .
    • temperature-sensor program może publikować w plikach /telemetry/temperature-sensor i /telemetry/contoso.
    • humidity-sensor program może publikować w plikach /telemetry/humidity-sensor i /telemetry/contoso.
    • some-other-username program może publikować w programie /telemetry/contoso.
  • Subskrybowanie tematów poleceń objętych zakresem ich organizacji. Na przykład: .
    • temperature-sensor program może subskrybować usługę /commands/contoso.
    • some-other-username program może subskrybować usługę /commands/contoso.

Aby utworzyć ten zasób BrokerAuthorization, zastosuj manifest YAML do klastra Kubernetes.

Autoryzowanie klientów korzystających z uwierzytelniania X.509

Klienci korzystający z certyfikatów X.509 do uwierzytelniania mogą mieć autoryzację dostępu do zasobów na podstawie właściwości X.509 znajdujących się w ich certyfikacie lub certyfikatów wystawiających łańcuch.

Z właściwościami łańcucha certyfikatów przy użyciu atrybutów

Aby utworzyć reguły na podstawie właściwości na podstawie certyfikatu klienta, jego głównego urzędu certyfikacji lub pośredniego urzędu certyfikacji, wymagany jest plik TOML mapowania certyfikatu na atrybuty. Na przykład:

[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"

W tym przykładzie każdy klient z certyfikatem wystawionym przez główny urząd certyfikacji CN = Contoso Root CA Cert, OU = Engineering, C = US lub pośredni urząd certyfikacji CN = Contoso Intermediate CA otrzymuje wymienione atrybuty. Ponadto inteligentny wentylator otrzymuje atrybuty specyficzne dla niego.

Dopasowanie atrybutów zawsze rozpoczyna się od certyfikatu klienta liścia, a następnie przechodzi wzdłuż łańcucha. Przypisanie atrybutu zostaje zatrzymane po pierwszym dopasowaniu. W poprzednim przykładzie, nawet jeśli smart-fan ma certyfikat CN = Contoso Intermediate CApośredni , nie pobiera skojarzonych atrybutów.

Aby zastosować mapowanie, utwórz plik TOML mapowania certyfikatu na atrybut jako wpis tajny Kubernetes i odwołaj się do niego w authenticationMethods.x509.attributes zasobie BrokerAuthentication.

Następnie reguły autoryzacji można stosować do klientów przy użyciu certyfikatów X.509 z tymi atrybutami.

W przypadku nazwy pospolitej podmiotu certyfikatu klienta jako nazwy użytkownika

Aby utworzyć zasady autoryzacji na podstawie nazwy pospolitej podmiotu certyfikatu klienta (CN), utwórz reguły na podstawie nazwy CN.

Jeśli na przykład klient ma certyfikat z podmiotem CN = smart-lock, jego nazwa użytkownika to smart-lock. Z tego miejsca utwórz zasady autoryzacji w zwykły sposób.

Autoryzowanie klientów korzystających z tokenów konta usługi Kubernetes Service

Atrybuty autoryzacji dla sieci SAN są ustawiane jako część adnotacji konta usługi. Aby na przykład dodać atrybut autoryzacji o nazwie group z wartością authz-sat, uruchom polecenie:

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

Adnotacje atrybutów muszą zaczynać się od aio-mq-broker-auth/ , aby odróżnić je od innych adnotacji.

Ponieważ aplikacja ma atrybut autoryzacji o nazwie authz-sat, nie ma potrzeby podawania elementu clientId lub username. Odpowiedni zasób BrokerAuthorization używa tego atrybutu jako podmiotu zabezpieczeń, na przykład:

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"

Aby dowiedzieć się więcej na przykładzie, zobacz Konfigurowanie zasad autoryzacji za pomocą klienta dapr.

Rozproszony magazyn stanów

Broker usługi Azure IoT MQ udostępnia rozproszony magazyn stanów (DSS), którego klienci mogą używać do przechowywania stanu. Usługę DSS można również skonfigurować pod kątem wysokiej dostępności.

Aby skonfigurować autoryzację dla klientów korzystających z usługi DSS, podaj następujące uprawnienia:

  • Uprawnienie do publikowania w temacie magazynu $services/statestore/_any_/command/invoke/request wartości klucza systemu
  • Uprawnienie do subskrybowania tematu odpowiedzi (ustawionego podczas początkowego publikowania jako parametru) <response_topic>/#

Aktualizowanie autoryzacji

Zasoby autoryzacji brokera można aktualizować w czasie wykonywania bez ponownego uruchamiania. Wszyscy klienci połączeni w momencie aktualizacji zasad są rozłączone. Zmiana typu zasad jest również obsługiwana.

kubectl edit brokerauthorization my-authz-policies

Wyłączanie autoryzacji

Aby wyłączyć autoryzację, ustaw wartość authorizationEnabled: false w zasobie BrokerListener. Gdy zasady mają zezwalać wszystkim klientom, wszyscy uwierzytelnieni klienci mogą uzyskiwać dostęp do wszystkich operacji.

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

Nieautoryzowane publikowanie w MQTT 3.1.1

W przypadku protokołu MQTT 3.1.1 po odmowie publikowania klient otrzymuje puBACK bez błędu, ponieważ wersja protokołu nie obsługuje zwracania kodu błędu. MQTTv5 zwraca puBACK z kodem przyczyny 135 (nieautoryzowanym) podczas odmowy publikowania.

Powiązana zawartość