Partager via

Configurer l’authentification de MQTT broker

  • Article

Important

Cette page inclut des instructions pour la gestion des composants Azure IoT Operations à l’aide des manifestes de déploiement Kubernetes, qui sont en version préliminaire. Cette fonctionnalité est fournie avec plusieurs limitations et ne doit pas être utilisée pour les charges de travail de production.

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.

Un Agent MQTT prend en charge plusieurs méthodes d’authentification. Vous pouvez configurer chaque port d’écoute pour qu’il ait ses propres paramètres d’authentification avec une ressource BrokerAuthentication. Pour obtenir la liste des paramètres disponibles, consultez la référence de l’API d’authentification Broker.

Les règles suivantes s’appliquent à la relation entre les ressources BrokerListener et BrokerAuthentication :

  • Chaque ressource BrokerListener peut avoir plusieurs ports. Vous pouvez associer chaque port à une ressource BrokerAuthentication.
  • Chaque ressource BrokerAuthentication peut prendre en charge plusieurs méthodes d’authentification à la fois.
  • L’authentification des ports qui ne lient pas des ressources BrokerAuthentication est désactivée.

Pour lier un port BrokerListener à une ressource BrokerAuthentication, spécifiez le champ authenticationRef dans le paramètre ports de la ressource BrokerListener. Pour en savoir plus, consultez Ressource BrokerListener.

Ressource BrokerAuthentication par défaut

Opérations Azure IoT déploie une ressource BrokerAuthentication par défaut nommée default liée à l’écouteur par défaut dans l’espace de noms azure-iot-operations. Elle utilise uniquement les jetons de compte de service Kubernetes (SAT) pour l’authentification.

Important

La méthode d’authentification SAT dans la ressource BrokerAuthentication par défaut est requise pour que les composants des opérations IoT fonctionnent correctement. Évitez de mettre à jour ou de supprimer la ressource BrokerAuthentication par défaut.

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Composants, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Dans la liste des stratégies d’authentification, sélectionnez le nom de la stratégie par défaut.

    Capture d’écran montrant l’affichage de la stratégie d’authentification de l’Agent MQTT par défaut dans le portail Azure.

Pour ajouter de nouvelles méthodes d’authentification, sélectionnez Ajouter une méthode.

Flux d’authentification

L’ordre des méthodes d’authentification spécifiées dans le tableau détermine comment l’Agent MQTT authentifie les clients. L’Agent MQTT tente d’authentifier les informations d’identification du client en utilisant la première méthode spécifiée, et parcourt les méthodes spécifiées jusqu’à ce qu’il trouve une correspondance ou atteigne la fin.

Pour chaque méthode, MQTT broker vérifie d’abord si les informations d’identification du client sont pertinentes pour cette méthode. Par exemple, l’authentification SAT nécessite un nom d’utilisateur commençant par K8S-SAT, et l’authentification X.509 nécessite un certificat client. Si les informations d’identification du client sont pertinentes, l’Agent MQTT vérifie ensuite si elles sont valides. Pour plus d’informations, consultez la section Configurer la méthode d’authentification.

Pour l’authentification personnalisée, l’Agent MQTT traite l’échec de la communication avec le serveur d’authentification personnalisé comme des informations d’identification non pertinentes. Ce comportement permet à l’Agent MQTT de revenir à d’autres méthodes si le serveur d’authentification personnalisée est inaccessible.

Le flux d’authentification se termine lorsque :

  • L’une de ces conditions est vraie :
    • Les informations d’identification du client sont pertinentes et valides pour l’une des méthodes.
    • Les informations d’identification du client ne sont pertinentes pour aucune des méthodes.
    • Les informations d’identification du client sont pertinentes mais non valides pour l’une des méthodes.
  • L’Agent MQTT accorde ou refuse l’accès au client en fonction du résultat du flux d’authentification.

Par exemple :

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

