Руководство. Проверка подлинности клиента TLS, проверка подлинности клиента X.509 и авторизация на основе атрибутов (ABAC) с помощью брокера MQTT операций Интернета вещей Azure
В этом руководстве описано, как настроить брокер MQTT операций Интернета вещей Azure с шифрованием TLS и проверкой подлинности клиента X.509. Он включает пошаговые инструкции и скрипты для создания сертификатов для брокера и клиентов. В этом руководстве объясняется, как настроить брокер MQTT с различными корневыми центрами сертификации (ЦС) для клиента и брокера. Он также описывает настройку политики авторизации на основе атрибутов (ABAC) на основе цепочки сертификатов клиента. Наконец, в руководстве используется клиент Комаров для тестирования различных сценариев, чтобы убедиться, что программа установки работает правильно.
В этом руководстве имитируется среда, в которой операции Интернета вещей Azure устанавливаются в фабрике Contoso с устройствами, созданными Fabrikam. Чтобы сделать проверку подлинности TLS и X.509, выполните приведенные ниже действия.
- Брокер MQTT операций Интернета вещей Azure, установленный в фабрике Contoso, должен доверять корневому ЦС Fabrikam.
- Датчики Fabrikam, такие как термостаты, должны доверять корневому ЦС Contoso
- Каждая сущность должна иметь собственный конечный сертификат, выданный правильным корневым ЦС
Необходимые компоненты
Чтобы выполнить это руководство, требуется:
- Кластер Kubernetes с поддержкой перенаправления портов для порта 8883.
- Операции Интернета вещей Azure, развернутые без существующего прослушивателя подсистемы балансировки нагрузки.
- Доступ Kubectl к кластеру для создания секретов Kubernetes и карт конфигурации.
- Клиент Mosquitto для публикации и подписки на сообщения MQTT, выполняемые на том же компьютере, что и кластер Kubernetes для
localhost
доступа. Чтобы не использоватьlocalhost
, см . раздел "Необязательно". Используйте реальное имя узла или IP-адрес вместоlocalhost
раздела. - Шаг CLI для создания сертификатов.
Совет
Для удовлетворения этих требований используйте пространство кода быстрого запуска. Пространство кода быстрого запуска упрощает процесс установки, предоставляя эти компоненты из поля.
Кроме того, полезно ознакомиться с криптографией открытого ключа и терминами, такими как корневой ЦС, закрытый ключ и промежуточные сертификаты.
Необязательно. Используйте реальное имя узла или IP-адрес вместо localhost
Чтобы упростить этот учебник, мы используем localhost
для доступа к брокеру MQTT. Этот подход гарантирует, что сертификат сервера брокера имеет альтернативное имя субъекта (SAN), соответствующее имени узла, используемому для доступа к брокеру. Использование localhost
упрощения установки, так как san уже задано правильно.
В реальном сценарии вы будете использовать имя узла или внешний IP-адрес брокера вместо localhost
этого и подключитесь к нему с другого устройства в сети. В этом случае необходимо определить правильное имя узла или IP-адрес и использовать его в качестве SAN при создании сертификата сервера:
- Если имя узла или IP-адрес уже известны (например, через запись DNS или статический IP-адрес), используйте его в качестве SAN при создании сертификата сервера. Затем подключитесь к брокеру с помощью этого имени узла или IP-адреса
localhost
. - Если имя узла или IP-адрес еще не известно, можно использовать службу заполнителей для определения внешнего IP-адреса:
- Создайте службу LoadBalancer на порте, который не используется (например, 8080):
kubectl create service loadbalancer placeholder-service --tcp=8080:8080
- Получение внешнего IP-адреса:
kubectl get svc placeholder-service
- Если внешний IP-адрес:
- Показывает значение, например
192.168.X.X
, используйте этот IP-адрес в качестве SAN при создании сертификата сервера и секрета. Затем подключитесь к брокеру, используя этот IP-адрес, а неlocalhost
. - Показывает
<pending>
: используемое распределение Kubernetes может не поддерживать автоматическое назначение внешнего IP-адреса. Чтобы найти внешний IP-адрес, выполните действия, описанные в документации Kubernetes для вашей среды распространения и узла. Также может потребоваться настроить перенаправление портов или VPN в зависимости от настройки сети.
- Показывает значение, например
- После определения внешнего IP-адреса удалите службу заполнителей:
kubectl delete svc placeholder-service
- Создайте службу LoadBalancer на порте, который не используется (например, 8080):
Этот метод гарантирует, что сертификат сервера соответствует внешнему IP-адресу, что обеспечивает безопасный доступ к брокеру MQTT.
Подготовка сертификатов на стороне сервера и полная цепочка
Сначала создайте корневой ЦС на стороне сервера. Этот ЦС отделен от клиентского корневого ЦС, который создается позже. Чтобы обеспечить четкое разделение, мы назовем все серверные стороны Contoso. Чтобы упростить последующие действия, мы пропустим пароль для шифрования закрытого ключа. Эта практика допустима только в параметре учебника.
step certificate create "Contoso Root CA" \
contoso_root_ca.crt contoso_root_ca.key \
--profile root-ca \
--no-password --insecure
Затем создайте промежуточный ЦС, подписанный этим корневым ЦС.
step certificate create "Contoso Intermediate CA 1" \
contoso_intermediate_ca.crt contoso_intermediate_ca.key \
--profile intermediate-ca \
--ca ./contoso_root_ca.crt --ca-key ./contoso_root_ca.key \
--no-password --insecure
Наконец, используйте этот промежуточный ЦС для подписи сертификата сервера для внешнего интерфейса брокера MQTT брокера. localhost
Ниже приведено альтернативное имя субъекта (SAN), используемое для руководства.
step certificate create mqtts-endpoint \
mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--ca ./contoso_intermediate_ca.crt --ca-key ./contoso_intermediate_ca.key \
--bundle \
--san localhost \
--not-after 2400h --no-password --insecure
С флагом --bundle
сертификат сервера упаковается с промежуточным сертификатом подписи. Для подтверждения TLS требуется пакет для проверки полной цепочки.
Подготовка клиентских сертификатов и полная цепочка
Аналогичным образом создайте корневой ЦС для Fabrikam и промежуточного ЦС.
step certificate create --profile root-ca "Fabrikam Root CA" \
fabrikam_root_ca.crt fabrikam_root_ca.key \
--no-password --insecure
step certificate create "Fabrikam Intermediate CA 1" \
fabrikam_intermediate_ca.crt fabrikam_intermediate_ca.key \
--profile intermediate-ca \
--ca ./fabrikam_root_ca.crt --ca-key ./fabrikam_root_ca.key \
--no-password --insecure
Затем создайте сертификаты клиента для термостата, гигрометра, нагревателя и лампочки.
# Create a client certificate for the thermostat
step certificate create thermostat thermostat.crt thermostat.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure
# Create a client certificate for the hygrometer
step certificate create hygrometer hygrometer.crt hygrometer.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure
# Create a client certificate for the heater
step certificate create heater heater.crt heater.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure
# Create a client certificate for the lightbulb
step certificate create lightbulb lightbulb.crt lightbulb.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure
Настройка Kubernetes
Импортируйте только что созданный сертификат сервера и закрытый ключ в секрет Kubernetes. Этот секрет используется для настройки прослушивателя TLS для брокера MQTT позже.
kubectl create secret tls broker-server-cert -n azure-iot-operations \
--cert mqtts-endpoint.crt \
--key mqtts-endpoint.key
Кроме того, создайте карту конфигурации для хранения корневого ЦС Fabrikam (на стороне клиента). Эта карта конфигурации необходима для брокера MQTT, чтобы доверять ему для проверки подлинности X.509.
kubectl create configmap fabrikam-ca -n azure-iot-operations \
--from-file=client_ca.pem=fabrikam_root_ca.crt
Настройка брокера MQTT
Дальнейшие действия по настройке брокера MQTT с шифрованием TLS и проверкой подлинности клиента X.509. В этом руководстве используется портал Azure для настройки брокера MQTT.
Проверка подлинности
Чтобы разрешить клиентам проходить проверку подлинности с помощью сертификатов X.509, выданных корневым ЦС Fabrikam, создайте политику проверки подлинности, которая доверяет сертификату корневого ЦС Fabrikam и сопоставляет сертификаты клиента с атрибутами авторизации для ABAC.
В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.
Выберите вкладку Аутентификация.
Выберите " Создать политику проверки подлинности".
Введите
x509-auth
имя политики.Добавьте новый метод, нажав кнопку "Добавить".
Выберите тип метода X.509 из раскрывающегося списка, а затем выберите "Добавить сведения ", чтобы настроить метод.
В области сведений о проверке подлинности X.509 укажите имя
fabrikam-ca
доверенного сертификата ЦС Fabrikam и атрибуты.{ "trustedClientCaCert": "fabrikam-ca", "authorizationAttributes": { "thermostat": { "subject": "CN = thermostat", "attributes": { "group": "thermostat_group" } }, "hygrometer": { "subject": "CN = hygrometer", "attributes": { "group": "hygrometer_group" } }, "intermediate": { "subject": "CN = Fabrikam Intermediate CA 1", "attributes": { "manufacturer": "fabrikam" } } } }
Нажмите кнопку "Применить", чтобы сохранить изменения.
Средство прослушивания
Используя политику проверки подлинности, создайте прослушиватель, использующий политику проверки подлинности X.509. Кроме того, так как для проверки подлинности X.509 требуется TLS, настройте прослушиватель для использования сертификата сервера Contoso и закрытого ключа, созданного ранее.
В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.
Выберите прослушиватель брокера MQTT для LoadBalancer>Create. Введите следующие параметры:
Параметр Description Имя. Введите mqtts-endpoint
.Service name Имя службы Kubernetes. Оставьте пустым имя прослушивателя mqtts-endpoint
в качестве имени службы.тип услуги; LoadBalancer уже выбран. В разделе "Порты" введите следующие параметры для первого порта:
Параметр Description Порт Введите 8883 Проверка подлинности Выбор x509-auth Авторизация Выберите Нет. Протокол Выбор MQTT TLS Выберите Добавить В области конфигурации TLS введите следующие параметры:
Параметр Description Режим TLS Выбор вручную имя издателя; Введите broker-server-cert
Выберите "Применить " и "Создать прослушиватель".
Через минуту или два mqtts-endpoint
служба LoadBalancer создается.
$ kubectl get service mqtts-endpoint -n azure-iot-operations
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mqtts-endpoint LoadBalancer 10.43.28.140 XXX.XX.X.X 8883:30988/TCP 104s
Вместо использования внешнего IP-адреса мы используем localhost
для руководства.
Совет
Конфигурация пространства кода автоматически настраивает перенаправление портов для 8883. Сведения о настройке других сред см. в разделе "Использование перенаправления портов".
Использование одного клиента комаров для публикации сообщений по протоколу TLS
Из той же папки, что и файлы сертификатов: contoso_root_ca.crt
и thermostat.key
thermostat.crt
используйте клиент Комаров для публикации сообщения. Флаг --cafile contoso_root_ca.crt
предназначен для комаров для проверки сертификата сервера.
mosquitto_pub -t "example/topic" -m "example temperature measurement" -i thermostat \
-q 1 -V mqttv5 -d \
-h localhost \
--key thermostat.key \
--cert thermostat.crt \
--cafile contoso_root_ca.crt
Публикация завершается успешно, так как комар использует сертификат клиента, корневой в fabrikam_root_ca.crt
который входит. Брокер MQTT доверяет этому сертификату x509-auth
, так как политика проверки подлинности, созданная ранее. Кроме того, брокер MQTT в настоящее время позволяет клиентам, прошедшим проверку подлинности, публиковать в любом разделе.
Client thermostat sending CONNECT
Client thermostat received CONNACK (0)
Client thermostat sending PUBLISH (d0, q1, r0, m1, 'example/topic', ... (31 bytes))
Client thermostat received PUBACK (Mid: 1, RC:0)
Client thermostat sending DISCONNECT
Настройка авторизации в разделах MQTT для нескольких клиентов с помощью X.509
Чтобы ограничить доступ к разделам MQTT на основе атрибутов сертификата клиента, создайте политику авторизации, которая сопоставляет атрибуты сертификата клиента с разрешенными действиями в определенных разделах.
В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.
Перейдите на вкладку Authorization (Авторизация).
Выберите " Создать политику авторизации".
Введите
abac-authz
имя политики.В разделе "Правила" введите следующие правила:
[ { "principals": { "attributes": [ { "group": "thermostat_group" } ] }, "brokerResources": [ { "method": "Connect" }, { "method": "Publish", "topics": [ "telemetry/temperature" ] } ] }, { "principals": { "attributes": [ { "group": "hygrometer_group" } ] }, "brokerResources": [ { "method": "Connect" }, { "method": "Publish", "topics": [ "telemetry/humidity" ] } ] }, { "principals": { "attributes": [ { "manufacturer": "fabrikam" } ] }, "brokerResources": [ { "method": "Connect" }, { "method": "Publish", "topics": [ "health/heartbeat" ] } ] }, { "principals": { "usernames": [ "heater" ] }, "brokerResources": [ { "method": "Connect" }, { "method": "Subscribe", "topics": [ "telemetry/temperature", "telemetry/humidity" ] } ] } ]
Выберите Добавить, чтобы сохранить изменения.
Затем обновите прослушиватель брокера MQTT, чтобы использовать новую политику авторизации.
- Перейдите на вкладку "Прослушиватели ".
- Выберите прослушиватель mqtts-endpoint.
- В разделе "Порты>8883>Авторизация" выберите abac-authz.
- Выберите Сохранить.
Публикация сообщений в ограниченном разделе
В этом разделе мы тестируем только что примененные политики авторизации.
Во-первых, подключитесь к thermostat
разделу telemetry/humidity
и попробуйте опубликовать его:
mosquitto_pub -t "telemetry/humidity" -m "example temperature measurement" -i thermostat \
-q 1 -V mqttv5 -d \
-h localhost \
--key thermostat.key \
--cert thermostat.crt \
--cafile contoso_root_ca.crt
Так как thermostat
является частью thermostat_group
, которая не допускает публикации в теме влажности, публикация завершается сбоем.
Client thermostat sending CONNECT
Client thermostat received CONNACK (0)
Client thermostat sending PUBLISH (d0, q1, r0, m1, 'telemetry/humidity', ... (6 bytes))
Client thermostat received PUBACK (Mid: 1, RC:135)
Warning: Publish 1 failed: Not authorized.
Перейдите на публикацию, в которой разрешено и telemetry/temperature
публикация успешно выполнена. Оставьте команду запущенной.
mosquitto_pub -t "telemetry/temperature" -m "example temperature measurement" -i thermostat \
-q 1 -V mqttv5 -d \
-h localhost \
--repeat 10000 \
--repeat-delay 3 \
--key thermostat.key \
--cert thermostat.crt \
--cafile contoso_root_ca.crt
Подписка на сообщения в ограниченных разделах
В отдельном сеансе терминала подключитесь к heater
подписке health/heartbeat
.
mosquitto_sub -q 1 -t "health/heartbeat" -d -V mqttv5 \
-i heater \
-h localhost \
--key heater.key \
--cert heater.crt \
--cafile contoso_root_ca.crt
Так как heater
подписка на раздел пульса не разрешена, подписка завершается ошибкой. Здесь код 135 означает , что он не авторизован.
Client heater sending CONNECT
Client heater received CONNACK (0)
Client heater sending SUBSCRIBE (Mid: 1, Topic: health/heartbeat, QoS: 1, Options: 0x00)
Client heater received SUBACK
Subscribed (mid: 1): 135
Переключите раздел telemetry/temperature
подписки на , в который thermostat
по-прежнему отправляются сообщения.
mosquitto_sub -q 1 -t "telemetry/temperature" -d -V mqttv5 \
-i heater \
-h localhost \
--key heater.key \
--cert heater.crt \
--cafile contoso_root_ca.crt
Теперь heater
начинает получать сообщения, так как оно авторизовано с его именем пользователя.
В другом отдельном сеансе терминала опубликуйте сообщения health/heartbeat
с помощью lightbulb
:
mosquitto_pub -q 1 -t "health/heartbeat" -m "example heartbeat" -d -V mqttv5 \
-i lightbulb \
-h localhost \
--repeat 100 \
--repeat-delay 3 \
--key lightbulb.key \
--cert lightbulb.crt \
--cafile contoso_root_ca.crt
Публикация завершается успешно, так как lightbulb
имеет промежуточный сертификат с атрибутом, сопоставленным с CN = Fabrikam Intermediate CA 1
атрибутом manufacturer=fabrikam
. Клиенты с этим атрибутом могут публиковаться в health/heartbeat
. Когда клиент начинает отправлять сообщения, запущенные ранее, heater
не получают ничего.
Очистка ресурсов
Чтобы очистить ресурсы, созданные в этом руководстве, удалите прослушиватель и политики проверки подлинности и авторизации.
- В портал Azure перейдите к экземпляру Операций Интернета вещей.
- В разделе "Компоненты" выберите MQTT Broker.
- Перейдите на вкладку "Прослушиватели ".
- Установите флажок рядом с прослушивателем mqtts-endpoint .
- Выберите Удалить.
- Подтвердите удаление.
- Выберите вкладку Аутентификация.
- Установите флажок рядом с x509-auth.
- Выберите Удалить.
- Подтвердите удаление.
- Перейдите на вкладку Authorization (Авторизация).
- Установите флажок рядом с abac-authz.
- Выберите Удалить.
- Подтвердите удаление.
Кроме того, удалите секрет Kubernetes и карту конфигурации.
kubectl delete secret broker-server-cert -n azure-iot-operations
kubectl delete configmap fabrikam-ca -n azure-iot-operations
Наконец, удалите сертификаты и ключи, созданные ранее.
rm contoso_root_ca.crt contoso_root_ca.key contoso_intermediate_ca.crt contoso_intermediate_ca.key mqtts-endpoint.crt mqtts-endpoint.key
rm fabrikam_root_ca.crt fabrikam_root_ca.key fabrikam_intermediate_ca.crt fabrikam_intermediate_ca.key thermostat.crt thermostat.key hygrometer.crt hygrometer.key heater.crt heater.key lightbulb.crt lightbulb.key