Настройка проверки подлинности брокера MQTT

Внимание

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

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

Брокер MQTT поддерживает несколько методов проверки подлинности для клиентов. Вы можете настроить каждый порт прослушивателя, чтобы иметь собственные параметры проверки подлинности с помощью ресурса BrokerAuthentication. Список доступных параметров см . в справочнике по API проверки подлинности брокера.

Link BrokerListener и BrokerAuthentication

Следующие правила применяются к связи между ресурсами BrokerListener и BrokerAuthentication:

• Каждый ресурс BrokerListener может иметь несколько портов. Вы можете связать каждый порт с ресурсом BrokerAuthentication.
• Каждый ресурс BrokerAuthentication может одновременно поддерживать несколько методов проверки подлинности.
• Порты, не ссылающиеся на ресурс BrokerAuthentication, отключили проверку подлинности.

Чтобы связать порт BrokerListener с ресурсом BrokerAuthentication, укажите authenticationRef поле в ports параметре ресурса BrokerListener. Дополнительные сведения см. в ресурсе BrokerListener.

Ресурс BrokerAuthentication по умолчанию

Операции Интернета вещей Azure развертывают ресурс default BrokerAuthentication по умолчанию, связанный с прослушивателем по умолчанию в azure-iot-operations пространстве имен. Он использует только маркеры учетной записи службы Kubernetes (SATs) для проверки подлинности.

Внимание

Метод проверки подлинности SAT в ресурсе BrokerAuthentication по умолчанию необходим для правильной работы компонентов в операциях Интернета вещей. Избегайте обновления или удаления ресурса BrokerAuthentication по умолчанию.

Портал

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

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

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

4. В списке политик проверки подлинности выберите имя политики по умолчанию .

   

Чтобы добавить новые методы проверки подлинности, нажмите кнопку "Добавить".

Bicep

Чтобы изменить конечную точку по умолчанию, создайте файл Bicep .bicep со следующим содержимым. При необходимости обновите параметры. Замените значения заполнителей, как <AIO_INSTANCE_NAME> и собственные.

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 defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
          ]
        }
      }
    ]
  }
}

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

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

Kubernetes (предварительная версия)

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

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

В выходных данных показан ресурс BrokerAuthentication по умолчанию с метаданными, удаленными для краткости:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - aio-internal

Если необходимо внести изменения, измените authenticationMethods поле в этом ресурсе при сохранении метода проверки подлинности SAT с aio-internal аудиторией. Затем разверните его с помощью kubectl apply.

Поток аутентификации

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

Для каждого метода брокер MQTT сначала проверяет, относятся ли учетные данные клиента к этому методу. Например, для проверки подлинности SAT требуется имя пользователя, начиная с K8S-SAT, а для проверки подлинности X.509 требуется сертификат клиента. Если учетные данные клиента актуальны, брокер MQTT проверяет, является ли он допустимым. Дополнительные сведения см. в разделе "Настройка метода проверки подлинности".

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

Поток проверки подлинности заканчивается, когда:

• Одно из следующих условий имеет значение true:
  • Учетные данные клиента актуальны и допустимы для одного из методов.
  • Учетные данные клиента не относятся ни к одному из методов.
  • Учетные данные клиента важны, но недопустимы для любого из методов.
• Брокер MQTT предоставляет или запрещает доступ клиенту в зависимости от результата потока проверки подлинности.

Например:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

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

1. Брокер MQTT проверяет, действительны ли учетные данные клиента для пользовательской проверки подлинности. Так как пользовательская проверка подлинности использует внешний сервер для определения допустимости учетных данных, брокер рассматривает все учетные данные, относящиеся к пользовательской проверке подлинности, и перенаправит их на пользовательский сервер проверки подлинности.
2. Если пользовательский сервер проверки подлинности отвечает с Pass помощью или Fail результата, поток проверки подлинности заканчивается. Если пользовательский сервер проверки подлинности недоступен, брокер MQTT возвращается к оставшимся указанным методам, при этом SAT будет следующим.
3. Брокер MQTT пытается проверить подлинность учетных данных в качестве учетных данных SAT.

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

