Настройка авторизации брокера MQTT
Внимание
На этой странице содержатся инструкции по управлению компонентами Операций Интернета вещей Azure с помощью манифестов развертывания Kubernetes, которые доступны в предварительной версии. Эта функция предоставляется с несколькими ограничениями и не должна использоваться для рабочих нагрузок.
Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Политики авторизации определяют действия, которые клиенты могут выполнять на брокере, например подключение, публикация или подписка на разделы. Настройте брокер MQTT для использования одной или нескольких политик авторизации с ресурсом BrokerAuthorization . Каждый ресурс BrokerAuthorization содержит список правил, определяющих субъекты и ресурсы для политик авторизации.
Связывание BrokerAuthorization с BrokerListener
Чтобы связать brokerListener с ресурсом BrokerAuthorization, укажите authorizationRef
поле в ports
параметре ресурса BrokerListener. Аналогично BrokerAuthentication, ресурс BrokerAuthorization можно связать с несколькими портами BrokerListener . Политики авторизации применяются ко всем связанным портам прослушивателя. Однако есть одно ключевое различие по сравнению с BrokerAuthentication:
Внимание
Для применения конфигурации BrokerAuthorization к порту прослушивателя необходимо также связать хотя бы один брокерAuthentication с этим портом прослушивателя.
Дополнительные сведения о BrokerListener см. в ресурсе BrokerListener.
Правила авторизации
Чтобы настроить авторизацию, создайте ресурс BrokerAuthorization в кластере Kubernetes. В следующих разделах приведены примеры настройки авторизации для клиентов, использующих имена пользователей, атрибуты, сертификаты X.509 и маркеры учетных записей службы Kubernetes (SATs). Список доступных параметров см . в справочнике по API авторизации брокера.
В следующем примере показано, как создать ресурс BrokerAuthorization с помощью имени пользователя и атрибутов:
В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.
Перейдите на вкладку Authorization (Авторизация).
Выберите существующую политику проверки подлинности или создайте новую, выбрав "Создать политику авторизации".
Эта авторизация брокера позволяет клиентам с идентификаторами клиентов или humidity-sensor
клиентами с атрибутами organization
temperature-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
.
Использование имени пользователя для авторизации
Чтобы использовать имя пользователя MQTT для авторизации, укажите их как массив в разделе principals.usernames
. Однако в зависимости от метода проверки подлинности имя пользователя может быть не проверено:
- Kubernetes SAT — имя пользователя не должно использоваться для авторизации, так как оно не проверено для MQTTv5 с расширенной проверкой подлинности.
- X.509 — имя пользователя соответствует cn из сертификата и может использоваться для правил авторизации.
- Custom — имя пользователя должно использоваться только для правил авторизации, если пользовательская проверка подлинности проверяет имя пользователя.
Чтобы предотвратить проблемы с безопасностью, используйте только имя пользователя MQTT для авторизации брокера, когда его можно проверить.
Дальнейшее ограничение доступа на основе идентификатора клиента
principals
Так как поле является логическим ИЛИ, вы можете дополнительно ограничить доступ на основе идентификатора клиента, добавив clientIds
поле в brokerResources
поле. Например, чтобы разрешить клиентам идентификаторы клиентов, которые начинаются со своего номера сборки для подключения и публикации телеметрии в разделах, в которых используется их сборка, используйте следующую конфигурацию:
В правилах авторизации брокера для политики авторизации используйте следующую конфигурацию:
[
{
"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"
}
]
}
}
]
Здесь, если clientIds
параметр не задан в методе Connect
, клиент с любым идентификатором клиента может подключиться до тех пор, пока он имеет building
атрибут building22
building23
или. clientIds
Добавив поле, только клиенты с идентификаторами клиентов, которые начинаются с building22
или building23
могут подключаться. Это гарантирует не только правильность атрибута клиента, но и соответствие идентификатора клиента ожидаемому шаблону.
Авторизация клиентов, использующих проверку подлинности X.509
Клиенты, использующие сертификаты X.509 для проверки подлинности , могут быть авторизованы для доступа к ресурсам на основе свойств X.509, присутствующих на их сертификате или их выдачи сертификатов вверх по цепочке.
Использование атрибутов
Чтобы создать правила на основе свойств сертификата клиента, его корневого ЦС или промежуточного ЦС, определите атрибуты X.509 в ресурсе BrokerAuthorization . Дополнительные сведения см. в разделе "Атрибуты сертификата".
С общим именем субъекта сертификата клиента в качестве имени пользователя
Чтобы создать политики авторизации на основе общего имени субъекта сертификата клиента (CN), создайте правила на основе CN.
Например, если у клиента есть сертификат с субъектом CN = smart-lock
, это имя пользователя smart-lock
. После этого создайте политики авторизации как обычные.
Авторизация клиентов, использующих маркеры учетной записи службы Kubernetes
Атрибуты авторизации для STS задаются как часть заметок учетной записи службы. Например, чтобы добавить атрибут авторизации с именем group
value 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 предоставляет хранилище состояний, которое клиенты могут использовать для хранения состояния. Хранилище состояний также можно настроить для высокой доступности.
Чтобы настроить авторизацию для клиентов, использующих хранилище состояний, укажите следующие разрешения:
- Разрешение на публикацию в разделе хранилища
$services/statestore/_any_/command/invoke/request
значений системного ключа - Разрешение на подписку на раздел ответа (задано во время первоначальной публикации в качестве параметра)
<response_topic>/#
Ключи хранилища состояний
Хранилище состояний осуществляется через брокер 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
Использование сопоставления шаблонов стиля globstring
для точного сопоставления, например, если ключ содержит символы, которые могут быть сопоставлены в противном случае как шаблон (*
, ,?
)[0-9]
binary
сопоставление двоичного ключа
Поле keys
указывает ключи, которые будут соответствовать. Ключи можно указать в виде шаблонов стилей GLOB , подстановок маркеров или точных строк.
- Примеры стилей 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}/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"
]
}
]
}
]
Обновление авторизации
Ресурсы авторизации брокера можно обновлять во время выполнения без перезапуска. Все клиенты, подключенные во время обновления политики, отключены. Изменение типа политики также поддерживается.
kubectl edit brokerauthorization my-authz-policies
Отключение авторизации
- В портал Azure перейдите к экземпляру Операций Интернета вещей.
- В разделе "Компоненты" выберите MQTT Broker.
- Выберите прослушиватель брокера, который вы хотите изменить из списка.
- На порте, который требуется отключить авторизацию, выберите "Нет " в раскрывающемся списке авторизации.
Несанкционированная публикация в MQTT 3.1.1
С MQTT 3.1.1, когда публикация запрещена, клиент получает PUBACK без ошибки, так как версия протокола не поддерживает возврат кода ошибки. MQTTv5 возвращает PUBACK с кодом причины 135 (не авторизовано) при отклонении публикации.