Partage via

Configurer l’autorisation de l’agent MQTT

  • Article

Important

Opérations Azure IoT Préversion avec Azure Arc est actuellement en préversion. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Lorsqu’une version en disponibilité générale sera publiée, vous devrez déployer une nouvelle installation d’Opérations Azure IoT. Vous ne pourrez pas mettre à niveau une installation en préversion.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Les stratégies d’autorisation déterminent les actions que les clients peuvent effectuer sur le répartiteur, telles que la connexion, la publication ou l’abonnement aux rubriques. Configurer l’agent MQTT pour qu’il utilise une ou plusieurs stratégies d’autorisation à l’aide de la ressource BrokerAuthorization.

Vous pouvez définir une valeur BrokerAuthorization pour chaque écouteur. Chaque ressource BrokerAuthorization contient une liste de règles qui spécifient les principaux et les ressources des stratégies d’autorisation.

Important

Pour que la configuration BrokerAuthorization s’applique à un écouteur, au moins une ressource BrokerAuthentication doit également être associée à cet écouteur.

Configurer BrokerAuthorization pour les écouteurs

La spécification d’une ressource BrokerAuthorization comporte les champs suivants :

Nom du champ Requis Description
authorizationPolicies Oui Ce champ définit les paramètres pour les stratégies d’autorisation, comme enableCache et rules.
enableCache Non Indique s’il faut activer la mise en cache pour les stratégies d’autorisation. Si la valeur est définie sur true, le répartiteur met en cache les résultats d’autorisation pour chaque combinaison client et rubrique afin d’améliorer les performances et de réduire la latence. Si la valeur est définie sur false, le répartiteur évalue les stratégies d’autorisation pour chaque demande de client et de rubrique, afin de garantir la cohérence et l’exactitude. Ce champ est facultatif et est défini par défaut sur false.
rules Non Une liste de règles qui spécifient les principaux et les ressources pour les stratégies d’autorisation. Chaque règle a ces sous-champs : principals et brokerResources.
principaux Oui Ce sous-champ définit les identités qui représentent les clients, comme usernames, clientids et attributes.
Noms d’utilisateurs Non Liste des noms d’utilisateurs qui correspondent aux clients. Les noms d’utilisateurs respectent la casse et doivent correspondre aux noms d’utilisateurs fournis par les clients lors de l’authentification.
clientids Non Une liste d’ID client qui correspondent aux clients. Les ID client respectent la casse et doivent correspondre aux ID client fournis par les clients lors de la connexion.
attributs Non Liste des paires clés-valeurs qui correspondent aux attributs des clients. Les attributs respectent la casse et doivent correspondre aux attributs fournis par les clients lors de l’authentification.
brokerResources Oui Ce sous-champ définit les objets qui représentent les actions ou les rubriques, comme method et topics.
method Oui Type d’action que les clients peuvent effectuer sur le répartiteur. Ce sous-champ est obligatoire et peut être l’une des valeurs suivantes : Connect : cette valeur indique que les clients peuvent se connecter au répartiteur. Publier : cette valeur indique que les clients peuvent publier des messages dans des rubriques sur le répartiteur. S’abonner : cette valeur indique que les clients peuvent s’abonner à des rubriques sur le répartiteur.
topics Non Liste des rubriques ou modèles de rubriques qui correspondent aux rubriques sur lesquelles les clients peuvent publier ou auxquelles ils peuvent s’abonner. Ce sous-champ est requis si la méthode est Subscribe ou Publish.

L’exemple suivant montre comment créer une ressource BrokerAuthorization qui définit les stratégies d’autorisation d’un écouteur nommé my-listener.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    enableCache: true
    rules:
      - principals:
          usernames:
            - temperature-sensor
            - humidity-sensor
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.username}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Cette autorisation de répartiteur permet aux clients avec les noms d’utilisateurs temperature-sensor ou humidity-sensor ou ayant les attributs organization avec la valeur contoso et les attributs city avec la valeur seattle, de :

  • se connecter au répartiteur ;
  • publier des messages dans des rubriques de télémétrie délimitées par leurs noms d’utilisateurs et leur organisation. Par exemple :
    • temperature-sensor peut publier sur /telemetry/temperature-sensor et /telemetry/contoso.
    • humidity-sensor peut publier sur /telemetry/humidity-sensor et /telemetry/contoso.
    • some-other-username peut publier sur /telemetry/contoso.
  • Abonnez-vous aux rubriques de commandes délimitées par leur organisation. Par exemple :
    • temperature-sensor peut s’abonner à /commands/contoso.
    • some-other-username peut s’abonner à /commands/contoso.