Настройка метода проверки подлинности

Можно добавить такие методы проверки подлинности, как X.509, SAT или настраиваемые для политик проверки подлинности.

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

Портал

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

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

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

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

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

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

   

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        customSettings: {
          endpoint: 'https://auth-server-template'
          caCertConfigMap: 'custom-auth-ca'
          auth: {
            x509: {
              secretRef: 'custom-auth-client-cert'
            }
          }
          headers: {
            header_key: 'header_value'
          }
        }
      }
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: 'client-ca'
          authorizationAttributes: {
            root: {
              attributes: {
                organization: 'contoso'
              }
              subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
            }
            intermediate: {
              attributes: {
                city: 'seattle'
                foo: 'bar'
              }
              subject: 'CN = Contoso Intermediate CA'
            }
            smartfan: {
              attributes: {
                building: '17'
              }
              subject: 'CN = smart-fan'
            }
          }
        }
      }
    ]
  }
}

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

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

Kubernetes (предварительная версия)

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

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: my-policy
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: Custom
    customSettings:
      endpoint: https://auth-server-template
      caCertConfigMap: custom-auth-ca
      auth:
        x509:
          secretRef: custom-auth-client-cert
      headers:
        header_key: header_value
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience
    - method: X509
      x509Settings:
        trustedClientCaCert: client-ca
        authorizationAttributes:
          root:
            attributes:
              organization: contoso
            subject: CN = Contoso Root CA Cert, OU = Engineering, C = US
          intermediate:
            attributes:
              city: seattle
              foo: bar
            subject: CN = Contoso Intermediate CA
          smart-fan:
            attributes:
              building: "17"
            subject: CN = smart-fan

Чтобы изменить конфигурацию, измените authenticationMethods параметр в этом ресурсе BrokerAuthentication. Затем разверните его с помощью kubectl apply.

Дополнительные сведения о каждом из вариантов проверки подлинности см. в следующих разделах для каждого метода.

Дополнительные сведения о включении безопасных параметров путем настройки экземпляра Azure Key Vault и включения удостоверений рабочей нагрузки см. в статье "Включение безопасных параметров в развертывании операций Интернета вещей Azure".

X.509

Совет

Полный пример настройки проверки подлинности X.509 см. в руководстве по tls, проверке подлинности клиента X.509 и проверке доступа на основе атрибутов (ABAC).

При проверке подлинности X.509 брокер MQTT использует сертификат доверенного центра сертификации (ЦС) для проверки сертификатов клиента. Этот доверенный ЦС может быть корневым или промежуточным ЦС. Брокер проверяет цепочку сертификатов клиента по доверенному сертификату ЦС. Если цепочка допустима, клиент проходит проверку подлинности.

Чтобы использовать проверку подлинности X.509 с доверенным сертификатом ЦС, необходимо выполнить следующие требования:

• Протокол TLS: поскольку X.509 использует сертификаты клиента TLS, протокол TLS должен быть включен для портов с помощью проверки подлинности X.509.
• Ключевые алгоритмы: поддерживаются ключи EC и RSA, но все сертификаты в цепочке должны использовать один и тот же алгоритм ключей.
• Формат: сертификат ЦС должен находиться в формате "Улучшенная конфиденциальность" (PEM).

Совет

Формат PEM — это общий формат для сертификатов и ключей. PEM-файлы — это файлы ASCII в кодировке Base64 с такими заголовками, как -----BEGIN CERTIFICATE----- и -----BEGIN EC PRIVATE KEY-----.

Если у вас есть сертификат в другом формате, его можно преобразовать в PEM с помощью OpenSSL. Дополнительные сведения см. в разделе "Преобразование сертификата в соответствующий формат".

Получение доверенного сертификата ЦС

