Защита обмена данными брокера MQTT с помощью BrokerListener

Статья
11/20/2024

Внимание

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

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

BrokerListener соответствует сетевой конечной точке, которая предоставляет брокер клиентам через сеть. Для каждого брокера можно использовать один или несколько ресурсов BrokerListener с несколькими портами и разными средствами управления доступом.

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

Совет

Развертывание брокера MQTT по умолчанию — это IP-служба кластера, которая требует от клиентов подключаться к TLS и проходить проверку подлинности с помощью маркеров учетной записи службы. Клиенты, подключающиеся извне кластера , нуждаются в дополнительной конфигурации , прежде чем они смогут подключиться.

Прослушиватели брокера имеют следующие характеристики:

Имя: имя прослушивателя. Это имя также является именем службы Kubernetes, если не переопределено.
Тип службы: у вас может быть до трех прослушивателей, по одному на тип службы. Прослушиватель по умолчанию — тип ClusterIpслужбы.
Порты: каждый прослушиватель поддерживает несколько портов. Порты не могут конфликтуть с разными прослушивателями.
Ссылки на проверку подлинности и авторизацию: brokerAuthentication и BrokerAuthorization настроены на порт.
TLS: на порт применяется ручная или автоматическая конфигурация TLS.
Протокол: MQTT через WebSockets можно включить на один порт.

Список всех доступных параметров см . в справочнике по API прослушивателя брокера.

BrokerListener по умолчанию

При развертывании операций Интернета вещей Azure развертывание создает ресурс BrokerListener с именем default. Этот прослушиватель используется для зашифрованного внутреннего взаимодействия между компонентами Операций Интернета вещей Azure. Прослушиватель по умолчанию является частью брокера по умолчанию.

Она предоставляет службу ClusterIp через порт 18883
Для этого требуется, чтобы клиенты использовали проверку подлинности учетной записи службы Kubernetes
Он имеет автоматически управляемый сертификат TLS
Он не настраивает политики авторизации клиента

Внимание

Чтобы избежать нарушения внутренних операций Интернета вещей Azure, не изменяйте прослушиватель по умолчанию и выделенный для внутреннего использования. Для внешнего взаимодействия создайте прослушиватель. Если необходимо использовать службу ClusterIp, добавьте дополнительные порты в прослушиватель по умолчанию, не изменяя существующие параметры.

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

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

Будьте осторожны при изменении прослушивателя по умолчанию с помощью Bicep. Не изменяйте существующие параметры. Вместо этого добавьте дополнительные порты в прослушиватель по умолчанию. В следующем примере показано, как добавить новый порт в прослушиватель по умолчанию.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    // Don't change the service name or service type
    serviceType: 'ClusterIp'
    serviceName: 'aio-broker'
    ports: [
      // Don't modify the default port 18883 settings
      {
        port: 18883
        authenticationRef: 'default'
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
            privateKey: {
              algorithm: 'Ec256'
              rotationPolicy: 'Always'
            }
          }
        }
      }
      // Add more ports here, like the following example
      {
        port: 1884
        protocol: 'Mqtt'
      }
    ]
  }
}

Разверните Bicep-файл с помощью Azure CLI.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Чтобы просмотреть ресурс BrokerListener по умолчанию, используйте следующую команду:

kubectl get brokerlistener default -n azure-iot-operations -o yaml

Выходные данные должны выглядеть примерно так, при этом большинство метаданных удалены для краткости:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: default
  namespace: azure-iot-operations
  ownerReferences:
  - apiVersion: mqttbroker.iotoperations.azure.com/v1
    kind: Broker
    name: default
spec:
  serviceType: ClusterIp
  serviceName: aio-broker
  ports:
  - port: 18883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: azure-iot-operations-aio-certificate-issuer
          kind: ClusterIssuer
          group: cert-manager.io
        privateKey:
          algorithm: Ec256
          rotationPolicy: Always

Чтобы добавить новый порт 1883 без TLS и проверки подлинности в прослушиватель по умолчанию, используйте kubectl patch команду:

