Partager via

Configurer l’authentification de MQTT broker

  • Article

Important

Opérations Azure IoT (préversion) – activé parc Azure Arc est actuellement en PRÉVERSION. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Vous devrez déployer une nouvelle installation d’Opérations Azure IoT lorsqu’une version en disponibilité générale sera publiée. 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.

MQTT broker prend en charge plusieurs méthodes d’authentification pour les clients, et vous pouvez configurer chaque écouteur pour qu’il ait son propre système d’authentification avec des ressources BrokerAuthentication.

Ressource BrokerAuthentication par défaut

Opérations Azure IoT (préversion) déploie une ressource BrokerAuthentication par défaut nommée authn liée à l’écouteur par défaut nommé listener dans l’espace de noms azure-iot-operations. Elle est configurée pour utiliser uniquement des jetons de compte de service (SAT) Kubernetes pour l’authentification. Pour l’inspecter, exécutez :

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

La sortie affiche la ressource BrokerAuthentication par défaut, avec les métadonnées supprimées pour la concision :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: ServiceAccountToken
    serviceAccountToken:
      audiences:
      - aio-mq

Pour modifier la configuration, modifiez le paramètre authenticationMethods dans cette ressource BrokerAuthentication ou créez une ressource BrokerAuthentication avec un autre nom. Ensuite, déployez-la à l’aide de kubectl apply.

Relation entre BrokerListener et BrokerAuthentication

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

  • Chaque BrokerListener peut avoir plusieurs ports. Chaque port peut être lié à une ressource BrokerAuthentication.
  • Chaque BrokerAuthentication peut prendre en charge plusieurs méthodes d’authentification à la fois

Flux d’authentification

L’ordre des méthodes d’authentification dans le tableau détermine comment MQTT broker authentifie les clients. MQTT broker tente d’authentifier les informations d’identification du client à l’aide de la première méthode spécifiée, et parcourt le tableau 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, MQTT broker 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, MQTT broker traite l’échec de la communication avec le serveur d’authentification personnalisé comme des informations d’identification non pertinentes. Ce comportement permet à MQTT broker de revenir à d’autres méthodes si le serveur personnalisé 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.
  • MQTT broker accorde ou refuse l’accès au client en fonction du résultat du flux d’authentification.

Avec plusieurs méthodes d’authentification, MQTT broker a un mécanisme de secours. Par exemple :

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      custom:
        # ...
    - method: ServiceAccountToken
      serviceAccountToken:
        # ...
    - method: x509Credentials
      x509Credentials:
        # ...

L’exemple précédent spécifie Custom et SAT. Lorsqu’un client se connecte, MQTT broker tente d’authentifier le client à l’aide des méthodes spécifiées dans l’ordre suivant : Custom, puis SAT.

  1. MQTT broker 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. Toutefois, si le serveur d’authentification personnalisé n’est pas disponible, MQTT broker revient aux méthodes spécifiées restantes, la méthode SAT étant la suivante.

  3. MQTT broker tente d’authentifier les informations d’identification en tant qu’informations d’identification SAT. Si le nom d’utilisateur MQTT commence par K8S-SAT, MQTT broker évalue le mot de passe MQTT en tant que SAT.

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

Désactiver l’authentification

Pour les tests, vous pouvez désactiver l’authentification en omettant authenticationRef dans le paramètre ports d’une ressource BrokerListener.

Configurer la méthode d'authentification

Pour en savoir plus sur chacune des options d’authentification, consultez les sections suivantes :

Certificat client X.509

Prérequis

  • MQTT broker configuré avec TLS activé.
  • Step-CLI
  • Certificats clients et chaîne de certificats d’émission dans les fichiers PEM. Si vous n’en avez pas, utilisez l’interface CLI Step pour en générer.
  • Connaissance du chiffrement par clé publique et des termes tels que l’autorité de certification racine, la clé privée et les certificats intermédiaires.

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é. Si vous importez vos propres certificats d’autorité de certification, vérifiez que le certificat client utilise le même algorithme de clé que les autorités de certification.

