Поделиться через


Настройка авторизации брокера MQTT

Внимание

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

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

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

Как оцениваются правила

  • Политики доступны только для разрешения. Если правило явно не разрешает действие в ресурсе для субъекта, действие отказано.
  • Правило определяется тремя факторами: субъектами (субъектом), действием (операции подключения, публикации и подписки или хранилища состояний), а также ресурсами (разделами или ключами).
  • Субъекты в правиле соответствуют логическим ИЛИ. Например, любое указанное имя пользователя, clientId или сопоставление атрибутов предоставляет доступ к ресурсам в правиле.

Подстановочные знаки и подстановочные знаки

  • Для разделов и ключей можно использовать подстановку маркеров для создания правил, которые адаптируются для каждого клиента: {principal.username}, {principal.clientId}и {principal.attributes.<attributeName>}.
  • Подстановочные знаки + раздела MQTT и # поддерживаются в brokerResources.topics.
  • При использовании подстановки маркеров в разделе маркер должен быть единственным текстом в его сегменте пути. Например, допустимо, clients/{principal.clientId}/# но client-{principal.clientId}/# не является.
  • Действия подключения не должны включать разделы.

Чтобы связать ресурс BrokerListener с ресурсом BrokerAuthorization, укажите authorizationRef поле в ports параметре ресурса BrokerListener. Аналогично BrokerAuthentication, ресурс BrokerAuthorization можно связать с несколькими портами BrokerListener. Политики авторизации применяются ко всем связанным портам прослушивателя. Существует одно ключевое различие по сравнению с BrokerAuthentication:

Внимание

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

Дополнительные сведения о BrokerListener см. в ресурсе BrokerListener.

Правила авторизации

Чтобы настроить авторизацию, создайте ресурс BrokerAuthorization в кластере Kubernetes. В следующих разделах приведены примеры настройки авторизации для клиентов, использующих имена пользователей, атрибуты, сертификаты X.509 и маркеры учетных записей службы Kubernetes (SATs). Список доступных параметров см . в справочнике по API авторизации брокера.

В следующем примере показано, как создать ресурс BrokerAuthorization с помощью имени пользователя и атрибутов.

  1. В портал Azure перейдите к экземпляру Операций Интернета вещей.

  2. В разделе "Компоненты" выберите MQTT Broker.

  3. Перейдите на вкладку Authorization (Авторизация).

  4. Выберите существующую политику проверки подлинности или создайте новую, выбрав "Создать политику авторизации".

    Снимок экрана: использование портал Azure для создания правил авторизации брокера.

Эта авторизация брокера позволяет клиентам с идентификаторами клиента или temperature-sensorклиентами с атрибутамиhumidity-sensororganization, значениями и contosoзначением , а также со значением cityseattle:

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

Использование имени пользователя для авторизации

Чтобы использовать имя пользователя MQTT для авторизации, укажите их как массив в разделе principals.usernames. В зависимости от метода проверки подлинности имя пользователя может быть не проверено:

  • Kubernetes SAT: имя пользователя не должно использоваться для авторизации, так как оно не проверено для MQTTv5 с расширенной проверкой подлинности.
  • X.509: имя пользователя соответствует общему имени (CN) из сертификата и может использоваться для правил авторизации.
  • Custom: имя пользователя должно использоваться только для правил авторизации, если пользовательская проверка подлинности проверяет имя пользователя.

Чтобы предотвратить проблемы с безопасностью, используйте имя пользователя MQTT для авторизации брокера только при его проверке.

Подсказка

Чтобы требовать, чтобы имя пользователя MQTT соответствовало идентификатору клиента, используйте подстановку маркеров:

principals:
  usernames:
    - "{principal.clientId}"

Дальнейшее ограничение доступа на основе идентификатора клиента

principals Так как поле является логическимOR, вы можете дополнительно ограничить доступ на основе идентификаторов клиентов, добавив clientIds поле в brokerResources поле. Например, чтобы разрешить клиентам с идентификаторами, начинающимися с их номера здания, подключаться и публиковать в темах, связанных с их зданием, используйте следующую конфигурацию:

В правилах авторизации брокера для политики авторизации используйте следующую конфигурацию:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/sensor"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

Здесь, если clientIds параметр не задан в методе Connect , клиент с любым идентификатором клиента может подключиться до тех пор, пока он имеет building атрибут building22building23или. При добавлении clientIds поля только клиенты с идентификаторами клиентов, которые начинаются с building22 или building23 могут подключаться. Это обозначение гарантирует, что клиент имеет правильный атрибут и что идентификатор клиента соответствует ожидаемому шаблону.

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

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

Использование атрибутов

Чтобы создать правила на основе свойств сертификата клиента, его корневого ЦС или промежуточного ЦС, определите атрибуты X.509 в ресурсе BrokerAuthorization. Дополнительные сведения см. в разделе "Атрибуты сертификата".

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

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

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

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

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

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

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

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

В правилах авторизации брокера для политики авторизации используйте следующую конфигурацию:

[
  {
    "brokerResources": [
      {
        "clientIds": [],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "odd-numbered-orders"
        ]
      },
      {
        "clientIds": [],
        "method": "Subscribe",
        "topics": [
          "orders"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "group": "authz-sat"
        }
      ]
    }
  }
]

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

Хранилище состояний