kubectl patch brokerlistener default -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/-", "value": {"port": 1883, "protocol": "Mqtt"}}]'

Избегайте изменения прослушивателя брокера по умолчанию

Чтобы предотвратить нарушение внутренних операций Интернета вещей Azure, сохраните прослушиватель по умолчанию без изменений и выделен для внутреннего использования. Для внешнего взаимодействия создайте прослушиватель.

Так как прослушиватель брокера по умолчанию использует тип службы ClusterIp, и вы можете иметь только один прослушиватель для каждого типа службы, добавить дополнительные порты в прослушиватель по умолчанию, не изменяя существующие параметры, если необходимо использовать службу ClusterIp.

Создание прослушивателей брокера

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

Имя: имя прослушивателя. Это имя также является именем службы Kubernetes, если не переопределено.
Тип службы: тип службы Kubernetes. См . раздел "Тип службы".
Порты: список портов, которые необходимо прослушивать. См. порты.
(Необязательно) Имя службы: переопределите имя службы Kubernetes. См . имя службы.

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

В этом примере показано, как создать прослушиватель с типом службы подсистемы балансировки нагрузки. Ресурс BrokerListener определяет два порта, которые принимают подключения MQTT от клиентов.

Первый порт прослушивает порт 1883 без tls и проверки подлинности. Эта настройка подходит только для тестирования. Не используйте эту конфигурацию в рабочей среде.
Второй порт прослушивает порт 8883 с включенным протоколом TLS и проверкой подлинности. Подключиться могут только клиенты, прошедшие проверку подлинности с маркером учетной записи службы Kubernetes. Протокол TLS устанавливается в автоматический режим, используя cert-manager для управления сертификатом сервера из издателя по умолчанию. Эта настройка ближе к рабочей конфигурации.

В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.

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

Введите следующие параметры:

Параметр	Description
Имя.	Имя ресурса BrokerListener.
Service name	Имя службы Kubernetes. Оставьте пустым имя прослушивателя в качестве имени службы.
тип услуги;	LoadBalancer уже выбран.

В разделе "Порты" введите следующие параметры для первого порта:

Параметр	Description
Порт	Ввод 1883
Проверка подлинности	Выберите Нет.
Авторизация	Выберите Нет.
Протокол	Выбор MQTT
TLS	Не добавляйте

Выберите " Добавить запись порта", чтобы добавить второй порт и введите следующие параметры:

Параметр	Description
Порт	Введите 8883
Проверка подлинности	Выбор по умолчанию
Авторизация	Выберите Нет.
Протокол	Выбор MQTT
TLS	Выберите Добавить

В области конфигурации TLS введите следующие параметры:

Параметр	Description
Режим TLS	Выберите "Автоматически"
имя издателя;	Введите `azure-iot-operations-aio-certificate-issuer`
Тип издателя	Выбор ClusterIssuer

Оставьте другие параметры по умолчанию и нажмите кнопку "Применить".

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

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = '<LISTENER_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        port: 1883
        protocol: 'Mqtt'
      }
      {
        authenticationRef: 'default'
        port: 8883
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
          }
        }
      }
    ]
  }
}

Разверните Bicep-файл с помощью Azure CLI.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: <LISTENER_NAME>
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: LoadBalancer
  ports:
  - port: 1883
    protocol: Mqtt
  - port: 8883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
            name: azure-iot-operations-aio-certificate-issuer
            kind: ClusterIssuer
            group: cert-manager.io

тип услуги;

Каждая служба BrokerListener сопоставляется со службой Kubernetes. Тип службы определяет, как брокер предоставляется сети. Поддерживаемые типы служб:

ClusterIp: предоставляет брокер на внутреннем IP-адресе кластера. Клиенты могут подключаться к брокеру из кластера. Это тип службы по умолчанию для прослушивателя по умолчанию.
NodePort: предоставляет брокер на IP-адрес каждого узла в статическом порту. Клиенты могут подключаться к брокеру за пределами кластера. Этот тип службы полезен для разработки и тестирования.
LoadBalancer: предоставляет брокер внешним образом. Служба назначает внешний IP-адрес, который клиенты могут использовать для подключения к брокеру. Это наиболее распространенный тип службы для рабочих развертываний.