В рабочей настройке сертификат ЦС предоставляется инфраструктурой открытых ключей организации (PKI) или общедоступным центром сертификации.

Для тестирования создайте самозаверяющий сертификат ЦС с помощью OpenSSL. Например, выполните следующую команду, чтобы создать самозаверяющий сертификат ЦС с ключом RSA, различающееся имя CN=Contoso Root CA Certи срок действия 365 дней:

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

Та же команда с интерфейсом командной строки шага, которая является удобным средством для управления сертификатами, — это:

step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
 --not-after 8760h

Эти команды создают сертификат ca.pemЦС и закрытый ключ ca-key.pemв формате PEM. Сертификат ca.pem ЦС можно импортировать в брокер MQTT для проверки подлинности X.509.

Импорт доверенного сертификата ЦС

Чтобы приступить к работе с проверкой подлинности X.509, импортируйте доверенный сертификат ЦС в ConfigMap в azure-iot-operations пространстве имен. Чтобы импортировать доверенный сертификат ca.pem ЦС в ConfigMap с именем client-ca, выполните следующую команду:

kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations

В этом примере сертификат ЦС импортируется под ключом ca.pem. Брокер MQTT доверяет всем сертификатам ЦС в ConfigMap, чтобы можно было использовать любое имя ключа.

Чтобы проверить правильность импорта корневого сертификата ЦС, выполните команду kubectl describe configmap. В результате показана та же кодировка Base64 файла сертификата PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----


BinaryData
====

Настройка метода проверки подлинности X.509

После импорта доверенного сертификата ЦС включите проверку подлинности клиента X.509, добавив его в качестве метода проверки подлинности в ресурсе BrokerAuthentication. Убедитесь, что этот ресурс связан с портом прослушивателя с поддержкой TLS.

Портал

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

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

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

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

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

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

7. В области сведений о проверке подлинности X.509 укажите имя доверенного сертификата ЦС с помощью формата JSON.

   {
       "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
   }
   

   Замените <TRUSTED_CA_CONFIGMAP> именем ConfigMap, содержащего доверенный сертификат ЦС. Например, укажите "trustedClientCaCert": "client-ca".

   

8. При необходимости добавьте атрибуты авторизации для клиентов с помощью сертификатов X.509. Дополнительные сведения см. в разделе "Атрибуты сертификата" для авторизации.

9. Выберите Применить, чтобы сохранить изменения.

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'
param trustedCaConfigMap string = '<TRUSTED_CA_CONFIGMAP>'

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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: trustedCaConfigMap
          // authorizationAttributes: {
            //// Optional authorization attributes
            //// See the next section for more information
          // }
        }
      }
    ]
  }
}

Замените <TRUSTED_CA_CONFIGMAP> именем ConfigMap, содержащего доверенный сертификат ЦС. Например, укажите client-ca.

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

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

Kubernetes (предварительная версия)

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
        # authorizationAttributes:
          ## Optional authorization attributes
          ## See the next section for more information

Замените <TRUSTED_CA_CONFIGMAP> именем ConfigMap, содержащего доверенный сертификат ЦС. Например, укажите client-ca.

Необязательно. Атрибуты сертификата для авторизации

Атрибуты X.509 можно указать в ресурсе BrokerAuthentication для авторизации клиентов на основе их свойств сертификата. Атрибуты определяются в authorizationAttributes поле.

Например:

Портал

В портал Azure при настройке метода проверки подлинности X.509 добавьте атрибуты авторизации в область сведений о проверке подлинности X.509 в формате JSON.

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "authorizationAttributes": {
    "root": {
      "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
      "attributes": {
        "organization": "contoso"
      }
    },
    "intermediate": {
      "subject": "CN = Contoso Intermediate CA",
      "attributes": {
        "city": "seattle",
        "foo": "bar"
      }
    },
    "smartfan": {
      "subject": "CN = smart-fan",
      "attributes": {
        "building": "17"
      }
    }
  }
}