L’exemple précédent spécifie custom et SAT. Lorsqu’un client se connecte, l’Agent MQTT tente d’authentifier le client en utilisant les méthodes spécifiées dans l’ordre custom, puis SAT.

  1. L’Agent MQTT vérifie si les informations d’identification du client sont valides pour l’authentification personnalisée. Étant donné que l’authentification personnalisée s’appuie sur un serveur externe pour déterminer la validité des informations d’identification, le répartiteur considère toutes les informations d’identification pertinentes pour l’authentification personnalisée et les transfère au serveur d’authentification personnalisé.
  2. Si le serveur d’authentification personnalisé répond avec le résultat Pass ou Fail, le flux d’authentification se termine. Si le serveur d’authentification personnalisé n’est pas disponible, l’Agent MQTT revient aux méthodes spécifiées restantes, la méthode SAT étant la suivante.
  3. L’Agent MQTT tente d’authentifier les informations d’identification en tant qu’informations d’identification SAT.

Si le serveur d’authentification personnalisée n’est pas disponible et que toutes les méthodes suivantes ont déterminé que les informations d’identification fournies ne sont pas pertinentes, alors le répartiteur refuse la connexion cliente.

Configurer la méthode d'authentification

Vous pouvez ajouter des méthodes d’authentification telles que X.509, SAT ou personnalisées aux stratégies d’authentification.

Pour ajouter une méthode d’authentification à une stratégie :

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Composants, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Choisissez une stratégie d’authentification existante ou créez-en une.

  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.

  6. Choisissez le type de méthode dans la liste déroulante, puis sélectionnez Ajouter des détails pour configurer la méthode.

    Capture d’écran montrant l’ajout d’une stratégie d’authentification de l’Agent MQTT dans le portail Azure.

Pour en savoir plus sur chacune des options d’authentification, consultez les sections suivantes pour chaque méthode.

Pour plus d’informations sur l’activation des paramètres sécurisés en configurant une instance Azure Key Vault et en activant des identités de charge de travail, consultez Activer les paramètres sécurisés dans le déploiement Opérations Azure IoT.

X.509

Conseil

Pour obtenir un exemple de la configuration de bout en bout de l’authentification X.509, consultez Tutoriel : TLS, authentification du client X.509 et autorisation de contrôle d’accès en fonction des attributs (ABAC).

Avec l’authentification X.509, l’Agent MQTT utilise un certificat d’autorité de certification approuvé pour valider les certificats clients. Cette autorité de certification approuvée peut être une autorité de certification racine ou intermédiaire. L’agent vérifie la chaîne de certificat client sur le certificat d’autorité de certification approuvé. Si la chaîne est valide, le client est authentifié.

Pour utiliser l’authentification X.509 avec un certificat d’autorité de certification approuvé, les conditions suivantes doivent être remplies :

  • Protocole Transport Layer Security (TLS) : étant donné que X.509 s’appuie sur des certificats clients TLS, TLS doit être activé pour les ports utilisant l’authentification X.509.
  • Algorithmes clés : les clés EC et RSA sont prises en charge, mais tous les certificats de la chaîne doivent utiliser le même algorithme de clé.
  • Format : le certificat d’autorité de certification doit être au format PEM (Privacy Enhanced Mail).

Conseil

Le format PEM est un format couramment utilisé pour les certificats et les clés. Les fichiers PEM sont des fichiers ASCII encodés en base64 avec des en-têtes tels que -----BEGIN CERTIFICATE----- et -----BEGIN EC PRIVATE KEY-----.

Si vous utilisez un certificat dans un autre format, vous pouvez aussi le convertir au format PEM avec OpenSSL. Pour plus d’informations, consultez Convertir un certificat au format approprié.

Obtenir un certificat d’autorité de certification approuvé

Dans une configuration de production, le certificat d’autorité de certification est fourni par l’infrastructure à clé publique (PKI) d’une organisation ou une autorité de certification publique.