Только один прослушиватель на тип службы

Допускается только один прослушиватель для каждого типа службы. Если требуется больше подключения одного типа службы, добавьте дополнительные порты в существующий прослушиватель этого типа службы.

Service name

Имя службы — это имя службы Kubernetes, связанной с брокером. Если это не указано, имя прослушивателя брокера используется в качестве имени службы. Имя службы должно быть уникальным в пространстве имен.

Совет

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

Порты

Каждый прослушиватель может иметь несколько портов, и каждый порт может иметь собственные параметры для проверки подлинности, авторизации, протокола и TLS.

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

Сведения об использовании TLS см. в разделе "Настройка TLS с автоматическим управлением сертификатами " или "Настройка TLS" с разделами управления сертификатами вручную.

Использование одного порта для прослушивателей

Использование одного и того же номера порта для разных прослушивателей не поддерживается. Каждый номер порта должен быть уникальным в брокере MQTT операций Интернета вещей Azure.

Например, если у вас есть прослушиватель с помощью порта 1883, вы не можете создать другой прослушиватель с портом 1883. Аналогичным образом прослушиватель по умолчанию использует порт 18883, поэтому вы не можете создать другой прослушиватель с портом 18883.

Поддержка WebSocket

Брокер MQTT операций Интернета вещей Azure поддерживает MQTT через WebSockets. Чтобы включить WebSockets, задайте для порта протокол WebSockets .

Настройка TLS с помощью автоматического управления сертификатами

Чтобы включить TLS с автоматическим управлением сертификатами, укажите параметры TLS в порту прослушивателя.

Проверка установки cert-manager

При автоматическом управлении сертификатами используется диспетчер сертификатов для управления сертификатом сервера TLS. По умолчанию диспетчер сертификатов устанавливается вместе с операциями Интернета вещей Azure в cert-manager пространстве имен. Перед продолжением проверьте установку.

Используется kubectl для проверки соответствия модулей pod, соответствующих меткам приложений cert-manager.

kubectl get pods --namespace cert-manager -l 'app in (cert-manager,cainjector,webhook)'

NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

Если вы видите модули pod, которые отображаются как готовые и запущенные, диспетчер сертификатов устанавливается и готов к использованию.

Совет

Чтобы дополнительно проверить установку, проверьте установку документации по cert-manager. Не забудьте использовать cert-manager пространство имен.

Создание издателя для сертификата сервера TLS

Ресурс издателя cert-manager определяет способ автоматического выдачи сертификатов. Cert-manager поддерживает несколько типов издателей в собственном коде. Он также поддерживает внешний тип издателя для расширения функциональных возможностей за пределами собственных поддерживаемых издателей. Брокер MQTT можно использовать с любым типом издателя cert-manager.

Внимание

Во время первоначального развертывания операции Интернета вещей Azure устанавливаются с издателем по умолчанию для сертификатов сервера TLS. Этот издатель можно использовать для разработки и тестирования. Дополнительные сведения см. в разделе "Корневой ЦС по умолчанию" и издателя с помощью операций Интернета вещей Azure. Приведенные ниже действия требуются только в том случае, если вы хотите использовать другого издателя.

Подход к созданию издателя отличается в зависимости от вашего сценария. В следующих разделах приведены примеры, которые помогут вам приступить к работе.

Разработка или тестирование
Рабочая среда

Издатель ЦС полезен для разработки и тестирования. Его необходимо настроить с помощью сертификата и закрытого ключа, хранящегося в секрете Kubernetes.

Настройка корневого сертификата в качестве секрета Kubernetes

Если у вас есть сертификат ЦС, создайте секрет Kubernetes с сертификатом ЦС и файлами PEM закрытого ключа ЦС. Выполните следующую команду, чтобы импортировать сертификат ЦС в качестве секрета Kubernetes и пропустить следующий раздел.

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

Если у вас нет сертификата ЦС, диспетчер сертификатов может создать сертификат ЦС. Использование диспетчера сертификатов для создания сертификата ЦС называется начальной загрузкой издателя ЦС с самозаверяющими сертификатами.