Bicep

x509Settings: {
  trustedClientCaCert: '<TRUSTED_CA_CONFIGMAP>'
  authorizationAttributes: {
    root: {
      subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
      attributes: {
        organization: 'contoso'
      }
    }
    intermediate: {
      subject: 'CN = Contoso Intermediate CA'
      attributes: {
        city: 'seattle'
        foo: 'bar'
      }
    }
    smartfan: {
      subject: 'CN = smart-fan'
      attributes: {
        building: '17'
      }
    }
  }
}

Kubernetes (предварительная версия)

x509Settings:
  trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
  authorizationAttributes:
    root:
      subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"
      attributes:
        organization = contoso
    intermediate:
      subject = "CN = Contoso Intermediate CA"
      attributes:
        city = seattle
        foo = bar
    smart-fan:
      subject = "CN = smart-fan"
      attributes:
        building = 17

В этом примере каждый клиент, имеющий сертификат, выданный корневым ЦС с различающимися именами или промежуточным ЦС с различающимися именами CN = Contoso Root CA Cert, OU = Engineering, C = USCN = Contoso Intermediate CA , получает перечисленные атрибуты. Кроме того, сертификат клиента smart-fan получает атрибуты, относящиеся к нему.

Сопоставление атрибутов всегда начинается с конечного сертификата клиента, а затем идет по цепочке. Назначение атрибута останавливается после первого совпадения. В предыдущем примере, даже если smart-fan имеется промежуточный сертификат CN = Contoso Intermediate CA, он не получает связанные атрибуты.

Правила авторизации можно применять к клиентам с помощью сертификатов X.509 с этими атрибутами. Дополнительные сведения см. в статье "Авторизация клиентов, использующих проверку подлинности X.509".

Включение проверки подлинности X.509 для порта прослушивателя

После импорта сертификата доверенного ЦС и настройки ресурса BrokerAuthentication свяжите его с портом прослушивателя с поддержкой TLS. Этот шаг важен, так как проверка подлинности X.509 зависит от TLS для проверки сертификата клиента.

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

Примечание.

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

• Проверка клиента: брокер MQTT (сервер) проверяет сертификат клиента на соответствие доверенному сертификату ЦС, указанному trustedClientCaCert в поле для проверки подлинности клиента X.509.
• Проверка сервера: клиенты (например, Mosquitto или MQTTX) проверяют сертификат сервера брокера MQTT по сертификату доверенного ЦС в хранилище доверия. Для клиентов Mosquitto используйте --cafile параметр для указания файла сертификата ЦС. Для MQTTX добавьте сертификат ЦС в хранилище доверия в параметрах.

После включения проверки подлинности X.509 убедитесь, что клиенты доверяют сертификату сервера брокера, получив сертификат ЦС на стороне сервера в хранилище доверия. Не путайте доверие сертификата ЦС на стороне сервера с сертификатом ЦС на стороне клиента, используемым для проверки подлинности клиента, указанной trustedClientCaCert в поле.

Полный пример см. в руководстве по протоколу TLS, проверке подлинности клиента X.509 и авторизации на основе атрибутов (ABAC).

Подключение клиента Mosquitto к брокеру MQTT с сертификатом клиента X.509

Клиенту, например Mosquitto, требуется два файла для подключения к брокеру MQTT с проверкой подлинности клиента TLS и X.509:

• Параметр --cert задает PEM-файл сертификата клиента. Этот файл также должен содержать все промежуточные сертификаты, чтобы помочь брокеру MQTT создать полную цепочку сертификатов.
• Параметр --key задает PEM-файл закрытого ключа клиента.

В случаях, когда брокер MQTT использует самозаверяющий сертификат ЦС для выдачи сертификата сервера TLS, --cafile требуется параметр. Этот файл содержит сертификат ЦС (также известный как пакет доверия), который клиент Mosquitto использует для проверки сертификата сервера брокера при подключении по протоколу TLS. Если издатель сертификата сервера брокера MQTT является частью системного корневого хранилища (например, известных общедоступных ЦС), --cafile параметр может быть опущен.