Importer un certificat d’autorité de certification racine du client approuvé

Un certificat d’autorité de certification racine approuvé est requis pour valider le certificat client. Pour importer un certificat racine qui peut être utilisé pour valider les certificats clients, commencez par importer le certificat PEM en tant que ConfigMap sous la clé client_ca.pem. Les certificats clients doivent enracinés dans cette autorité de certification pour que MQTT broker puisse les authentifier.

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

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
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----


BinaryData
====

Attributs de certificat

Les attributs X509 peuvent être spécifiés dans la ressource BrokerAuthentication. Par exemple, chaque client disposant d’un certificat émis par l’autorité de certification racine CN = Contoso Root CA Cert, OU = Engineering, C = US ou une autorité de certification intermédiaire CN = Contoso Intermediate CA reçoit les attributs répertoriés.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: x509Credentials
      x509Credentials:
        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

Dans cet exemple, chaque client disposant d’un certificat émis par l’autorité de certification racine CN = Contoso Root CA Cert, OU = Engineering, C = US ou une autorité de certification intermédiaire CN = Contoso Intermediate CA reçoit les attributs répertoriés. En outre, le ventilateur intelligent 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.

Des règles d’autorisation peuvent être appliquées aux clients utilisant des certificats X.509 avec ces attributs.

Activer l’authentification du client X.509

Enfin, une fois que le certificat d’autorité de certification racine du client approuvé et le mappage de certificat à attribut sont importés, activez l’authentification du client X.509 en ajoutant x509 entant qu’une des méthodes d’authentification dans le cadre d’une ressource BrokerAuthentication liée à un écouteur compatible TLS. Par exemple :

spec:
  authenticationMethods:
    - method: x509Credentials
      x509Credentials:
        trustedClientCaCert: client-ca
        attributes:
          secretName: x509-attributes

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

Un client tel que mosquitto a besoin de trois fichiers pour pouvoir se connecter à MQTT broker avec l’authentification du client TLS et X.509. Par exemple :

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

Dans l’exemple :

  • Le paramètre --cert spécifie le fichier PEM du certificat client.
  • Le paramètre --key spécifie le fichier PEM de clé privée du client.
  • Le troisième paramètre --cafile est le plus complexe : la base de données de certificats approuvée, utilisée à deux fins :
    • Lorsque le client mosquitto se connecte à MQTT broker via TLS, il valide le certificat de serveur. Il recherche les certificats racines dans la base de données pour créer une chaîne approuvée vers le certificat de serveur. Pour cette raison, le certificat racine du serveur doit être copié dans ce fichier.
    • Quand MQTT broker demande un certificat client au client mosquitto, il nécessite également une chaîne de certificats valide à envoyer au serveur. Le paramètre --cert indique à mosquitto quel certificat envoyer, mais ce n’est pas suffisant. MQTT broker ne peut pas vérifier ce certificat seul, car il a également besoin du certificat intermédiaire. Mosquitto utilise le fichier de base de données pour générer la chaîne de certificats nécessaire. Pour prendre en charge ce problème, le cafile doit contenir à la fois les certificats intermédiaires et racines.

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

Diagramme du flux d’authentification du client X.509.

Voici les étapes du flux d’authentification du client :

  1. Lorsque l’authentification du client X.509 est activée, le client se connectant doit présenter son certificat client et tous les certificats intermédiaires pour permettre à MQTT broker 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. Le certificat est requis pour l’établissement d’une liaison TLS. 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 généré.
  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 à MQTT broker.
  6. Le paquet CONNECT est routé à nouveau vers le serveur front-end.
  7. Le serveur front-end collecte toutes les informations d’identification présentées par le client jusqu’à présent, telles que les champs nom d’utilisateur et mot de passe, 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, la connexion MQTT est terminé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.

MQTT broker 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 fonctionnalités de la publication :