Начните с создания ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

Создайте самозаверяющий сертификат ЦС с помощью следующей команды:
```
kubectl apply -f ca.yaml
```

Cert-manager создает сертификат ЦС с помощью значений по умолчанию. Свойства этого сертификата можно изменить, изменив спецификацию сертификата. Список допустимых параметров см . в документации по диспетчеру сертификатов.

Распространение корневого сертификата

В предыдущем примере сертификат ЦС хранится в секрете test-caKubernetes. Сертификат в формате PEM можно получить из секрета и сохранить в файле ca.crt с помощью следующей команды:

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

Этот сертификат должен распространяться и доверять всем клиентам. Например, используйте --cafile флаг для клиента mosquitto.

Создание издателя на основе сертификата ЦС

Диспетчер сертификатов требует издателя на основе сертификата ЦС, созданного или импортированного на предыдущем шаге. Создайте следующий файл следующим образом issuer-ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
  namespace: azure-iot-operations
spec:
  ca:
    # Must match secretName of generated or imported CA cert
    secretName: test-ca

Создайте издателя с помощью следующей команды:

kubectl apply -f issuer-ca.yaml

Следующая команда создает издателя для выдачи сертификатов сервера TLS. Запишите имя и тип издателя. В примере это имя my-issuer и тип Issuer. Эти значения задаются в ресурсе BrokerListener позже.

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

Разверните HashiCorp Vault в выбранной среде, например Kubernetes. Инициализировать и отменить хранилище соответствующим образом.
Создайте и настройте подсистему секретов PKI, импортируя сертификат ЦС.
Настройте Хранилище с ролью и политикой для выдачи сертификатов сервера.

Ниже приведен пример роли. Обратите внимание ExtKeyUsageServerAuth , что сертификат сервера работает:
```
vault write pki/roles/my-issuer \
  allow_any_name=true \
  client_flag=false \
  ext_key_usage=ExtKeyUsageServerAuth \
  no_store=true \
  max_ttl=240h
```
Пример политики для роли:
```
path "pki/sign/my-issuer" {
  capabilities = ["create", "update"]
}
```
Настройте проверку подлинности между диспетчером сертификатов и хранилищем с помощью выбранного метода, например SAT.
Настройте издателя хранилища cert-manager.

Включение автоматического управления сертификатами TLS для порта

Ниже приведен пример ресурса BrokerListener, который включает TLS через порт 8884 с автоматическим управлением сертификатами.

В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.
Выберите или создайте прослушиватель. Вы можете создать только один прослушиватель для каждого типа службы. Если у вас уже есть прослушиватель одного типа службы, можно добавить дополнительные порты в существующий прослушиватель.

Параметры TLS можно добавить в прослушиватель, выбрав TLS на существующем порту или добавив новый порт.

Введите следующие параметры:

Параметр	Description
Имя.	Имя ресурса BrokerListener. Введите `aio-broker-loadbalancer-tls`.
Порт	Номер порта, на котором брокерListener прослушивает подключения MQTT. Введите 8884.
Проверка подлинности	Ссылка на ресурс проверки подлинности.
Авторизация	Справочник по ресурсу авторизации.
TLS	Нажмите кнопку Добавить.
имя издателя;	Имя издателя cert-manager. Обязательный.
Тип издателя	Тип издателя cert-manager. Обязательный.
Группа издателей	Группа издателя cert-manager. Обязательный.
Алгоритм закрытого ключа	Алгоритм закрытого ключа.
Политика смены закрытого ключа	Политика поворота закрытого ключа.
DNS-имена	Альтернативные имена субъектов DNS для сертификата.
IP-адреса	IP-адреса альтернативного имени субъекта для сертификата.
Имя секрета	Секрет Kubernetes, содержащий сертификат клиента X.509.
Duration	Общее время существования сертификата сервера TLS по умолчанию составляет 90 дней.
Продление до	Когда начнется продление сертификата.

