Partager via


Tester la connectivité à l’Agent MQTT avec des clients MQTT

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.

Cet article montre différentes façons de tester la connectivité à l’Agent MQTT avec des clients MQTT hors environnement de production.

Par défaut, l’Agent MQTT :

  • Déploie un Écouteur compatible avec TLS sur le port 18883 avec ClusterIp comme type de service. ClusterIp signifie que le répartiteur est accessible uniquement à partir du cluster Kubernetes. Pour accéder au répartiteur à partir de l’extérieur du cluster, vous devez configurer un service de type LoadBalancer ou NodePort.

  • Accepte les comptes de service Kubernetes pour l’authentification pour les connexions à partir du cluster. Pour vous connecter à partir de l’extérieur du cluster, vous devez configurer une autre méthode d’authentification.

Attention

Pour les scénarios de production, vous devez utiliser le protocole TLS et l’authentification des comptes de service pour sécuriser votre solution IoT. Pour plus d’informations, consultez l’article suivant :

Avant de commencer, installez ou configurez des opérations IoT. Utilisez les options suivantes pour tester la connectivité à l’Agent MQTT avec des clients MQTT hors environnement de production.

Se connecter à partir d’un pod au sein du cluster avec la configuration par défaut

La première option consiste à se connecter à partir du cluster. Cette option utilise la configuration par défaut et ne nécessite aucune mise à jour supplémentaire. Les exemples suivants montrent comment se connecter depuis l'intérieur du cluster en utilisant Alpine Linux et un client MQTT couramment utilisé, en utilisant le compte de service et le certificat racine par défaut de l'autorité de certification.

  1. Créez un fichier nommé client.yaml avec la configuration suivante :

    apiVersion: v1
    kind: Pod
    metadata:
      name: mqtt-client
      # Namespace must match MQTT broker BrokerListener's namespace
      # Otherwise use the long hostname: aio-broker.azure-iot-operations.svc.cluster.local
      namespace: azure-iot-operations
    spec:
      # Use the "mqtt-client" service account which comes with default deployment
      # Otherwise create it with `kubectl create serviceaccount mqtt-client -n azure-iot-operations`
      serviceAccountName: mqtt-client
      containers:
        # Mosquitto and mqttui on Alpine
      - image: alpine
        name: mqtt-client
        command: ["sh", "-c"]
        args: ["apk add mosquitto-clients mqttui && sleep infinity"]
        volumeMounts:
        - name: mq-sat
          mountPath: /var/run/secrets/tokens
        - name: trust-bundle
          mountPath: /var/run/certs
      volumes:
      - name: mq-sat
        projected:
          sources:
          - serviceAccountToken:
              path: mq-sat
              audience: aio-internal # Must match audience in BrokerAuthentication
              expirationSeconds: 86400
      - name: trust-bundle
        configMap:
          name: aio-ca-trust-bundle-test-only # Default root CA cert
    
  2. Utilisez kubectl apply -f client.yaml pour déployer la configuration. Le démarrage ne doit prendre que quelques secondes.

  3. Une fois le pod en cours d’exécution, utilisez kubectl exec pour exécuter des commandes à l’intérieur du pod.

    Par exemple, pour publier un message sur le répartiteur, ouvrez un interpréteur de commandes à l’intérieur du pod :

    kubectl exec --stdin --tty mqtt-client --namespace azure-iot-operations -- sh
    
  4. 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-broker --port 18883 --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.

  5. Pour vous abonner à la rubrique, exécutez la commande suivante :

    mosquitto_sub --host aio-broker --port 18883 --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 SUBSCRIBE (Mid: 1, Topic: world, QoS: 0, Options: 0x00)
    Client (null) received SUBACK
    Subscribed (mid: 1): 0
    

    Le client mosquitto utilise le même jeton de compte de service et le certificat d’autorité de certification racine pour s’authentifier auprès du répartiteur et s’abonner à la rubrique.

  6. Pour supprimer le pod, exécutez kubectl delete pod mqtt-client -n azure-iot-operations.

Connecter les clients de l’extérieur du cluster au port TLS par défaut

Chaîne d’approbation TLS

Étant donné que le répartiteur utilise TLS, le client doit approuver la chaîne de certificats TLS du répartiteur. Vous devez configurer le client pour faire confiance au certificat d’autorité de certification racine utilisé par le répartiteur.

Pour utiliser le certificat d’autorité de certification racine par défaut, téléchargez-le à partir de la ConfigMap aio-ca-trust-bundle-test-only :

kubectl get configmap aio-ca-trust-bundle-test-only -n azure-iot-operations -o jsonpath='{.data.ca\.crt}' > ca.crt

Utilisez le fichier ca.crt téléchargé pour configurer votre client pour qu’il fasse confiance à la chaîne de certificats TLS du répartiteur.