Lancés dans Kubernetes 1.13 et devenus le format par défaut dans la version 1.21, les jetons liés répondent à toutes les fonctionnalités limitées des jetons traditionnels, et plus encore :

  • Les jetons eux-mêmes sont plus difficiles à voler et à utiliser à mauvais escient. Ils sont limités dans le temps, limités à l’audience et limités à 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.

Le répartiteur 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, les SAT ne peuvent pas être utilisés.

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

Ajouter des attributs pour l’autorisation

Les clients qui s’authentifient via SAT peuvent éventuellement faire annoter leurs SAT avec des attributs à utiliser avec des stratégies d’autorisation personnalisées. Pour plus d’informations, consultez Autoriser les clients qui utilisent des jetons de compte de service Kubernetes.

Activer l’authentification par jeton de compte de service (SAT)

Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier ServiceAccountToken comme méthode d’authentification valide. Le 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.

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountToken:
        audiences:
        - aio-mq
        -  my-audience

Appliquez vos modifications avec kubectl apply. Patientez quelques minutes pour que les modifications soient prises en compte.

Tester l’authentification SAT

L’authentification SAT doit être utilisée à partir d’un client dans le même cluster que MQTT broker. Seuls les champs d’authentification améliorée sont autorisés. Définissez la méthode d’authentification sur K8S-SAT et les données d’authentification sur le jeton.

La commande suivante spécifie un pod qui a le client mosquitto et monte le SAT créé dans les étapes précédentes dans le pod.

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
spec:
  serviceAccountName: mqtt-client
  containers:
  - image: efrecon/mqtt-client
    name: mqtt-client
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: mqtt-client-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: mqtt-client-token
    projected:
      sources:
      - serviceAccountToken:
          path: mqtt-client-token
          audience: my-audience
          expirationSeconds: 86400

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

Une fois le pod créé, démarrez un interpréteur de commandes dans le pod :

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

Dans l’interpréteur de commandes du pod, exécutez la commande suivante pour publier un message sur le répartiteur :

mosquitto_pub --host aio-mq-dmqtt-frontend --port 8883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/mq-sat)

Le résultat doit être semblable à ce qui suit :

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

Le client mosquitto utilise le jeton de compte de service monté sur /var/run/secrets/tokens/mq-sat pour s’authentifier auprès du répartiteur. Le jeton est valide pendant 24 heures. Le client utilise également le certificat d’autorité de certification racine par défaut monté sur /var/run/certs/ca.crt pour vérifier la chaîne de certificats TLS du répartiteur.

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/mqtt-client-token. Lorsque vous effectuez une nouvelle connexion, le client 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 à MQTT broker et que l’authentification personnalisée est activé, MQTT broker délègue la vérification des informations d’identification du client à un serveur d’authentification personnalisé avec une requête HTTP accompagnée de toutes les informations d’identification présentées par le client. Le serveur d’authentification personnalisé répond par l’approbation ou le refus du client avec les attributs pour l’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 MQTT broker.

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

API

L’API entre MQTT broker 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

MQTT broker 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 MQTT broker 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 MQTT broker 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 MQTT broker présente un certificat client pour s’authentifier lui-même.

Activer l’authentification personnalisée pour un écouteur

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

Cet exemple montre tous les paramètres possibles. Les paramètres exacts requis dépendent des exigences de chaque serveur personnalisé.

spec:
  authenticationMethods:
    - custom:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Trusted CA certificate for validating custom authentication server certificate.
        # Required unless the server certificate is publicly-rooted.
        caCert: 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:
            secretName: 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

Déconnexion du client après l’expiration des informations d’identification

MQTT broker 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 MQTT broker, 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 le répartiteur 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.

Les clients SAT envoient un client AUTH avec les champs method: K8S-SAT, 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, et le répartiteur répond avec un paquet Success AUTH. En cas d’échec d’authentification dû à des problèmes temporaires, le répartiteur répond avec un paquet ContinueAuthentication AUTH. C’est le cas par exemple en cas d’indisponibilité du serveur d’authentification personnalisée. 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