Нажмите кнопку "Применить" , чтобы сохранить параметры TLS.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-loadbalancer-tls'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8884
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'my-issuer'
              kind: 'Issuer'
            }
          }
        }
      }
    ]
  }
}

Разверните Bicep-файл с помощью Azure CLI.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Измените tls параметр в ресурсе BrokerListener, чтобы указать порт TLS и издателя для интерфейсных интерфейсов.

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-loadbalancer-tls # Avoid conflicts with default service name 'aio-broker'
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer
  ports:
  - port: 8884 # Avoid conflicts with default port 18883
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: my-issuer
          kind: Issuer

После настройки ресурса BrokerListener брокер MQTT автоматически создает новую службу с указанным портом и протоколом TLS.

Необязательно. Настройка параметров сертификата сервера

Единственными обязательными параметрами являются имя издателя и тип издателя. Все остальные свойства созданных сертификатов сервера TLS автоматически выбираются. Однако брокер MQTT позволяет настраивать определенные свойства после того же синтаксиса, что и сертификаты cert-manager. Например, можно указать алгоритм закрытого ключа и политику поворота. Эти параметры находятся tls.certManagerCertificateSpec в области конфигурации TLS в портал Azure.

Полный список этих параметров см . в справочнике по API Прослушивателя Брокера CertManagerCertificateSpec.

Проверка развертывания

Используйте kubectl, чтобы проверить, запущена ли служба, связанная с ресурсом BrokerListener. В приведенном выше примере имя службы — aio-broker-loadbalancer-tls это пространство azure-iot-operationsимен. Следующая команда проверяет состояние службы:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
aio-broker-loadbalancer-tls    LoadBalancer   10.X.X.X        172.X.X.X     8884:32457/TCP   33s

Подключение к брокеру с помощью TLS

После настройки сертификата сервера протокол TLS включен. Чтобы проверить с помощью mosquitto:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

Аргумент --cafile включает TLS в клиенте mosquitto и указывает, что клиент должен доверять всем сертификатам сервера, выданным заданным файлом. Необходимо указать файл, содержащий издателя настроенного сертификата СЕРВЕРА TLS.

Замените $HOST соответствующим узлом:

При подключении из одного кластера замените имя службы (my-new-tls-listener например) или службу CLUSTER-IP.
При подключении извне кластера служба EXTERNAL-IP.

При необходимости не забудьте указать методы проверки подлинности.

Корневой ЦС по умолчанию и издатель по умолчанию

Чтобы приступить к работе, операции Интернета вещей Azure развертываются с сертификатом ЦС по умолчанию и издателем сертификатов сервера TLS. Этот издатель можно использовать для разработки и тестирования. Дополнительные сведения см. в разделе "Корневой ЦС по умолчанию" и издателя сертификатов сервера TLS.

Для рабочей среды необходимо настроить издателя ЦС с сертификатом из доверенного ЦС, как описано в предыдущих разделах.

Настройка TLS с помощью ручного управления сертификатами

Чтобы вручную настроить брокер MQTT для использования определенного сертификата TLS, укажите его в ресурсе BrokerListener со ссылкой на секрет Kubernetes и разверните его с помощью kubectl. В этой статье показан пример настройки TLS с самозаверяющими сертификатами для тестирования.

Создание центра сертификации с помощью step CLI

Шаг — это диспетчер сертификатов, который может быстро приступить к работе и работе при создании собственного частного ЦС и управлении ими.

Установите интерфейс командной строки и создайте сертификат и ключ корневого центра сертификации.
```
step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key
```

Создайте промежуточный сертификат ЦС и ключ, подписанный корневым ЦС.

step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

Создание сертификата сервера

Используйте интерфейс командной строки шага для создания сертификата сервера из подписанного промежуточного ЦС.

step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure

mqtts-endpoint Здесь и localhost представлены альтернативные имена субъектов (SAN) для внешнего интерфейса брокера MQTT в Kubernetes и локальных клиентах соответственно. Чтобы подключиться через Интернет, добавьте --san внешний IP-адрес. Флаги --no-password --insecure используются для тестирования, чтобы пропустить запросы паролей и отключить защиту паролей для закрытого ключа, так как он хранится в секрете Kubernetes. Для рабочей среды используйте пароль и сохраните закрытый ключ в безопасном расположении, например Azure Key Vault.

