Partager via

Tester la connectivité à Azure IoT MQ (préversion) avec des clients MQTT

  • 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.

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é à Azure IoT MQ (préversion) avec des clients MQTT hors environnement de production.

Par défaut, Azure IoT MQ (préversion) :

  • Déploie un écouteur compatible TLS sur le port 8883 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 déployez des opérations IoT. Utilisez les options suivantes pour tester la connectivité à IoT MQ 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 IoT MQ BrokerListener's namespace
  # Otherwise use the long hostname: aio-mq-dmqtt-frontend.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-mq # 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-mq-dmqtt-frontend --port 8883 --message "hello" --topic "world" --username '$sat' --pw $(cat /var/run/secrets/tokens/mq-sat) --debug --cafile /var/run/certs/ca.crt

    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-mq-dmqtt-frontend --port 8883 --topic "world" --username '$sat' --pw $(cat /var/run/secrets/tokens/mq-sat) --debug --cafile /var/run/certs/ca.crt

    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. Vous pouvez également utiliser mqttui pour vous connecter au répartiteur à l’aide du jeton de compte de service. L’indicateur --insecure est requis, car mqttui ne prend pas en charge la vérification de la chaîne de certificats TLS avec un certificat d’autorité de certification racine personnalisé.

    Attention

    L’utilisation de --insecure n’est pas recommandée pour les scénarios de production. Utilisez-le uniquement à des fins de test ou de développement.

    mqttui --broker mqtts://aio-mq-dmqtt-frontend:8883 --username '$sat' --password $(cat /var/run/secrets/tokens/mq-sat) --insecure

  7. 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.

S’authentifier auprès du répartiteur

Par défaut, IoT MQ accepte uniquement 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 comme X.509 ou le nom d’utilisateur et le mot de passe. 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 IoT MQ à un port sur le système hôte (localhost). Vous devez utiliser cette approche, car elle facilite l’accès des clients sur le même hôte à IoT MQ.

Par exemple, pour créer un cluster K3d avec le mappage du port MQTT MQ par défaut d’IoT 8883 à localhost :8883 :

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

Mais pour que cette méthode fonctionne avec IoT MQ, 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: 8883
      targetPort: 8883
    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-mq-dmqtt-frontend --namespace azure-iot-operations

    La sortie doit ressembler à ce qui suit :

    NAME                    TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
aio-mq-dmqtt-frontend   LoadBalancer   10.43.107.11   XXX.XX.X.X    8883:30366/TCP   14h

  3. Vous pouvez utiliser l’adresse IP externe pour vous connecter à IoT MQ 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 à IoT MQ à partir de 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 à IoT MQ. 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 requis, 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-mq-dmqtt-frontend) et les adresses IP affectées, et non localhost.

N’exposez jamais le port IoT MQ à 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 répartiteur, transférez le port d’écoute du répartiteur 8883 à l’hôte.

    kubectl port-forward --namespace azure-iot-operations service/aio-mq-dmqtt-frontend 8883:mqtts-8883

  2. Utilisez 127.0.0.1 pour vous connecter au répartiteur au port 8883 avec la même configuration d’authentification et TLS que l’exemple sans transfert de port.

Le transfert de port est également utile pour tester IoT MQ localement sur votre ordinateur de développement sans avoir à modifier la configuration du répartiteur.

Pour plus d’informations, consultez Utiliser le transfert de port pour accéder aux applications dans un cluster pour minikube et Exposer des services Kubernetes à des appareils externes pour Azure Kubernetes Services Edge Essentials.

Aucune authentification TLS et aucune authentification

La raison pour laquelle IoT MQ utilise l’authentification tls et les comptes de service par défaut est de fournir 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. Exposer IoT MQ à Internet sans authentification et TLS peut entraîner des attaques DDOS non autorisées.

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: mq.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

Contenu connexe