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


Руководство. Проверка подлинности клиента 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-адреса:
    1. Создайте службу LoadBalancer на порте, который не используется (например, 8080):
      kubectl create service loadbalancer placeholder-service --tcp=8080:8080
      
    2. Получение внешнего IP-адреса:
      kubectl get svc placeholder-service
      
    3. Если внешний IP-адрес:
      • Показывает значение, например 192.168.X.X , используйте этот IP-адрес в качестве SAN при создании сертификата сервера и секрета. Затем подключитесь к брокеру, используя этот IP-адрес, а не localhost.
      • Показывает <pending> : используемое распределение Kubernetes может не поддерживать автоматическое назначение внешнего IP-адреса. Чтобы найти внешний IP-адрес, выполните действия, описанные в документации Kubernetes для вашей среды распространения и узла. Также может потребоваться настроить перенаправление портов или VPN в зависимости от настройки сети.
    4. После определения внешнего IP-адреса удалите службу заполнителей:
      kubectl delete svc placeholder-service
      

Этот метод гарантирует, что сертификат сервера соответствует внешнему 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.

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

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

  3. Выберите вкладку Аутентификация.

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

  5. Введите x509-authимя политики.

  6. Добавьте новый метод, нажав кнопку "Добавить".

  7. Выберите тип метода X.509 из раскрывающегося списка, а затем выберите "Добавить сведения ", чтобы настроить метод.

  8. В области сведений о проверке подлинности 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"
          }
        }
      }
    }
    
  9. Нажмите кнопку "Применить", чтобы сохранить изменения.

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

Средство прослушивания

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

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

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

  3. Выберите прослушиватель брокера MQTT для LoadBalancer>Create. Введите следующие параметры:

    Параметр Description
    Имя. Введите mqtts-endpoint.
    Service name Имя службы Kubernetes. Оставьте пустым имя прослушивателя mqtts-endpoint в качестве имени службы.
    тип услуги; LoadBalancer уже выбран.
  4. В разделе "Порты" введите следующие параметры для первого порта:

    Параметр Description
    Порт Введите 8883
    Проверка подлинности Выбор x509-auth
    Авторизация Выберите Нет.
    Протокол Выбор MQTT
    TLS Выберите Добавить
  5. В области конфигурации TLS введите следующие параметры:

    Параметр Description
    Режим TLS Выбор вручную
    имя издателя; Введите broker-server-cert
  6. Выберите "Применить " и "Создать прослушиватель".

Снимок экрана: метод портал Azure для задания прослушивателя с помощью порта TLS.

Через минуту или два 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.keythermostat.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 на основе атрибутов сертификата клиента, создайте политику авторизации, которая сопоставляет атрибуты сертификата клиента с разрешенными действиями в определенных разделах.

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

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

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

  4. Выберите " Создать политику авторизации".

  5. Введите abac-authzимя политики.

  6. В разделе "Правила" введите следующие правила:

    [
      {
        "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"
            ]
          }
        ]
      }
    ]
    
  7. Выберите Добавить, чтобы сохранить изменения.

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

Затем обновите прослушиватель брокера MQTT, чтобы использовать новую политику авторизации.

  1. Перейдите на вкладку "Прослушиватели ".
  2. Выберите прослушиватель mqtts-endpoint.
  3. В разделе "Порты>8883>Авторизация" выберите abac-authz.
  4. Выберите Сохранить.

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

Публикация сообщений в ограниченном разделе

В этом разделе мы тестируем только что примененные политики авторизации.

Во-первых, подключитесь к 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 не получают ничего.

Очистка ресурсов

Чтобы очистить ресурсы, созданные в этом руководстве, удалите прослушиватель и политики проверки подлинности и авторизации.

  1. В портал Azure перейдите к экземпляру Операций Интернета вещей.
  2. В разделе "Компоненты" выберите MQTT Broker.
  3. Перейдите на вкладку "Прослушиватели ".
  4. Установите флажок рядом с прослушивателем mqtts-endpoint .
  5. Выберите Удалить.
  6. Подтвердите удаление.
  7. Выберите вкладку Аутентификация.
  8. Установите флажок рядом с x509-auth.
  9. Выберите Удалить.
  10. Подтвердите удаление.
  11. Перейдите на вкладку Authorization (Авторизация).
  12. Установите флажок рядом с abac-authz.
  13. Выберите Удалить.
  14. Подтвердите удаление.

Кроме того, удалите секрет 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