Например:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem

Общие сведения о потоке проверки подлинности клиента брокера MQTT X.509

Выполните следующие действия для проверки подлинности клиента:

1. Если включена проверка подлинности клиента X.509, подключение клиентов должно представлять сертификат клиента и все промежуточные сертификаты, чтобы брокер MQTT построил цепочку сертификатов, корневую к одному из настроенных доверенных сертификатов.
2. Подсистема балансировки нагрузки направляет связь к одному из интерфейсных брокеров.
3. После того как интерфейсный брокер получает сертификат клиента, он пытается создать цепочку сертификатов, корневую к одному из настроенных сертификатов. Если интерфейсный брокер успешно создает цепочку и проверяется представленная цепочка, она завершает подтверждение TLS. Подключающийся клиент может отправлять пакеты MQTT на интерфейс через канал TLS.
4. Канал TLS открыт, но проверка подлинности клиента или авторизация еще не завершена.
5. Затем клиент отправляет пакет CONNECT брокеру MQTT.
6. Пакет CONNECT перенаправляется на внешний интерфейс снова.
7. Интерфейс собирает все учетные данные, представленные клиентом до сих пор, например данные проверки подлинности из пакета CONNECT, и цепочку сертификатов клиента, представленную во время подтверждения TLS.
8. Интерфейс отправляет эти учетные данные в службу проверки подлинности. Служба проверки подлинности снова проверяет цепочку сертификатов и собирает имена субъектов всех сертификатов в цепочке.
9. Служба проверки подлинности использует настроенные правила авторизации, чтобы определить, какие атрибуты имеют подключающиеся клиенты. Эти атрибуты определяют, какие операции может выполнять клиент, включая сам пакет CONNECT.
10. Служба проверки подлинности возвращает решение интерфейсного брокера.
11. Интерфейсный брокер знает атрибуты клиента и может ли он подключаться. Если да, то подключение MQTT завершено, и клиент может продолжать отправлять и получать пакеты MQTT, как определено правилами авторизации.

Маркеры учетной записи службы Kubernetes

SaTs Kubernetes — это веб-маркеры JSON, связанные с учетными записями службы Kubernetes. Клиенты представляют sats брокеру MQTT для проверки подлинности.

Брокер MQTT использует привязанные маркеры учетной записи службы, описанные в разделе "Какие пользователи GKE должны знать о новых маркерах учетной записи службы Kubernetes". Ниже приведены основные функции из публикации:

Привязанные маркеры, запущенные в Kubernetes 1.13, стали форматом по умолчанию в версии 1.21. Ограничивающие маркеры устраняют все ограниченные функциональные возможности устаревших маркеров и многое другое:

• Маркеры трудно украсть и неправильно использовать. Они привязаны к времени, привязаны к аудитории и привязаны к объектам.
• Они принимают стандартизованный формат. OpenID Connect (OIDC) с полным обнаружением OIDC упрощает прием поставщиков услуг.
• Они распределяются по модулям pod более безопасно с помощью нового проецируемого типа тома Kubelet.

Брокер проверяет маркеры с помощью API проверки маркеров Kubernetes. Включите функцию Kubernetes TokenRequestProjection , чтобы указать audiences (по умолчанию с 1.21). Если эта функция не включена, вы не можете использовать STS.

Создание учетной записи службы

Чтобы создать saTs, сначала создайте учетную запись службы. Следующая команда создает учетную запись службы:mqtt-client

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Необязательно. Добавление атрибутов для авторизации

При проверке подлинности клиентов с помощью SAT могут быть помечены учетные записи службы с атрибутами, которые будут использоваться с политиками авторизации. Чтобы отличить эти заметки от других, они начинаются с aio-broker-auth/ префикса.

Вы можете учесть учетную запись службы с помощью kubectl annotate:

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

