Partager 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. Chaque ressource BrokerAuthorization contient une liste de règles qui spécifient les principaux et les ressources des stratégies d’autorisation.

Pour lier un BrokerListener à une ressource BrokerAuthorization, spécifiez le champ authenticationRef dans le paramètre ports de la ressource BrokerListener. Similaire à BrokerAuthentication, la ressource BrokerAuthorization peut être liée à plusieurs ports BrokerListener. Les stratégies d’autorisation s’appliquent à tous les ports d’écouteur liés. Toutefois, il existe une différence clé par rapport à BrokerAuthentication :

Important

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

Pour en savoir plus sur BrokerListener, consultez la ressource BrokerListener.

Règles d’autorisation

Pour configurer l’autorisation, créez une ressource BrokerAuthorization dans votre cluster Kubernetes. Les sections suivantes fournissent des exemples de configuration d’autorisation pour les clients qui utilisent des noms d’utilisateur, des attributs, des certificats X.509 et des jetons de compte Kubernetes Service (SAP). Pour obtenir la liste des paramètres disponibles, consultez la référence de l’API d’autorisation Broker.

L’exemple suivant montre comment créer une ressource BrokerAuthorization à l’aide de noms d’utilisateur et d’attributs :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    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.

Limiter davantage l’accès en fonction de l’ID client

Étant donné que le champ principals est une or logique, vous pouvez restreindre davantage l’accès en fonction de l’ID client en ajoutant le champ clientIds au champ brokerResources. Par exemple, pour autoriser les clients avec des ID clients qui commencent par son numéro de construction pour connecter et publier des données de télémétrie dans des rubriques délimitées par leur génération, utilisez la configuration suivante :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
    - principals:
        attributes:
          - building: "building22"
          - building: "building23"
      brokerResources:
      - method: Connect
        clientIds:
          - "{principal.attributes.building}*" # client IDs must start with building22
      - method: Publish
        topics:
          - "sensors/{principal.attributes.building}/{principal.clientId}/telemetry"

Ici, si le clientIds n’était pas défini sous la méthode Connect, un client avec n’importe quel ID client pouvait se connecter tant qu’il avait l’attribut building défini sur building22 ou building23. En ajoutant le champ clientIds, seuls les clients disposant d’ID client qui commencent par building22 ou building23 peuvent se connecter. Cela garantit non seulement que le client a l’attribut correct, mais également que l’ID client correspond au modèle attendu.

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-broker-auth/group=authz-sat

Les annotations d’attributs doivent commencer par aio-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, omettez le paramètre authorizationRef et ports d’une ressource BrokerListener.

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