Требования к алгоритму ключа сертификата

Поддерживаются ключи EC и RSA, но все сертификаты в цепочке должны использовать один и тот же алгоритм ключа. При импорте собственных сертификатов ЦС убедитесь, что сертификат сервера использует тот же алгоритм ключей, что и ЦС.

Импорт цепочки сертификатов сервера в виде секрета Kubernetes

Создайте полную цепочку сертификатов сервера, где порядок сертификатов имеет значение: сертификат сервера является первым в файле, промежуточным является второй.
```
cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt
```
Создайте секрет Kubernetes с цепочкой сертификатов сервера и ключом сервера с помощью kubectl.
```
kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key
```

Включение управления сертификатами TLS вручную для порта

Ниже приведен пример ресурса BrokerListener, который включает TLS через порт 8884 с помощью ручного управления сертификатами.

В портал Azure перейдите к экземпляру Операций Интернета вещей.
В разделе "Компоненты" выберите MQTT Broker.
Выберите или создайте прослушиватель. Вы можете создать только один прослушиватель для каждого типа службы. Если у вас уже есть прослушиватель одного типа службы, можно добавить дополнительные порты в существующий прослушиватель. Чтобы следовать примеру, укажите имя службы прослушивателя как mqtts-endpoint.

Параметры TLS можно добавить в прослушиватель, выбрав TLS на существующем порту или добавив новый порт.

Введите следующие параметры:

Параметр	Description
Порт	Номер порта, на котором брокерListener прослушивает подключения MQTT. Обязательный.
Проверка подлинности	Ссылка на ресурс проверки подлинности.
Авторизация	Справочник по ресурсу авторизации.
TLS	Нажмите кнопку Добавить.
Имя секрета	Секрет Kubernetes, содержащий сертификат клиента X.509.

Нажмите кнопку "Применить" , чтобы сохранить параметры TLS.

Измените tls параметр в ресурсе BrokerListener, чтобы указать ручную конфигурацию TLS, ссылающуюся на секрет Kubernetes. Обратите внимание на имя секрета, используемого для сертификата сервера TLS (server-cert-secret в примере выше).

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerServiceName string = 'mqtts-endpoint'
param listenerName string = '<LISTENER_NAME>' // Match the SAN in the server certificate

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceName: listenerServiceName
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8885 // Avoid port conflict with default listener at 18883
        tls: {
          mode: 'Manual'
          manual: {
            secretRef: 'server-cert-secret'
          }
        }
      }
    ]
  }
}

Разверните Bicep-файл с помощью Azure CLI.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: loadbalancer-tls
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  ports:
  - port: 8885 # Avoid port conflict with default listener at 18883
    tls:
      mode: Manual
      manual:
        secretRef: server-cert-secret

После создания ресурса BrokerListener оператор автоматически создает службу Kubernetes и развертывает прослушиватель. Вы можете проверить состояние службы, выполнив команду kubectl get svc.

Подключение к брокеру с помощью TLS

Чтобы проверить подключение TLS с клиентом mosquitto, опубликуйте сообщение и передайте корневой сертификат ЦС в параметре --cafile.

mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt

Не забудьте указать имя пользователя, пароль и т. д., если включена проверка подлинности брокера MQTT.

Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT

Совет

Чтобы использовать localhost, порт должен быть доступен на хост-компьютере. Например, kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. При использовании некоторых дистрибутивов Kubernetes, таких как K3d, можно добавить переадресованный порт.k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer

Примечание.

Чтобы подключиться к брокеру, необходимо распространить корневой каталог доверия, также известный как пакет доверия для всех клиентов. В этом случае корнем доверия является самозаверяющий корневой ЦС, созданный с помощью step CLI. Для проверки цепочки сертификатов сервера требуется распределение доверия клиента. Если клиенты MQTT являются рабочими нагрузками в кластере Kubernetes, вам также нужно создать ConfigMap с корневым ЦС и подключить его в pod.