Или добавить заметки в файл манифеста учетной записи службы:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <SERVICE_ACCOUNT_NAME>
  namespace: azure-iot-operations
  annotations:
    aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
    aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>

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

Включение проверки подлинности SAT

Измените authenticationMethods параметр в ресурсе BrokerAuthentication, чтобы указать ServiceAccountToken в качестве допустимого метода проверки подлинности. Параметр audiences задает список допустимых аудиторий для токенов. Выберите уникальные значения, определяющие службу брокера MQTT. Необходимо указать по крайней мере одну аудиторию, и все SAT должны соответствовать одной из указанных аудиторий.

Портал

1. В портал Azure перейдите к экземпляру Операций Интернета вещей.
2. В разделе "Компоненты" выберите MQTT Broker.
3. Выберите вкладку Аутентификация.
4. Выберите существующую политику проверки подлинности или создайте новую.
5. Добавьте новый метод, нажав кнопку "Добавить".
6. Выберите тип метода Kubernetes SAT из раскрывающегося списка. Затем нажмите кнопку "Добавить сведения", чтобы настроить метод.

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

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

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

Kubernetes (предварительная версия)

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience

Примените изменения с kubectl applyпомощью . Чтобы изменения вступили в силу, может потребоваться несколько минут.

Проверка проверки подлинности SAT

Проверка подлинности SAT использует поля расширенной проверки подлинности MQTT версии 5. Клиент должен задать для маркера расширенный метод K8S-SAT проверки подлинности и расширенные данные проверки подлинности.

Например, используйте Mosquitto (некоторые поля опущены для краткости):

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

<TOKEN> Ниже приведен маркер учетной записи службы. Чтобы получить тестовый маркер, выполните следующую команду:

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

Ниже приведено имя созданной учетной записи службы и <AUDIENCE> является одной из аудиторий, <SERVICE_ACCOUNT> настроенных в ресурсе BrokerAuthentication.

Пример настройки модуля pod Kubernetes для использования проверки подлинности SAT см. в статье "Подключение к прослушивателю по умолчанию в кластере".

В конфигурации pod поле должно соответствовать учетной записи службы, serviceAccountName связанной с используемым маркером. Поле serviceAccountToken.audience должно быть одним из настроенных в ресурсе audiences BrokerAuthentication.

Обновление маркеров учетной записи службы

Маркеры учетной записи службы допустимы в течение ограниченного времени и настроены.expirationSeconds Однако Kubernetes автоматически обновляет маркер до истечения срока действия. Маркер обновляется в фоновом режиме, и клиенту не нужно делать ничего, кроме того, чтобы снова получить его.

Например, если клиент является модулем pod, использующим маркер, подключенный в качестве тома, например, в примере проверки подлинности SAT последний маркер доступен в том же пути /var/run/secrets/tokens/broker-sat. Когда клиент создает новое подключение, клиент может получить последний маркер и использовать его для проверки подлинности. Клиент также должен иметь механизм обработки несанкционированных ошибок MQTT, извлекая последний маркер и повторив подключение.

Нестандартная проверка подлинности

Расширение проверки подлинности клиента за пределы предоставленных методов проверки подлинности с помощью пользовательской проверки подлинности. Это подключаемый модуль , так как служба может быть любой, если она соответствует API.

Когда клиент подключается к брокеру MQTT с включенной пользовательской проверкой подлинности, брокер отправляет HTTPS-запрос на пользовательский сервер проверки подлинности с учетными данными клиента. Затем сервер отвечает с утверждением или отказом, включая атрибуты авторизации клиента.

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

Сервер пользовательской проверки подлинности реализуется и развертывается отдельно от брокера MQTT.

Пример пользовательского сервера проверки подлинности и инструкции доступны на сайте GitHub. Используйте этот пример как шаблон и отправную точку для реализации собственной пользовательской логики проверки подлинности.

API