Si vous vous connectez au répartiteur à partir d’un autre espace de noms, vous devez utiliser le nom d’hôte aio-broker.azure-iot-operations.svc.cluster.local de service complet. Vous devez également ajouter le nom DNS au certificat de serveur en incluant un champ DNS SAN (autre nom de l’objet) à la ressource BrokerListener. Pour plus d’informations, consultez Configurer les paramètres du certificat de serveur.

S’authentifier auprès du répartiteur

Par défaut, l’Agent MQTT accepte uniquement les comptes de service Kubernetes pour l’authentification pour les connexions à partir du cluster. Pour vous connecter depuis l’extérieur du cluster, vous devez configurer une autre méthode d’authentification comme X.509. Pour plus d’informations, consultez Configurer l’authentification client.

Désactiver l’authentification est uniquement à des fins de test

Pour désactiver l’authentification à des fins de test, modifiez la ressource BrokerListener et définissez le champ authenticationEnabled sur false :

Attention

La désactivation de l’authentification doit uniquement être utilisée à des fins de test avec un cluster de test qui n’est pas accessible à partir d’Internet.

kubectl patch brokerlistener listener -n azure-iot-operations --type='json' -p='[{"op": "replace", "path": "/spec/authenticationEnabled", "value": false}]'

Connectivité des ports

Certaines distributions Kubernetes peuvent exposer l’Agent MQTT à un port sur le système hôte (localhost). Préférez cette approche parce qu’elle permet aux clients sur le même hôte d’accéder plus facilement à l’Agent MQTT.

Par exemple, pour créer un cluster K3d avec le mappage du port MQTT par défaut de l’Agent MQTT 18883 à localhost:18883 :

k3d cluster create --port '18883:18883@loadbalancer'

Mais pour que cette méthode fonctionne avec l’Agent MQTT, vous devez la configurer pour qu’elle utilise un équilibreur de charge au lieu d’une adresse IP de cluster. Il existe deux façons de procéder : créer un équilibreur de charge ou corriger le type de service de ressource BrokerListener par défaut existant pour en faire l’équilibreur de charge.

Option 1 : Créer un équilibreur de charge

  1. Créez un fichier nommé loadbalancer.yaml avec la configuration suivante :

    apiVersion: v1
    kind: Service
    metadata:
        name: iotmq-public-svc
    spec:
        type: LoadBalancer
        ports:
        - name: mqtt1
          port: 18883
          targetPort: 18883
        selector:
          app: broker
          app.kubernetes.io/instance: broker
          app.kubernetes.io/managed-by: dmqtt-operator
          app.kubernetes.io/name: dmqtt
          tier: frontend
    
  2. Appliquez la configuration pour créer un service d’équilibreur de charge :

    kubectl apply -f loadbalancer.yaml
    

Option 2 : Corriger l’équilibreur de charge par défaut

  1. Modifiez la ressource BrokerListener et remplacez le champ serviceType par loadBalancer.

    kubectl patch brokerlistener listener --namespace azure-iot-operations --type='json' --patch='[{"op": "replace", "path": "/spec/serviceType", "value": "loadBalancer"}]'
    
  2. Attendez que le service soit mis à jour.

    kubectl get service aio-broker --namespace azure-iot-operations
    

    La sortie doit ressembler à ce qui suit :

    NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
    aio-broker   LoadBalancer   10.43.107.11   XXX.XX.X.X    18883:30366/TCP   14h
    
  3. Vous pouvez utiliser l’adresse IP externe pour vous connecter à l’Agent MQTT via Internet. Assurez-vous d’utiliser l’adresse IP externe au lieu de localhost.

    mosquitto_pub --qos 1 --debug -h XXX.XX.X.X --message hello --topic world --username client1 --pw password --cafile ca.crt
    

Conseil

Vous pouvez utiliser l’adresse IP externe pour vous connecter à l’Agent MQTT depuis l’extérieur du cluster. Si vous avez utilisé la commande K3d avec l’option de transfert de port, vous pouvez utiliser localhost pour vous connecter à l’Agent MQTT. Par exemple, pour vous connecter au client mosquitto :

mosquitto_pub --qos 1 --debug -h localhost --message hello --topic world --username client1 --pw password --cafile ca.crt --insecure

Dans cet exemple, le client mosquitto utilise le nom d’utilisateur et le mot de passe pour s’authentifier auprès du répartiteur, ainsi que le certificat d’autorité de certification racine pour vérifier la chaîne de certificats TLS du répartiteur. Ici, l’indicateur --insecure est nécessaire, car le certificat TLS par défaut émis à l’équilibreur de charge est valide uniquement pour le nom de service par défaut de l’équilibreur de charge (aio-broker) et les adresses IP affectées, et non localhost.