Pour les tests, créez un certificat d’autorité de certification auto-signé avec OpenSSL. Par exemple, exécutez la commande suivante pour générer un certificat d’autorité de certification auto-signé avec une clé RSA, un nom unique CN=Contoso Root CA Cert et une validité de 365 jours :

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

La même commande avec l’étape CLI, qui est un outil pratique pour la gestion des certificats, est la suivante :

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

Ces commandes créent un certificat d’autorité de certification ca.pem et une clé ca-key.pem privée au format PEM. Vous pouvez importer le certificat d’autorité de certification ca.pem dans l’Agent MQTT pour l’authentification X.509.

Importer un certificat d'Autorité de certification approuvée

Pour commencer à utiliser l’authentification X.509, importez le certificat d’autorité de certification approuvé dans un ConfigMap dans l’espace de noms azure-iot-operations. Pour importer un certificat d’autorité de certification approuvé ca.pem dans un ConfigMap nommé client-ca, exécutez :

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

Dans cet exemple, le certificat d’autorité de certification est importé sous la clé ca.pem. L’Agent MQTT approuve tous les certificats d’autorité de certification dans la ConfigMap, le nom de la clé n’est donc pas défini.

Pour vérifier que le certificat d’autorité de certification racine est correctement importé, exécutez kubectl describe configmap. Le résultat montre le même encodage Base64 du fichier de certificat 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
====

Configurer la méthode d’authentification X.509

Une fois le certificat d’autorité de certification approuvé importé, activez l’authentification client X.509 en l’ajoutant en tant que méthode d’authentification dans une ressource BrokerAuthentication. Vérifiez que cette ressource est bien liée à un port d’écoute compatible avec TLS.

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Composants, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Choisissez une stratégie d’authentification existante ou créez-en une.

  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.

  6. Choisissez le type de méthode X.509 dans la liste déroulante. Sélectionnez ensuite Ajouter des détails pour configurer la méthode.

  7. Dans le volet Détails de l’authentification X.509, spécifiez le nom ConfigMap du certificat d’autorité de certification approuvé au format JSON.

    {
    "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
}

    Remplacez <TRUSTED_CA_CONFIGMAP> par le nom du ConfigMap qui contient le certificat d’autorité de certification approuvé. Par exemple, utilisez "trustedClientCaCert": "client-ca".

    Capture d’écran montrant l’utilisation du portail Azure pour définir la méthode d’authentification X.509 de l’Agent MQTT.

  8. Si vous le souhaitez, ajoutez des attributs d’autorisation pour les clients utilisant des certificats X.509. Pour plus d’informations, consultez Attributs de certificat pour l’autorisation.

  9. Cliquez sur Appliquer pour enregistrer les modifications.

Facultatif : attributs de certificat pour l’autorisation

Vous pouvez spécifier les attributs X.509 dans la ressource BrokerAuthentication pour autoriser les clients en fonction de leurs propriétés de certificat. Les attributs sont définis dans le champ authorizationAttributes.

Par exemple :

Dans le portail Microsoft Azure, lorsque vous configurez la méthode d’authentification X.509, ajoutez les attributs d’autorisation dans le volet d’informations d’authentification X.509 au format 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"
      }
    }
  }
}

Dans cet exemple, chaque client disposant d’un certificat émis par l’autorité de certification racine portant un nom unique CN = Contoso Root CA Cert, OU = Engineering, C = US ou l’autorité de certification intermédiaire portant un nom unique CN = Contoso Intermediate CA reçoit les attributs répertoriés. En outre, le certificat client smart fan reçoit des attributs spécifiques à celui-ci.

La correspondance pour les attributs commence toujours à partir du certificat client de nœud terminal, puis est acheminée le long de la chaîne. L’affectation d’attributs s’arrête après la première correspondance. Dans l’exemple précédent, même si smart-fan a le certificat intermédiaire CN = Contoso Intermediate CA, il n’obtient pas les attributs associés.