API между брокером MQTT и пользовательским сервером проверки подлинности следует спецификации API для пользовательской проверки подлинности. Спецификация OpenAPI доступна на сайте GitHub.

Требуется протокол HTTPS с шифрованием TLS

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

Сервер пользовательской проверки подлинности должен представлять сертификат сервера, а брокер MQTT должен иметь доверенный корневой сертификат ЦС для проверки сертификата сервера. При необходимости для проверки подлинности на пользовательском сервере проверки подлинности может потребоваться брокер MQTT.

Включение пользовательской проверки подлинности для прослушивателя

Измените параметр методов проверки подлинности в ресурсе BrokerAuthentication, чтобы указать Custom в качестве допустимого метода проверки подлинности. Затем укажите параметры, необходимые для взаимодействия с пользовательским сервером проверки подлинности.

Портал

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

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

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

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

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

6. Выберите тип метода Custom из раскрывающегося списка. Затем нажмите кнопку "Добавить сведения", чтобы настроить метод.

   

Bicep

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

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

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

Kubernetes (предварительная версия)

В этом примере показаны все возможные параметры. Точные параметры, необходимые для каждого пользовательского сервера, зависят от требований каждого пользовательского сервера.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Отключение проверки подлинности

Для тестирования можно отключить проверку подлинности для порта прослушивателя брокера. Не рекомендуется отключить проверку подлинности для рабочих сред.

Портал

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

Bicep

Чтобы отключить проверку подлинности, опустить authenticationRefports параметр ресурса BrokerListener.

Kubernetes (предварительная версия)

Чтобы отключить проверку подлинности, опустить authenticationRefports параметр ресурса BrokerListener.

Отключение клиентов после истечения срока действия учетных данных

Брокер MQTT отключает клиентов при истечении срока действия учетных данных. Отключение после истечения срока действия учетных данных применяется ко всем клиентам, которые подключаются к внешним интерфейсам брокера MQTT, например:

• Клиенты, прошедшие проверку подлинности с помощью STS, отключены при истечении срока их действия SAT.
• Клиенты, прошедшие проверку подлинности с помощью X.509, отключены при истечении срока действия сертификата клиента.
• Клиенты, прошедшие проверку подлинности с помощью отключения пользовательской проверки подлинности, зависят от времени истечения срока действия, возвращенного с пользовательского сервера проверки подлинности.

При отключении сетевое подключение клиента закрывается. Клиент не получает пакет MQTT DISCONNECT, но брокер записывает сообщение об отключении клиента.

Клиенты MQTT версии 5, прошедшие проверку подлинности с помощью SATs и настраиваемой проверки подлинности, могут повторно пройти проверку подлинности с новыми учетными данными до истечения срока действия их первоначальных учетных данных. Клиенты X.509 не могут повторно пройти проверку подлинности и должны повторно получить подключение, так как проверка подлинности выполняется на уровне TLS.

Клиенты могут повторно пройти проверку подлинности, отправив пакет AUTH MQTT версии 5 с причиной ReAuth.

Клиенты SAT отправляют клиент AUTH с полями method: K8S-SAT и data: <token>. Клиенты пользовательской проверки подлинности задают метод и поле данных, необходимые пользовательскому серверу проверки подлинности.

Успешное повторная проверка подлинности обновляет срок действия учетных данных клиента с истечением срока действия новых учетных данных. Брокер отвечает с Success помощью пакета AUTH. Сбой проверки подлинности из-за временных проблем, таких как пользовательский сервер проверки подлинности, недоступен, приводит к тому, что брокер отвечает с ContinueAuthentication помощью пакета AUTH. Клиент может повторить попытку позже. Другие сбои проверки подлинности приводят к тому, что брокер отправляет пакет DISCONNECT и закрывает сетевое подключение клиента.

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

• Ресурс BrokerListener
• Настройка авторизации для BrokerListener
• Руководство по TLS, аутентификации клиента X.509 и авторизации на основе атрибутов (ABAC)