N’exposez jamais le port de l’Agent MQTT à Internet sans authentification et TLS. Cela est dangereux et peut entraîner un accès non autorisé à vos appareils IoT et amener le trafic non sollicité vers votre cluster.

Pour plus d’informations sur l’ajout de localhost à l’autre nom d’objet (SAN) du certificat pour éviter d’utiliser l’indicateur non sécurisé, consultez Configurer les paramètres de certificat de serveur.

Utiliser le transfert de port

Avec minikube, kindet d’autres systèmes d’émulation de cluster, une adresse IP externe peut ne pas être automatiquement affectée. Par exemple, il peut s’afficher en tant qu’état en attente.

  1. Pour accéder au broker, transférez le port d’écoute du broker 18883 à l’hôte.

    kubectl port-forward --namespace azure-iot-operations service/aio-broker 18883:mqtts-18883
    
  2. Utilisez 127.0.0.1 pour vous connecter au broker au port 18883 avec la même configuration d’authentification et TLS que l’exemple sans réacheminement de port.

Le transfert de port est également utile pour tester l’Agent MQTT localement sur votre ordinateur de développement sans avoir à modifier la configuration de l’agent. Pour plus d’informations sur minikube, consultez Utiliser le transfert de port pour accéder aux applications dans un cluster

Transfert de port sur AKS Edge Essentials

Pour Azure Kubernetes Services Edge Essentials, vous devez effectuer quelques étapes supplémentaires. Pour plus d’informations sur le transfert de port, consultez Exposer les services Kubernetes aux appareils externes.

  1. Supposons que le service de l’agent est exposé à une adresse IP externe à l’aide d’un équilibreur de charge. Par exemple, si vous avez patché l’équilibreur de charge par défaut aio-broker, obtenez l’adresse IP externe du service.

    kubectl get service aio-broker --namespace azure-iot-operations
    

    La sortie doit ressembler à ce qui suit :

    NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
    aio-broker   LoadBalancer   10.43.107.11   192.168.0.4   18883:30366/TCP   14h
    
  2. Configurez le transfert de port vers le service aio-broker sur l’adresse IP externe 192.168.0.4 et le port 18883 :

    netsh interface portproxy add v4tov4 listenport=18883 connectport=18883 connectaddress=192.168.0.4
    
  3. Ouvrez le port sur le pare-feu pour autoriser le trafic vers le service de l’agent :

    New-NetFirewallRule -DisplayName "AIO MQTT Broker" -Direction Inbound -Protocol TCP -LocalPort 18883 -Action Allow
    
  4. Utilisez l’adresse IP publique de l’hôte pour vous connecter à l’agent MQTT.

Aucune authentification TLS et aucune authentification

L’Agent MQTT utilise l’authentification TLS et les comptes de service par défaut parce qu’il fournit une expérience sécurisée par défaut qui réduit l’exposition accidentelle de votre solution IoT aux attaquants. Vous ne devez pas désactiver TLS et l’authentification en production.

Attention

N’utilisez pas en production. L’exposition de l’Agent MQTT à Internet sans authentification et TLS peut entraîner des accès non autorisés et même des attaques DDOS.

Si vous comprenez les risques et devez utiliser un port non sécurisé dans un environnement bien contrôlé, vous pouvez désactiver TLS et l’authentification à des fins de test à des fins de test :

  1. Créez une ressource BrokerListener sans paramètres TLS :

    apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
    kind: BrokerListener
    metadata:
      name: non-tls-listener
      namespace: azure-iot-operations
    spec:
      brokerRef: broker
      serviceType: loadBalancer
      serviceName: my-unique-service-name
      authenticationEnabled: false
      authorizationEnabled: false
      port: 1883
    

    Les champs authenticationEnabled et authorizationEnabled sont définis sur false pour désactiver l’authentification et l’autorisation. Le champ port est défini sur 1883 pour utiliser le port MQTT commun.

  2. Attendez que le service soit mis à jour.

    kubectl get service my-unique-service-name --namespace azure-iot-operations
    

    La sortie doit ressembler à ce qui suit :

    NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
    my-unique-service-name   LoadBalancer   10.43.144.182   XXX.XX.X.X    1883:31001/TCP   5m11s
    

    Le nouveau port 1883 est disponible.

  3. Utilisez le client mosquitto pour vous connecter au répartiteur :

    mosquitto_pub --qos 1 --debug -h localhost --message hello --topic world
    

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

    Client mosq-7JGM4INbc5N1RaRxbW sending CONNECT
    Client mosq-7JGM4INbc5N1RaRxbW received CONNACK (0)
    Client mosq-7JGM4INbc5N1RaRxbW sending PUBLISH (d0, q1, r0, m1, 'world', ... (5 bytes))
    Client mosq-7JGM4INbc5N1RaRxbW received PUBACK (Mid: 1, RC:0)
    Client mosq-7JGM4INbc5N1RaRxbW sending DISCONNECT