Vous pouvez appliquer des règles d’autorisation aux clients utilisant des certificats X.509 avec ces attributs. Pour plus d’informations, consultez Autoriser les clients qui utilisent l’authentification X.509.

Activer l’authentification X.509 pour un port d’écouteur

Après avoir importé le certificat d’autorité de certification approuvé et configuré la ressource BrokerAuthentication, liez-la à un port d’écoute compatible avec TLS. Cette étape est importante, car l’authentification X.509 s’appuie sur TLS pour la validation des certificats clients.

Pour obtenir un port d’écouteur compatible avec TLS, consultez Activer la gestion manuelle des certificats TLS pour un port et Activer la gestion automatique des certificats TLS pour un port.

Remarque

L’activation de TLS sur un port d’écoute d’agent signifie que l’agent utilise un certificat de serveur pour le chiffrement TLS. Lorsque les clients se connectent à ce port, ils doivent approuver le certificat de serveur en ayant le certificat d’autorité de certification qui l’a signée dans leur magasin de confiance. Ce processus est appelé distribution de confiance ou groupement de confiance. Il est important de comprendre la différence entre la validation par le client et la validation par le serveur :

  • Validation par le client : l’agent MQTT (serveur) vérifie le certificat client par rapport au certificat d’autorité de certification approuvé spécifié dans le champ trustedClientCaCert pour l’authentification client X.509.
  • Validation par le serveur : les clients (comme Mosquitto ou MQTTX) vérifient le certificat de serveur de l’Agent MQTT sur le certificat d’autorité de certification approuvé dans leur magasin de confiance. Pour les clients Mosquitto, utilisez le paramètre --cafile pour spécifier le fichier de certificat d’autorité de certification. Pour MQTTX, ajoutez le certificat d’autorité de certification au magasin de confiance dans les paramètres.

Après avoir activé l’authentification X.509, assurez-vous que les clients font confiance au certificat de serveur de l’agent en ayant le certificat d’autorité de certification côté serveur dans leur magasin de confiance. Ne confondez pas l’approbation du certificat d’autorité de certification côté serveur avec le certificat d’autorité de certification côté client utilisé pour l’authentification client spécifiée dans le champ trustedClientCaCert.

Pour voir un exemple complet, consultez Tutoriel : TLS, authentification client X.509 et autorisation de contrôle d'accès basé sur les attributs (ABAC).

Connecter le client Mosquitto à MQTT broker avec un certificat client X.509

Un client comme Mosquitto a besoin de deux fichiers pour pouvoir se connecter à l’Agent MQTT avec TLS et l’authentification client X.509 :

  • Le paramètre --cert spécifie le fichier PEM du certificat client. Ce fichier doit également inclure tous les certificats intermédiaires pour aider l’Agent MQTT à générer la chaîne de certificats complète.
  • Le paramètre --key spécifie le fichier PEM de clé privée du client.

Dans les cas où l’Agent MQTT utilise un certificat d’autorité de certification auto-signé pour émettre son certificat de serveur TLS, le paramètre --cafile est nécessaire. Ce fichier contient le certificat d’autorité de certification (aussi appelé groupe de confiance) que le client Mosquitto utilise pour valider le certificat de serveur de l’agent lors de la connexion via TLS. Si l’émetteur du certificat de serveur de l’Agent MQTT fait partie du magasin racine système (par exemple, les autorités de certification publiques connues), le paramètre --cafile peut être omis.

Par exemple :

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

Comprendre le flux d’authentification du client X.509 MQTT broker

Diagramme affichant le flux d’authentification client X.509.