Использование внешнего IP-адреса для сертификата сервера

Чтобы подключиться к TLS через Интернет, сертификат сервера брокера MQTT должен иметь имя внешнего узла или IP-адрес в качестве SAN. В рабочей среде это обычно DNS-имя или известный IP-адрес. Однако во время разработки и тестирования вы можете не знать, какое имя узла или внешний IP-адрес назначается перед развертыванием. Чтобы решить эту проблему, сначала разверните прослушиватель без сертификата сервера, создайте сертификат сервера и секрет с внешним IP-адресом и импортируйте секрет в прослушиватель.

Если вы попытаетесь развернуть пример прослушивателя manual-tls-listener TLS, но указанный секрет server-cert-secret Kubernetes не существует, связанная служба создается, но модули pod не запускаются. Служба создается, так как оператор должен зарезервировать внешний IP-адрес для прослушивателя.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

Однако это поведение ожидается при импорте сертификата сервера. Журналы диспетчера работоспособности говорят, что брокер MQTT ожидает сертификата сервера.

kubectl logs -l app=health-manager -n azure-iot-operations

...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.

Примечание.

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

Несмотря на то, что интерфейсные модули pod не растут, внешний IP-адрес уже доступен.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

Далее выполните те же действия, что и ранее, чтобы создать сертификат сервера с этим внешним IP-адресом --san и создать секрет Kubernetes таким же образом. После создания секрета он автоматически импортируется в прослушиватель.

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

Защита обмена данными брокера MQTT с помощью BrokerListener

BrokerListener по умолчанию

Избегайте изменения прослушивателя брокера по умолчанию

Создание прослушивателей брокера

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

тип услуги;

Только один прослушиватель на тип службы

Service name

Порты

Использование одного порта для прослушивателей

Поддержка WebSocket

Настройка TLS с помощью автоматического управления сертификатами

Проверка установки cert-manager

Создание издателя для сертификата сервера TLS

Настройка корневого сертификата в качестве секрета Kubernetes

Распространение корневого сертификата

Создание издателя на основе сертификата ЦС

Включение автоматического управления сертификатами TLS для порта

Необязательно. Настройка параметров сертификата сервера

Проверка развертывания

Подключение к брокеру с помощью TLS

Корневой ЦС по умолчанию и издатель по умолчанию

Настройка TLS с помощью ручного управления сертификатами

Создание центра сертификации с помощью step CLI

Создание сертификата сервера

Требования к алгоритму ключа сертификата

Импорт цепочки сертификатов сервера в виде секрета Kubernetes

Включение управления сертификатами TLS вручную для порта

Подключение к брокеру с помощью TLS

Использование внешнего IP-адреса для сертификата сервера

Обратная связь

Дополнительные ресурсы

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

Защита обмена данными брокера MQTT с помощью BrokerListener

BrokerListener по умолчанию

Избегайте изменения прослушивателя брокера по умолчанию

Создание прослушивателей брокера

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

тип услуги;

Только один прослушиватель на тип службы

Service name

Порты

Использование одного порта для прослушивателей

Поддержка WebSocket

Настройка TLS с помощью автоматического управления сертификатами

Проверка установки cert-manager

Создание издателя для сертификата сервера TLS

Настройка корневого сертификата в качестве секрета Kubernetes

Распространение корневого сертификата

Создание издателя на основе сертификата ЦС

Включение автоматического управления сертификатами TLS для порта

Необязательно. Настройка параметров сертификата сервера

Проверка развертывания

Подключение к брокеру с помощью TLS

Корневой ЦС по умолчанию и издатель по умолчанию

Настройка TLS с помощью ручного управления сертификатами

Создание центра сертификации с помощью step CLI

Создание сертификата сервера

Требования к алгоритму ключа сертификата

Импорт цепочки сертификатов сервера в виде секрета Kubernetes

Включение управления сертификатами TLS вручную для порта

Подключение к брокеру с помощью TLS

Использование внешнего IP-адреса для сертификата сервера

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

Обратная связь

Дополнительные ресурсы