Брокер MQTT предоставляет хранилище состояний, которое клиенты могут использовать для хранения состояния. Вы также можете настроить хранилище состояний для высокой доступности.

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

  • Публикация запросов в: statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke
  • Подпишитесь на раздел ответа, который вы устанавливаете для публикации, обычно: clients/{principal.clientId}/services/statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke/response/#
  • Предоставьте доступ к ключу в stateStoreResources соответствии с приведенными ниже рекомендациями.

Ключи хранилища состояний

Доступ к хранилищу состояний осуществляется через брокер MQTT в этой статье statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Так как клиенты имеют доступ к разделу, вы можете указать ключи и уровни доступа в stateStoreResources разделе конфигурации брокера brokerResources MQTT.

Формат stateStoreResources раздела состоит из уровня доступа, индикатора шаблона и шаблона.

stateStoreResources Включите раздел в правила политики авторизации.

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

Поле method указывает уровень доступа:

  • Для чтения указан readдоступ на чтение. Для записи указан writeдоступ к записи. Для чтения и записи указан readwriteдоступ.
  • Требуется уровень доступа.
  • Уровень доступа для чтения подразумевает действия get и keynotify.
  • Уровень доступа записи подразумевает действия set, delа также vdel.

Поле keyType указывает тип сопоставления ключей:

  • pattern: используется для сопоставления шаблонов в стиле glob.
  • string: используется для точного сопоставления, например, если ключ содержит символы, которые могут быть сопоставлены в противном случае как шаблон (*, , ?). [0-9]
  • binary: используется для сопоставления двоичного ключа.

Поле keys указывает ключи, которые будут соответствовать. Ключи можно указать в виде шаблонов, подстановок маркеров или точных строк.

  • Примеры стилей Glob:

    • colors/*: все ключи под префиксом "цвета/"
    • number[0-9]: любой ключ от "number0" до "number9"
    • char?: любой ключ с префиксом char и суффиксом одной цифры, например charA.
    • *: полный доступ ко всем ключам
  • Ключи хранилища состояний также поддерживают подстановку маркеров, если тип ключа и pattern фигурные скобки зарезервированы для этой цели. Примеры подстановки маркеров:

    • clients/{principal.clientId}/*
    • usernames/{principal.username}/*
    • rooms/{principal.attributes.room}/*

Ниже приведен пример создания ресурсов хранилища состояний.

В правилах авторизации брокера для политики авторизации добавьте аналогичную конфигурацию:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect"
      },
      {
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/sensor/*"
        ]
      },
      {
        "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"
        ]
      }
    ]
  }
]

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

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

kubectl edit brokerauthorization my-authz-policies

Поведение кэширования

Чтобы сократить расходы на авторизацию в разделах с высокой пропускной способностью, включите кэширование в памяти с authorizationPolicies.cache: Enabledпомощью .

  • Решения кэшируются на кортеж клиента, действия и ресурса. Повторяющиеся операции попали в кэш.
  • Ресурсы высокой переменной (например, уникальные сегменты разделов на сообщение) снижают скорость попадания кэша.
  • Кэш растет с числом уникальных кортежей. Отслеживайте память для очень высоких шаблонов оттока.

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

  1. В портал Azure перейдите к экземпляру Операций Интернета вещей.
  2. В разделе "Компоненты" выберите MQTT Broker.
  3. Выберите прослушиватель брокера, который вы хотите изменить из списка.
  4. На порту, в котором требуется отключить авторизацию, выберите "Нет " в раскрывающемся списке авторизации.

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

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

Устранение неполадок

Проверка правил

  1. Просмотрите yamL/JSON для брокера YAML/JSON, чтобы устранить проблемы с схемой.
  2. Проверьте выходные данные при применении конфигурации; Ошибки схемы сообщаются сервером API.
  3. Задайте для журналов pod интерфейсных debug модулей или traceперезапустите модули pod и проверьте наличие записей, помеченных с authz помощью синтаксического анализа и действующих правил.

Примеры работоспособных журналов (сокращенные):

<7>2025-02-10T16:28:31.986Z aio-broker-frontend-0 [mq@311 tid="1" module="authz"] - adding broker config ... and store config ...
<6>2025-02-10T16:28:31.986Z aio-broker-frontend-0 [mq@311 tid="1"] - starting broker authorization engine with basic rules. Cache enabled: true
<7>2025-02-10T16:28:31.987Z aio-broker-frontend-0 [mq@311 tid="1" module="authz"] - set broker authorization engine data: {"rules":[{...}]}

Операции брокера MQTT

Пример публикации запрещен:

<7>2025-02-10T16:32:19.398Z aio-broker-frontend-0 [mq@311 tid="15" module="authz"] - checking authorization for {"action":"publish","clientId":"test-publisher","topic":"test"}
<7>2025-02-10T16:32:19.411Z aio-broker-frontend-0 [mq@311 tid="15" module="authz"] - publish from client 'test-publisher' was denied ... reason_code: NotAuthorized

Операции хранилища состояний

Пример отказано в получении:

<7>2025-02-10T16:41:31.314Z aio-broker-frontend-0 [mq@311 tid="8" module="authz"] - checking authorization for {"action":"get","clientId":"statestore-cli","key":"dGVzdA=="}
<7>2025-02-10T16:41:31.322Z aio-broker-frontend-0 [mq@311 tid="8" module="authz"] - cached new authorization result ...: Denied("no rule matched")

Дальнейшие шаги