Pour l’authentification client, procédez comme suit :

  1. Lorsque l’authentification client X.509 est activée, les clients se connectant doivent présenter leur certificat client et tous les certificats intermédiaires pour permettre à l’Agent MQTT de générer une chaîne de certificats enracinée dans l’un de ses certificats approuvés configurés.
  2. L’équilibreur de charge dirige la communication vers l’un des répartiteurs front-end.
  3. Une fois que le répartiteur front-end a reçu le certificat client, il tente de générer une chaîne de certificats qui est enracinée dans l’un des certificats configurés. Si le répartiteur front-end a correctement créé une chaîne et que la chaîne présentée est vérifiée, il termine l’établissement d’une liaison TLS. Le client qui se connecte est en mesure d’envoyer des paquets MQTT au front-end via le canal TLS.
  4. Le canal TLS est ouvert, mais l’authentification ou l’autorisation du client n’est pas encore terminée.
  5. Le client envoie ensuite un paquet CONNECT à l’Agent MQTT.
  6. Le paquet CONNECT est routé à nouveau vers le serveur front-end.
  7. Le serveur frontal collecte toutes les informations d’identification présentées par le client jusqu’à présent, telles que les données d’authentification à partir du paquet CONNECT et la chaîne de certificats client présentée lors de l’établissement d’une liaison TLS.
  8. Le serveur front-end envoie ces informations d’identification au service d’authentification. Le service d’authentification vérifie à nouveau la chaîne de certificats et collecte les noms d’objet de tous les certificats de la chaîne.
  9. Le service d’authentification utilise ses règles d’autorisation configurées pour déterminer les attributs dont disposent les clients qui se connectent. Ces attributs déterminent les opérations que le client peut exécuter, y compris le paquet CONNECT lui-même.
  10. Le service d’authentification retourne la décision au répartiteur front-end.
  11. Le répartiteur front-end connaît les attributs du client et s’il est autorisé à se connecter. Si c’est le cas, alors la connexion MQTT est achevée et le client peut continuer à envoyer et recevoir des paquets MQTT déterminés par ses règles d’autorisation.

Jetons de compte de service Kubernetes

Les jetons de compte de service (SAT) Kubernetes sont des JSON Web Tokens associés à des comptes de service Kubernetes. Les clients présentent des SAT à MQTT broker pour s’authentifier eux-mêmes.

L’Agent MQTT utilise des jetons de compte de service liés qui sont détaillés dans le billet Ce que les utilisateurs de GKE doivent savoir sur les nouveaux jetons de compte de service Kubernetes. Voici les principales informations de la publication :

Les jetons liés ont été lancés dans Kubernetes 1.13 et sont devenus le format par défaut dans la version 1.21. Les jetons liés traitent toutes les fonctionnalités limitées des jetons hérités, et bien plus encore :

  • Les jetons sont difficiles à voler et à utiliser à mauvais escient. Ils sont liés au temps, à l’audience et à l’objet.
  • Ils adoptent un format standardisé. OpenID Connect (OIDC), avec détection OIDC complète, ce qui permet aux fournisseurs de services de les accepter plus facilement.
  • Ils sont distribués aux pods de manière plus sécurisée, à l’aide d’un nouveau type de volume projeté Kubelet.

L’agent vérifie les jetons à l’aide de l’API de révision des jetons Kubernetes. Activez la fonctionnalité TokenRequestProjection Kubernetes pour spécifier audiences (par défaut depuis la version 1.21). Si cette fonctionnalité n’est pas activée, vous ne pouvez pas utiliser les SAT.

Création d’un compte de service

Pour créer des SAT, commencez par créer un compte de service. La commande suivante crée un compte de service appelé mqtt-client.

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

Facultatif : ajouter des attributs pour l’autorisation

Les clients qui s’authentifient via SAT peuvent éventuellement avoir leurs comptes de service annotés avec des attributs à utiliser avec les stratégies d’autorisation. Pour distinguer ces annotations des autres, elles commencent par le préfixe aio-broker-auth/.

Vous pouvez annoter un compte de service à l’aide de kubectl annotate :

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

Vous pouvez également ajouter les annotations au fichier manifeste du compte de service :

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>

Pour plus d’informations, consultez Autoriser les clients qui utilisent des jetons de compte de service Kubernetes.

