Share via

Настройка предварительной версии авторизации Azure IoT MQ

  • Статья

Внимание

Предварительная версия операций Интернета вещей Azure, включенная Azure Arc в настоящее время находится в предварительной версии. Не следует использовать это программное обеспечение предварительной версии в рабочих средах.

Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.

Политики авторизации определяют действия, которые клиенты могут выполнять на брокере, например подключение, публикация или подписка на разделы. Настройте предварительную версию Azure IoT MQ, чтобы использовать одну или несколько политик авторизации с ресурсом BrokerAuthorization .

Для каждого прослушивателя можно задать одно значение BrokerAuthorization . Каждый ресурс BrokerAuthorization содержит список правил, определяющих субъекты и ресурсы для политик авторизации.

Внимание

Чтобы конфигурация BrokerAuthorization применялся к прослушивателю, необходимо также связать по крайней мере один брокерAuthentication с этим прослушивателем.

Настройка brokerAuthorization для прослушивателей

Спецификация ресурса BrokerAuthorization имеет следующие поля:

Имя поля Обязательное поле Описание
прослушивательRef Да Имена ресурсов BrokerListener, которые применяет эта политика авторизации. Это поле является обязательным и должно соответствовать существующему ресурсу BrokerListener в том же пространстве имен.
authorizationPolicies Да Это поле определяет параметры политик авторизации, таких как enableCache и правила.
enableCache No Следует ли включить кэширование для политик авторизации. Если задано значение true, брокер кэширует результаты авторизации для каждого клиента и сочетания разделов, чтобы повысить производительность и уменьшить задержку. Если задано значение false, брокер оценивает политики авторизации для каждого запроса клиента и раздела, чтобы обеспечить согласованность и точность. Это поле является необязательным и по falseумолчанию .
rules No Список правил, определяющих субъекты и ресурсы для политик авторизации. Каждое правило имеет эти подфилды: субъекты и брокерResources.
principals Да В этом подполе определяются удостоверения, представляющие клиенты, такие как имена пользователей, клиентские идентификаторы и атрибуты.
Имена No Список имен пользователей, соответствующих клиентам. Имена пользователей чувствительны к регистру и должны соответствовать именам пользователей, предоставляемым клиентами во время проверки подлинности.
clientids No Список идентификаторов клиентов, соответствующих клиентам. Идентификаторы клиентов чувствительны к регистру и должны соответствовать идентификаторам клиента, предоставляемым клиентами во время подключения.
атрибутов No Список пар "ключ-значение", которые соответствуют атрибутам клиентов. Атрибуты чувствительны к регистру и должны соответствовать атрибутам, предоставляемым клиентами во время проверки подлинности.
brokerResources Да В этом подфилде определяются объекты, представляющие действия или разделы, такие как метод и разделы.
метод Да Тип действия, которое клиенты могут выполнять на брокере. Это подфилд является обязательным и может быть одним из следующих значений: Подключение: это значение указывает, что клиенты могут подключаться к брокеру. Публикация: это значение указывает, что клиенты могут публиковать сообщения в разделах брокера. Подписка: это значение означает, что клиенты могут подписаться на разделы брокера.
topics No Список разделов или шаблонов тем, которые соответствуют темам, на которые клиенты могут публиковать или подписываться. Это подполея требуется, если метод подписки или публикации.

В следующем примере показано, как создать ресурс BrokerAuthorization , определяющий политики авторизации прослушивателя с именем 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}"

Эта авторизация брокера позволяет клиентам с именами пользователей или humidity-sensorклиентами с атрибутами organizationtemperature-sensor со значением contoso и city значениемseattle:

  • Подключение брокеру.
  • Публикация сообщений в разделах телеметрии, область с именами пользователей и организацией. Например:
    • temperature-sensor может публиковаться в /telemetry/temperature-sensor и /telemetry/contoso.
    • humidity-sensor может публиковаться в /telemetry/humidity-sensor и /telemetry/contoso.
    • some-other-username может публиковаться в /telemetry/contoso.
  • Подписываться на разделы команд, область с их организацией. Например:
    • temperature-sensor может подписаться на /commands/contoso.
    • some-other-username может подписаться на /commands/contoso.