Pour créer cette ressource BrokerAuthorization, appliquez le manifeste YAML à votre cluster Kubernetes.

Autoriser les clients qui utilisent l’authentification X.509

Les clients qui utilisent des certificats X.509 pour l’authentification peuvent être autorisés à accéder aux ressources basées sur les propriétés X.509 présentes sur leur certificat ou sur leurs certificats émetteurs dans la chaîne.

Utilisation d’attributs

Pour créer des règles basées sur les propriétés du certificat d’un client, de son autorité de certification racine ou intermédiaire, définissez les attributs X.509 dans la ressource BrokerAuthorization. Pour plus d’informations, consultez Attributs de certificat.

Avec le nom commun d’objet de certificat client comme nom d’utilisateur

Pour créer des stratégies d’autorisation basées uniquement sur le nom commun d’objet de certificat client, créez des règles basées sur le nom commun (CN).

Par exemple, si un client a un certificat avec l’objet CN = smart-lock, son nom d’utilisateur est smart-lock. À ce stade, créez des stratégies d’autorisation comme normale.

Autoriser les clients qui utilisent des jetons de comptes de service Kubernetes

Les attributs d’autorisation pour les SAT sont définis dans le cadre des annotations de comptes de service. Par exemple, pour ajouter un attribut d’autorisation nommé group avec la valeur authz-sat, exécutez la commande :

kubectl annotate serviceaccount mqtt-client aio-mq-broker-auth/group=authz-sat

Les annotations d’attributs doivent commencer par aio-mq-broker-auth/ afin de se distinguer des autres annotations.

Comme l’application a un attribut d’autorisation appelé authz-sat, il n’est pas nécessaire de fournir clientId ni username. La ressource BrokerAuthorization correspondante utilise cet attribut comme principal, par exemple :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Pour en savoir plus avec un exemple, consultez Configurer la stratégie d’autorisation avec le client Dapr.

Magasin d’états distribué

L’agent MQTT fournit un magasin d’état distribué (DSS) que les clients peuvent utiliser pour stocker l’état. Le magasin d’états distribué peut également être configurée pour une haute disponibilité.

Pour configurer l’autorisation pour les clients qui utilisent le magasin d’états distribué, fournissez les autorisations suivantes :

  • Autorisation de publier sur la rubrique $services/statestore/_any_/command/invoke/request du magasin de valeurs de clé système
  • Autorisation de s’abonner à la rubrique de réponse (définie lors de la publication initiale en tant que paramètre) <response_topic>/#

Pour plus d’informations sur l’autorisation DSS, consultez les clés de la mémoire d’état.

Mettre à jour une autorisation

Les ressources d’autorisation du répartiteur peuvent être mises à jour lors du runtime sans redémarrage. Tous les clients connectés au moment de la mise à jour de la stratégie sont déconnectés. La modification du type de stratégie est également prise en charge.

kubectl edit brokerauthorization my-authz-policies

Désactiver l’autorisation

Pour désactiver l’autorisation, définissez authorizationEnabled: false dans la ressource BrokerListener. Lorsque la stratégie est définie de sorte à autoriser tous les clients, tous les clients authentifiés peuvent accéder à l’ensemble des opérations.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: "my-listener"
  namespace: azure-iot-operations
spec:
  brokerRef: "my-broker"
  authenticationEnabled: false
  authorizationEnabled: false
  port: 1883

Publication non autorisée dans MQTT 3.1.1

Avec MQTT 3.1.1, lorsqu’une publication est refusée, le client reçoit PUBACK sans erreur, car la version du protocole ne prend pas en charge le renvoi du code d’erreur. MQTTv5 retourne PUBACK avec le code de raison 135 (non autorisé) lorsque la publication est refusée.

Contenu connexe