Activer l’authentification SAT

Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier ServiceAccountToken comme méthode d’authentification valide. Le paramètre audiences spécifie la liste des audiences valides pour les jetons. Choisissez des valeurs uniques qui identifient le service MQTT broker. Vous devez spécifier au moins une audience, et tous les SAT doivent correspondre à l’une des audiences spécifiées.

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.
  2. Sous Composants, sélectionnez Agent MQTT.
  3. Sélectionnez l’onglet Authentification.
  4. Choisissez une stratégie d’authentification existante ou créez-en une.
  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.
  6. Choisissez le type de méthode SAT Kubernetes dans la liste déroulante. Sélectionnez ensuite Ajouter des détails pour configurer la méthode.

Capture d’écran montrant l’utilisation du portail Azure pour définir la méthode d’authentification SAT de l’Agent MQTT.

Tester l’authentification SAT

L’authentification SAT utilise les champs d’authentification améliorés MQTT v5. La méthode d’authentification améliorée sur K8S-SAT et les données d’authentification améliorées sur le jeton doivent être définies par le client.

Par exemple, en utilisant Mosquitto (certains champs sont omis pour rester concis) :

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

Ici, <TOKEN> est le jeton de compte de service. Pour obtenir un jeton de test, exécutez :

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

Ici, <SERVICE_ACCOUNT> est le nom du compte de service que vous avez créé et <AUDIENCE> est l’une des audiences configurées dans la ressource BrokerAuthentication.

Pour obtenir un exemple de configuration d’un pod Kubernetes pour qu’il utilise l’authentification SAT, consultez Se connecter à l’écouteur par défaut à l’intérieur du cluster.

Dans la configuration du pod, le champ serviceAccountName doit correspondre au compte de service associé au jeton utilisé. Le champ serviceAccountToken.audience doit être l’un des audiences configurés dans la ressource BrokerAuthentication.

Actualiser les jetons de compte de service

Les jetons de compte de service sont valides pendant une durée limitée et configurés avec expirationSeconds. Toutefois, Kubernetes actualise automatiquement le jeton avant son expiration. Le jeton est actualisé en arrière-plan et le client a seulement besoin de le récupérer à nouveau.

Par exemple, si le client est un pod qui utilise le jeton monté en tant que volume, comme dans l’exemple Tester l’authentification SAT, le dernier jeton est disponible au même chemin d’accès /var/run/secrets/tokens/broker-sat. Lorsque le client effectue une nouvelle connexion, il peut récupérer le dernier jeton et l’utiliser pour s’authentifier. Le client doit également disposer d’un mécanisme permettant de gérer les erreurs non autorisées MQTT en récupérant le dernier jeton et en réessayant la connexion.

Authentification personnalisée

Étendez l’authentification du client au-delà des méthodes d’authentification fournies avec l’authentification personnalisée. Le service est enfichable car il peut être n’importe quoi tant qu’il respecte l’API.

Lorsqu’un client se connecte à l’agent MQTT avec l’authentification personnalisée activée, l’agent envoie une requête HTTPS à un serveur d’authentification personnalisé avec les informations d’identification du client. Le serveur répond ensuite par approbation ou déni, y compris les attributs d’autorisation du client.

Créer un service d’authentification personnalisé

Le serveur d’authentification personnalisé est implémenté et déployé séparément de l’Agent MQTT.

Un exemple de serveur d’authentification personnalisé et des instructions sont disponibles sur GitHub. Utilisez cet exemple en tant que modèle et point de départ pour implémenter votre propre logique d’authentification personnalisée.

API

L’API entre l’Agent MQTT et le serveur d’authentification personnalisé suit la spécification de l’API pour l’authentification personnalisée. La spécification OpenAPI est disponible sur GitHub.

HTTPS avec chiffrement TLS requis

L’Agent MQTT envoie des requêtes contenant des informations d’identification client sensibles au serveur d’authentification personnalisée. Pour protéger ces informations d’identification, la communication entre l’Agent MQTT et le serveur d’authentification personnalisée doit être chiffrée avec TLS.