Чтобы создать этот ресурс BrokerAuthorization, примените манифест YAML к кластеру Kubernetes.

Авторизация клиентов, использующих проверку подлинности X.509

Клиенты, использующие сертификаты X.509 для проверки подлинности , могут быть авторизованы для доступа к ресурсам на основе свойств X.509, присутствующих на их сертификате или их выдачи сертификатов вверх по цепочке.

Свойства цепочки сертификатов с помощью атрибутов

Чтобы создать правила на основе свойств сертификата клиента, его корневого ЦС или промежуточного ЦС, требуется сопоставление сертификатов с атрибутами TOML-файл. Например:

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

В этом примере каждый клиент, имеющий сертификат, выданный корневым ЦС или промежуточным ЦС CN = Contoso Root CA Cert, OU = Engineering, C = USCN = Contoso Intermediate CA , получает указанные атрибуты. Кроме того, смарт-вентилятор получает атрибуты, относящиеся к нему.

Сопоставление атрибутов всегда начинается с конечного сертификата клиента, а затем идет по цепочке. Назначение атрибута останавливается после первого совпадения. В предыдущем примере, даже если smart-fan имеется промежуточный сертификат CN = Contoso Intermediate CA, он не получает связанные атрибуты.

Чтобы применить сопоставление, создайте файл TOML сопоставления сертификатов и атрибутов в качестве секрета Kubernetes и сослаться на authenticationMethods.x509.attributes него для ресурса BrokerAuthentication.

Затем правила авторизации можно применять к клиентам с помощью сертификатов X.509 с этими атрибутами.

С общим именем субъекта сертификата клиента в качестве имени пользователя

Чтобы создать политики авторизации на основе общего имени субъекта сертификата клиента (CN), создайте правила на основе CN.

Например, если у клиента есть сертификат с субъектом CN = smart-lock, это имя пользователя smart-lock. После этого создайте политики авторизации как обычные.

Авторизация клиентов, использующих маркеры учетной записи службы Kubernetes

Атрибуты авторизации для STS задаются как часть заметок учетной записи службы. Например, чтобы добавить атрибут авторизации с именем group value authz-sat, выполните команду:

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

Заметки атрибутов должны начинаться с aio-mq-broker-auth/ различать их от других заметок.

Так как у приложения есть атрибут authz-satавторизации, нет необходимости предоставлять или clientIdusername. Соответствующий ресурс BrokerAuthorization использует этот атрибут в качестве субъекта, например:

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"

Дополнительные сведения см. в статье "Настройка политики авторизации с помощью клиента Dapr".

Распределенное хранилище состояний

Брокер MQ Azure IoT предоставляет распределенное хранилище состояний (DSS), которое клиенты могут использовать для хранения состояния. DsS также можно настроить для высокой доступности.

Чтобы настроить авторизацию для клиентов, использующих DSS, укажите следующие разрешения:

  • Разрешение на публикацию в разделе хранилища $services/statestore/_any_/command/invoke/request значений системного ключа
  • Разрешение на подписку на раздел ответа (задано во время первоначальной публикации в качестве параметра) <response_topic>/#

Обновление авторизации

Ресурсы авторизации брокера можно обновлять во время выполнения без перезапуска. Все клиенты, подключенные во время обновления политики, отключены. Изменение типа политики также поддерживается.

kubectl edit brokerauthorization my-authz-policies

Отключение авторизации

Чтобы отключить авторизацию, задайте authorizationEnabled: false в ресурсе BrokerListener. Если для политики задано разрешение всех клиентов, все прошедшие проверку подлинности клиенты могут получить доступ ко всем операциям.

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

Несанкционированная публикация в MQTT 3.1.1

С MQTT 3.1.1, когда публикация запрещена, клиент получает PUBACK без ошибки, так как версия протокола не поддерживает возврат кода ошибки. MQTTv5 возвращает PUBACK с кодом причины 135 (не авторизовано) при отклонении публикации.

Связанный контент