Le serveur d’authentification personnalisée doit présenter un certificat de serveur, et l’Agent MQTT doit disposer d’un certificat d’autorité de certification racine approuvé pour valider le certificat de serveur. Si vous le souhaitez, le serveur d’authentification personnalisée peut exiger que l’Agent MQTT présente un certificat client pour s’authentifier lui-même.

Activer l’authentification personnalisée pour un écouteur

Modifiez le paramètre Méthodes d’authentification dans une ressource BrokerAuthentication pour spécifier Personnalisée comme méthode d’authentification valide. Ensuite, spécifiez les paramètres nécessaires pour communiquer avec un serveur d’authentification personnalisé.

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Composants, sélectionnez Agent MQTT.

  3. Sélectionnez l’onglet Authentification.

  4. Choisissez une stratégie d’authentification existante ou créez-en une.

  5. Ajoutez une nouvelle méthode en sélectionnant Ajouter une méthode.

  6. Choisissez le type de méthode Personnalisée dans la liste déroulante. Sélectionnez ensuite Ajouter des détails pour configurer la méthode.

    Capture d’écran montrant l’utilisation du portail Azure pour définir la méthode d’authentification personnalisée de l’Agent MQTT.

Désactiver l’authentification

Pour les tests, vous pouvez désactiver l’authentification pour un port d’écouteur d’agent. Nous ne vous recommandons pas de désactiver l’authentification pour les environnements de production.

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.
  2. Sous Composants, sélectionnez Agent MQTT.
  3. Sélectionnez l’écouteur d’agent que vous souhaitez modifier dans la liste.
  4. Sur le port pour lequel vous souhaitez désactiver l’authentification, sélectionnez Aucune dans la liste déroulante d’authentification.

Déconnexion des clients après expiration des informations d’identification

L’Agent MQTT déconnecte les clients à l’expiration de leurs informations d’identification. La déconnexion après l’expiration des informations d’identification s’applique à tous les clients qui se connectent aux front-ends de l’Agent MQTT, notamment :

  • Les clients authentifiés avec des SAT se déconnectent lorsque leur SAT expire.
  • Les clients authentifiés avec X.509 se déconnectent lorsque leur certificat client expire.
  • Les clients authentifiés avec une authentification personnalisée se déconnectent en fonction de l’heure d’expiration retournée par le serveur d’authentification personnalisée.

Lors de la déconnexion, la connexion réseau du client est fermée. Le client ne reçoit pas de paquet MQTT DISCONNECT, mais l’agent enregistre un message indiquant qu’il a déconnecté le client.

Les clients MQTT v5 authentifiés avec des SAT et une authentification personnalisée peuvent se réauthentifier avec de nouvelles informations d’identification avant l’expiration de leurs informations d’identification initiales. Les clients X.509 ne peuvent pas se réauthentifier et doivent rétablir la connexion, car l’authentification est effectuée au niveau de la couche TLS.

Les clients peuvent se réauthentifier en envoyant un paquet AUTH MQTT v5 avec un motif ReAuth.

Les clients SAT envoient un client AUTH avec les champs method: K8S-SAT et data: <token>. Les clients d’authentification personnalisée définissent la méthode et le champ de données en fonction des exigences du serveur d’authentification personnalisée.

La réauthentification réussie met à jour l’expiration des informations d’identification du client avec l’heure d’expiration de ses nouvelles informations d’identification. Le répartiteur répond avec un paquet AUTH Success. L’échec de l’authentification en raison de problèmes temporaires, comme l’indisponibilité du serveur d’authentification personnalisée, entraîne une réponse du répartiteur avec un paquet AUTH ContinueAuthentication. Le client peut réessayer ultérieurement. Les autres échecs d’authentification entraînent l’envoi d’un paquet DISCONNECT par le répartiteur, et la fermeture de la connexion réseau du client.

Contenu connexe