Connecter des appareils Azure IoT Edge pour créer une hiérarchie

S’applique à : IoT Edge 1.5 IoT Edge 1.4

Cet article explique comment établir une connexion approuvée entre une passerelle IoT Edge et un appareil IoT Edge en aval. Cette configuration est également appelée périphérie imbriquée.

Dans un scénario de type passerelle, un appareil IoT Edge peut être à la fois une passerelle et un appareil en aval. Il est possible de superposer plusieurs passerelles IoT Edge pour créer une hiérarchie d’appareils. Les appareils en aval (enfants) peuvent s’authentifier et envoyer ou recevoir des messages par le biais de leur appareil de passerelle (parent).

Il existe deux configurations différentes pour les appareils IoT Edge d’une hiérarchie de passerelle. Cet article aborde les deux. La première est l’appareil IoT Edge de la couche supérieure. Quand plusieurs appareils IoT Edge sont connectés les uns aux autres, un appareil dépourvu d’appareil parent qui se connecte directement à IoT Hub est considéré comme situé dans la couche supérieure. Il est chargé de gérer les demandes de tous les appareils qui se trouvent en aval. L’autre configuration s’applique à tous les appareils IoT Edge des couches inférieures de la hiérarchie. Ces appareils peuvent servir de passerelle pour d’autres appareils IoT et IoT Edge en aval, mais ils doivent également acheminer les communications via leurs propres appareils parents.

Certaines architectures réseau exigent que seul le premier appareil IoT Edge d’une hiérarchie puisse se connecter au cloud. Dans cette configuration, les appareils IoT Edge des couches inférieures de la hiérarchie ne peuvent communiquer qu’avec leur appareil de passerelle (parent) et tous les appareils en aval (enfants).

Toutes les étapes de cet article s’appuient sur la procédure Configurer un appareil IoT Edge comme passerelle transparente, qui vise à configurer un appareil IoT Edge comme passerelle pour les appareils IoT en aval. Tous les scénarios de passerelle comportent les mêmes étapes de base :

• Authentification : créez des identités IoT Hub pour tous les appareils de la hiérarchie de passerelle.
• Autorisation : configurez la relation parent/enfant dans IoT Hub de façon à autoriser les appareils en aval à se connecter à leur appareil parent de la même manière qu’à IoT Hub.
• Détection de passerelle : veillez à ce que l’appareil en aval puisse trouver son appareil parent sur le réseau local.
• Connexion sécurisée : établissez une connexion sécurisée avec des certificats approuvés qui font partie de la même chaîne.

Prérequis

• Un hub IoT gratuit ou standard.
• Au moins deux appareils IoT Edge : l’un qui deviendra l’appareil de la couche supérieure, et le ou les autres les appareils de couche inférieure. Si vous ne possédez pas d’appareils IoT Edge disponibles, vous pouvez exécuter Azure IoT Edge sur des machines virtuelles Ubuntu.
• Si vous utilisez Azure CLI pour créer et gérer des appareils, installez l’extension Azure IoT.

Création d’une hiérarchie de passerelle

Pour créer une hiérarchie de passerelle IoT Edge, définissez des relations parent/enfant des appareils IoT Edge dans le scénario. Vous pouvez définir un appareil parent lorsque vous créez une identité d’appareil, ou bien gérer le parent et les enfants d’une identité d’appareil existante.

L’étape de configuration des relations parent/enfant permet d’autoriser les appareils en aval à se connecter à leur appareil parent de la même manière qu’à IoT Hub.

Seuls les appareils IoT Edge peuvent être des appareils parents, tandis que peuvent être enfants les appareils IoT Edge et IoT. Un parent peut avoir de nombreux enfants, alors qu’un enfant ne peut avoir qu’un seul parent. Une hiérarchie de passerelle est créée en chaînant des ensembles parent/enfant de sorte que l’enfant d’un appareil constitue le parent d’un autre.

Par défaut, chaque parent peut avoir jusqu’à 100 enfants. Vous pouvez modifier cette limite en définissant la variable d’environnement MaxConnectedClients dans le module edgeHub de l’appareil parent.

Générer des certificats

Il est nécessaire qu’une chaîne de certificats cohérente soit installée sur les appareils de la même hiérarchie de passerelle pour établir une communication sécurisée entre ces appareils. Chacun des appareils de la hiérarchie (appareil IoT Edge ou appareil en aval IoT) a besoin d’une copie du même certificat d’autorité de certification racine. Chaque appareil IoT Edge de la hiérarchie utilise alors ce certificat d’autorité de certification racine comme certificat d’autorité de certification Edge.

Avec cette configuration, chacun des appareils IoT Edge en aval peut connaître l’identité de son parent en vérifiant que le module edgeHub auquel il se connecte possède un certificat de serveur signé par le certificat d’autorité de certification racine partagée.

Pour plus d’informations sur les exigences liées aux certificats IoT Edge, consultez Comprendre comment Azure IoT Edge utilise les certificats.

1. Créez ou demandez les certificats suivants :

   • Un certificat d’autorité de certification racine, à savoir le plus haut certificat partagé pour tous les appareils d’une hiérarchie de passerelle donnée. Il est installé sur tous les appareils.
   • Les certificats intermédiaires que vous souhaitez inclure dans la chaîne de certificats racines.
   • Un certificat d’autorité de certification Edge et sa clé privée, générés par les certificats racine et intermédiaires. Vous avez besoin d’un certificat d’autorité de certification Edge unique pour chacun des appareils IoT Edge de la hiérarchie de la passerelle.

   Vous pouvez soit utiliser une autorité de certification auto-signée, soit en acheter un auprès d’une autorité de certification commerciale approuvée comme Baltimore, Verisign, DigiCert ou GlobalSign.

2. Si vous n’avez pas vos propres certificats à utiliser pour le test, créez un ensemble de certificats racines et intermédiaires, puis créez des certificats d’autorité de certification Edge pour chaque appareil. Dans cet article, nous allons utiliser des certificats de test générés à l’aide de certificats d’autorité de certification de test pour les exemples et les tutoriels. Par exemple, les commandes suivantes créent un certificat d’autorité de certification racine, un certificat d’appareil parent et un certificat d’appareil enfant.

   # !!! For test only - do not use in production !!!
   
   # Create the the root CA test certificate
   ./certGen.sh create_root_and_intermediate
   
   # Create the parent (gateway) device test certificate 
   # signed by the shared root CA certificate
   ./certGen.sh create_edge_device_ca_certificate "gateway"
   
   # Create the downstream device test certificate
   # signed by the shared root CA certificate
   ./certGen.sh create_edge_device_ca_certificate "downstream"
   

   Avertissement

   N’utilisez pas les certificats créés par les scripts de test pour la production. Ils contiennent des mots de passe codés en dur et expirent par défaut au bout de 30 jours. Les certificats d’autorité de certification de test sont fournis à des fins de démonstration pour vous aider à comprendre les certificats d’autorité de certification. Utilisez vos bonnes pratiques en matière de sécurité pour créer des certificats et gérer leur durée de vie en production.

   Pour plus d’informations sur la création de certificats de test, consultez Créer des certificats de démonstration pour tester les fonctionnalités d’un appareil IoT Edge.

3. Vous devez transférer les certificats et les clés vers chaque appareil. Vous pouvez utiliser un lecteur USB, un service comme Azure Key Vault ou une fonction comme Copie de fichiers sécurisée. Choisissez l’une de ces méthodes qui correspondent le mieux à votre scénario. Copiez les fichiers vers le répertoire préféré pour les certificats et les clés. Utilisez /var/aziot/certs pour les certificats et /var/aziot/secrets pour les clés.

Pour plus d’informations sur l’installation de certificats sur un appareil, consultez Gérer des certificats sur un appareil IoT Edge.

Configurer un appareil parent

Pour configurer votre appareil parent, ouvrez un interpréteur de commandes local ou distant.

Pour permettre les connexions sécurisées, chaque appareil parent IoT Edge dans un scénario de passerelle doit être configuré avec un certificat d’autorité de certification Edge unique et une copie du certificat d’autorité de certification racine partagé par tous les appareils de la hiérarchie de la passerelle.

1. Vérifiez que vos certificats répondent aux exigences de format.

2. Transférez le certificat d’autorité de certification racine, le certificat d’autorité de certification Edge parent et la clé privée du parent sur l’appareil parent.

3. Copiez les certificats et les clés dans les répertoires appropriés. Les répertoires préférés pour les certificats d’appareil sont /var/aziot/certs pour les certificats et /var/aziot/secrets pour les clés.

   ### Copy device certificate ###
   
   # If the device certificate and keys directories don't exist, create, set ownership, and set permissions
   sudo mkdir -p /var/aziot/certs
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   sudo mkdir -p /var/aziot/secrets
   sudo chown aziotks:aziotks /var/aziot/secrets
   sudo chmod 700 /var/aziot/secrets
   
   # Copy full-chain device certificate and private key into the correct directory
   sudo cp iot-edge-device-ca-gateway-full-chain.cert.pem /var/aziot/certs
   sudo cp iot-edge-device-ca-gateway.key.pem /var/aziot/secrets
   
   ### Root certificate ###
   
   # Copy root certificate into the /certs directory
   sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs
   
   # Copy root certificate into the CA certificate directory and add .crt extension.
   # The root certificate must be in the CA certificate directory to install it in the certificate store.
   # Use the appropriate copy command for your device OS or if using EFLOW.
   
   # For Ubuntu and Debian, use /usr/local/share/ca-certificates/
   sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt
   # For EFLOW, use /etc/pki/ca-trust/source/anchors/
   sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt
   

4. Modifiez la propriété et les autorisations des certificats et des clés.

   # Give aziotcs ownership to certificates
   # Read and write for aziotcs, read-only for others
   sudo chown -R aziotcs:aziotcs /var/aziot/certs
   sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;
   
   # Give aziotks ownership to private keys
   # Read and write for aziotks, no permission for others
   sudo chown -R aziotks:aziotks /var/aziot/secrets
   sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
   
   # Verify permissions of directories and files
   sudo ls -Rla /var/aziot
   

   La sortie de liste avec une propriété et une autorisation correctes est similaire à ce qui suit :

   azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
   /var/aziot:
   total 16
   drwxr-xr-x  4 root    root    4096 Dec 14 00:16 .
   drwxr-xr-x 15 root    root    4096 Dec 14 00:15 ..
   drwxr-xr-x  2 aziotcs aziotcs 4096 Jan 14 00:31 certs
   drwx------  2 aziotks aziotks 4096 Jan 23 17:23 secrets
   
   /var/aziot/certs:
   total 20
   drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
   drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
   -rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
   -rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-gateway-full-chain.cert.pem
   
   /var/aziot/secrets:
   total 16
   drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
   drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
   -rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-gateway.key.pem
   

5. Installez le certificat d’autorité de certification racine sur l’appareil parent IoT Edge en mettant à jour le magasin de certificats sur l’appareil à l’aide de la commande spécifique à la plateforme.

   # Update the certificate store
   
   # For Ubuntu or Debian - use update-ca-certificates
   sudo update-ca-certificates
   # For EFLOW or RHEL - use update-ca-trust
   sudo update-ca-trust
   

   Pour plus d’informations sur l’utilisation de update-ca-trust dans EFLOW, consultez la gestion des certificats d’autorité de certification SSL CBL-Mariner.

La commande signale qu’un certificat a été ajouté à /etc/ssl/certs.

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Mettre à jour le fichier de configuration du parent

IoT Edge doit être déjà installé sur l’appareil. Si ce n’est pas le cas, suivez les étapes pour provisionner manuellement un seul appareil IoT Edge sur Linux.

1. Vérifiez que le fichier config /etc/aziot/config.toml existe sur l’appareil parent.

   Si le fichier config n’existe pas sur votre appareil, utilisez la commande suivante pour le créer en fonction du fichier de modèle :

   sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
   

   Vous pouvez également utiliser le fichier de modèle comme référence pour ajouter des paramètres de configuration dans cette section.

2. Ouvrez le fichier config IoT Edge avec un éditeur. Par exemple, utilisez l’éditeur nano pour ouvrir le fichier /etc/aziot/config.toml.

   sudo nano /etc/aziot/config.toml
   

3. Recherchez le paramètre hostname ou ajoutez-le au début du fichier config. Mettez à jour la valeur pour qu’elle corresponde au nom de domaine complet (FQDN) ou à l’adresse IP de l’appareil parent IoT Edge. Par exemple :

   hostname = "10.0.0.4"
   

   Pour activer la découverte de passerelle, chaque appareil de passerelle IoT Edge (parent) doit spécifier un paramètre hostname permettant à ses appareils enfants de le trouver sur le réseau local. Chaque appareil IoT Edge en aval doit spécifier un paramètre parent_hostname pour identifier son parent. Dans un scénario hiérarchique où un seul appareil IoT Edge est à la fois parent et enfant, il a besoin des deux paramètres.

   Les paramètres hostname et trust_bundle_cert doivent se trouver au début du fichier config avant les sections. Le fait d’ajouter le paramètre avant les sections définies garantit qu’il est appliqué correctement.

   Utilisez un nom d’hôte inférieur à la limite de caractères d’un nom commun de certificat de serveur, soit 64 caractères.

   Maintenez une cohérence avec le modèle de nom d’hôte dans toute la hiérarchie de passerelle. Utilisez soit des noms de domaine complets, soit des adresses IP, non les deux. Le FQDN ou l’adresse IP est obligatoire pour connecter les périphériques en aval.

   Définissez le nom d’hôte avant la création du conteneur edgeHub. Si edgeHub est en cours d’exécution, la modification du nom d’hôte dans le fichier config ne prendra effet qu’une fois le conteneur recréé. Pour plus d’informations sur la façon de vérifier que le nom d’hôte est appliqué, consultez la section Vérifier la configuration du parent.

4. Recherchez le paramètre Trust bundle cert ou ajoutez-le au début du fichier config.

   Mettez à jour le paramètre trust_bundle_cert avec l’URI du fichier pour qu’il pointe vers le certificat d’autorité de certification racine sur votre appareil. Par exemple :

   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   

5. Recherchez ou ajoutez la section Edge CA certificate dans le fichier config. Remplacez les paramètres cert (certificat) et pk (clé privée) par les chemins d’URI des fichiers de certificat à chaîne complète et de clé sur l’appareil IoT Edge parent. IoT Edge nécessite que le certificat et la clé privée soient au format texte PEM (Privacy-Enhanced Mail). Par exemple :

   [edge_ca]
   cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
   

6. Vérifiez que votre appareil IoT Edge utilise la bonne version de l’agent IoT Edge lors de son démarrage. Recherchez la section Agent Edge par défaut et définissez la valeur de l’image pour IoT Edge sur la version 1.5. Par exemple :

   [agent]
   name = "edgeAgent"
   type = "docker"
   
   [agent.config]
   image = "mcr.microsoft.com/azureiotedge-agent:1.5"
   

7. Le début de votre fichier config parent doit ressembler à l’exemple suivant.

   hostname = "10.0.0.4"
   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   
   [edge_ca]
   cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
   

8. Enregistrez et fermez le fichier config config.toml. Par exemple, si vous utilisez l’éditeur nano, sélectionnez Ctrl+O - Écrire, Entrée et Ctrl+X - Quitter.

9. Si vous avez déjà utilisé d’autres certificats pour IoT Edge, supprimez les fichiers dans les deux répertoires suivants pour que vos nouveaux certificats s’appliquent :

   • /var/lib/aziot/certd/certs
   • /var/lib/aziot/keyd/keys

10. Sélectionnez Appliquer pour appliquer vos modifications.

    sudo iotedge config apply
    

11. Recherchez les éventuelles erreurs dans la configuration.

    sudo iotedge check --verbose
    

    Remarque

    Sur un appareil nouvellement approvisionné, vous pourriez voir une erreur liée à IoT Edge Hub :

    Vérification de disponibilité de la production × : le répertoire de stockage Edge Hub est conservé sur le système de fichiers hôte - Erreur

    Impossible de vérifier l’état actuel du conteneur edgeHub

    Cette erreur est attendue sur un appareil nouvellement provisionné, car le module IoT Edge Hub n’est pas en cours d’exécution. Pour résoudre l’erreur, dans IoT Hub, définissez les modules de l’appareil et créez un déploiement. La création d’un déploiement pour l’appareil démarre les modules sur l’appareil, y compris le module IoT Edge Hub.

Vérifier la configuration du parent

Le paramètre hostname doit être un nom de domaine complet (FQDN) ou l’adresse IP de l’appareil IoT Edge, car IoT Edge utilise cette valeur dans le certificat de serveur lorsque les appareils en aval se connectent. Les valeurs doivent correspondre ; sinon, vous obtenez l’erreur relative à l’incohérence des adresses IP.

Pour vérifier le paramètre hostname, vous devez inspecter les variables d’environnement du conteneur edgeHub.

1. Listez les conteneurs IoT Edge en cours d’exécution.

   iotedge list
   

   Vérifiez que les conteneurs edgeAgent et edgeHub sont en cours d’exécution. La sortie de la commande doit ressembler à celle de l’exemple suivant :

   NAME                        STATUS           DESCRIPTION      CONFIG
   SimulatedTemperatureSensor  running          Up 5 seconds     mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0
   edgeAgent                   running          Up 17 seconds    mcr.microsoft.com/azureiotedge-agent:1.5
   edgeHub                     running          Up 6 seconds     mcr.microsoft.com/azureiotedge-hub:1.5
   

2. Inspectez le conteneur edgeHub.

   sudo docker inspect edgeHub
   

3. Dans la sortie, recherchez le paramètre EdgeDeviceHostName dans la section Env.

   "EdgeDeviceHostName=10.0.0.4"
   

4. Vérifiez que la valeur du paramètre EdgeDeviceHostName correspond au paramètre hostname de config.toml. S’il ne correspond pas, le conteneur edgeHub s’exécute lorsque vous avez modifié et appliqué la configuration. Pour mettre à jour EdgeDeviceHostName, supprimez le conteneur edgeAgent.

   sudo docker rm -f edgeAgent
   

   Les conteneurs edgeAgent et edgeHub sont recréés et démarrés en quelques minutes. Une fois le conteneur edgeHub en cours d’exécution, inspectez-le et vérifiez que le paramètre EdgeDeviceHostName correspond au fichier config.

Configurer un appareil en aval

Pour configurer votre appareil en aval, ouvrez un interpréteur de commandes local ou distant.

Pour permettre des connexions sécurisées, chacun des appareils en aval IoT Edge d’un scénario de passerelle doit être configuré avec un certificat d’autorité de certification Edge unique et une copie du certificat d’autorité de certification racine partagé par tous les appareils de la hiérarchie de la passerelle.

1. Vérifiez que vos certificats répondent aux exigences de format.

2. Transférez le certificat d’autorité de certification racine, le certificat d’autorité de certification Edge enfant et la clé privée de l’enfant vers l’appareil en aval.

3. Copiez les certificats et les clés dans les répertoires appropriés. Les répertoires préférés pour les certificats d’appareil sont /var/aziot/certs pour les certificats et /var/aziot/secrets pour les clés.

   ### Copy device certificate ###
   
   # If the device certificate and keys directories don't exist, create, set ownership, and set permissions
   sudo mkdir -p /var/aziot/certs
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   sudo mkdir -p /var/aziot/secrets
   sudo chown aziotks:aziotks /var/aziot/secrets
   sudo chmod 700 /var/aziot/secrets
   
   # Copy device full-chain certificate and private key into the correct directory
   sudo cp iot-device-downstream-full-chain.cert.pem /var/aziot/certs
   sudo cp iot-device-downstream.key.pem /var/aziot/secrets
   
   ### Root certificate ###
   
   # Copy root certificate into the /certs directory
   sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs
   
   # Copy root certificate into the CA certificate directory and add .crt extension.
   # The root certificate must be in the CA certificate directory to install it in the certificate store.
   # Use the appropriate copy command for your device OS or if using EFLOW.
   
   # For Ubuntu and Debian, use /usr/local/share/ca-certificates/
   sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt
   # For EFLOW, use /etc/pki/ca-trust/source/anchors/
   sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt
   

4. Modifiez la propriété et les autorisations des certificats et des clés.

   # Give aziotcs ownership to certificates
   # Read and write for aziotcs, read-only for others
   sudo chown -R aziotcs:aziotcs /var/aziot/certs
   sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;
   
   # Give aziotks ownership to private keys
   # Read and write for aziotks, no permission for others
   sudo chown -R aziotks:aziotks /var/aziot/secrets
   sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
   

5. Installez le certificat d’autorité de certification racine sur l’appareil en aval IoT Edge en mettant à jour le magasin de certificats sur l’appareil à l’aide de la commande spécifique à la plateforme.

   # Update the certificate store
   
   # For Ubuntu or Debian - use update-ca-certificates
   sudo update-ca-certificates
   # For EFLOW or RHEL - use update-ca-trust
   sudo update-ca-trust
   

   Pour plus d’informations sur l’utilisation de update-ca-trust dans EFLOW, consultez la gestion des certificats d’autorité de certification SSL CBL-Mariner.

La commande signale qu’un certificat a été ajouté à /etc/ssl/certs.

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Mettre à jour le fichier de configuration en aval

IoT Edge doit être déjà installé sur l’appareil. Si ce n’est pas le cas, suivez les étapes pour provisionner manuellement un seul appareil IoT Edge sur Linux.

1. Vérifiez que le fichier config /etc/aziot/config.toml existe sur l’appareil en aval.

   Si le fichier config n’existe pas sur votre appareil, utilisez la commande suivante pour le créer en fonction du fichier de modèle :

   sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
   

   Vous pouvez également utiliser le fichier de modèle comme référence pour ajouter des paramètres de configuration dans cette section.

2. Ouvrez le fichier config IoT Edge avec un éditeur. Par exemple, utilisez l’éditeur nano pour ouvrir le fichier /etc/aziot/config.toml.

   sudo nano /etc/aziot/config.toml
   

3. Recherchez le paramètre parent_hostname ou ajoutez-le au début du fichier config. Chaque appareil IoT Edge en aval doit spécifier un paramètre parent_hostname pour identifier son parent. Remplacez le paramètre parent_hostname par le nom de domaine complet ou l’adresse IP de l’appareil parent, en fonction de ce qui a été indiqué comme nom d’hôte dans le fichier config de l’appareil parent. Par exemple :

   parent_hostname = "10.0.0.4"
   

4. Recherchez le paramètre Trust bundle cert ou ajoutez-le au début du fichier config.

   Mettez à jour le paramètre trust_bundle_cert avec l’URI du fichier pour qu’il pointe vers le certificat d’autorité de certification racine sur votre appareil. Par exemple :

   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   

5. Recherchez ou ajoutez la section Edge CA certificate dans le fichier config. Remplacez les paramètres cert (certificat) et pk (clé privée) par les chemins d’URI des fichiers de certificat à chaîne complète et de clé sur l’appareil IoT Edge en aval. IoT Edge nécessite que le certificat et la clé privée soient au format texte PEM (Privacy-Enhanced Mail). Par exemple :

   [edge_ca]
   cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
   

6. Vérifiez que votre appareil IoT Edge utilise la bonne version de l’agent IoT Edge lors de son démarrage. Recherchez la section Agent Edge par défaut et définissez la valeur de l’image pour IoT Edge sur la version 1.5. Par exemple :

   [agent]
   name = "edgeAgent"
   type = "docker"
   
   [agent.config]
   image: "mcr.microsoft.com/azureiotedge-agent:1.5"
   

7. Le début de votre fichier config en aval doit ressembler à l’exemple suivant.

   parent_hostname = "10.0.0.4"
   trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
   
   [edge_ca]
   cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
   pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
   

8. Enregistrez et fermez le fichier config config.toml. Par exemple, si vous utilisez l’éditeur nano, sélectionnez Ctrl+O - Écrire, Entrée et Ctrl+X - Quitter.

9. Si vous avez déjà utilisé d’autres certificats pour IoT Edge, supprimez les fichiers dans les deux répertoires suivants pour que vos nouveaux certificats s’appliquent :

   • /var/lib/aziot/certd/certs
   • /var/lib/aziot/keyd/keys

10. Sélectionnez Appliquer pour appliquer vos modifications.

    sudo iotedge config apply
    

11. Recherchez les éventuelles erreurs dans la configuration.

    sudo iotedge check --verbose
    

    Conseil

    L’outil de vérification IoT Edge utilise un conteneur pour effectuer une partie du contrôle diagnostics. Si vous souhaitez vous servir de cet outil sur des appareils IoT Edge en aval, veillez à ce qu’ils puissent accéder à mcr.microsoft.com/azureiotedge-diagnostics:latest, ou placez l’image conteneur dans votre registre de conteneurs privé.

    Remarque

    Sur un appareil nouvellement approvisionné, vous pourriez voir une erreur liée à IoT Edge Hub :

    Vérification de disponibilité de la production × : le répertoire de stockage Edge Hub est conservé sur le système de fichiers hôte - Erreur

    Impossible de vérifier l’état actuel du conteneur edgeHub

    Cette erreur est attendue sur un appareil nouvellement provisionné, car le module IoT Edge Hub n’est pas en cours d’exécution. Pour résoudre l’erreur, dans IoT Hub, définissez les modules de l’appareil et créez un déploiement. La création d’un déploiement pour l’appareil démarre les modules sur l’appareil, y compris le module IoT Edge Hub.

Isolement réseau des appareils en aval

Dans cet article ont été indiquées les procédures visant à configurer les appareils IoT Edge comme une passerelle ou un appareil en aval, et à créer une connexion approuvée entre eux. L’appareil de passerelle gère les interactions entre l’appareil en aval et IoT Hub, notamment l’authentification et le routage des messages. Les modules déployés sur des appareils IoT Edge en aval peuvent toujours créer leurs propres connexions aux services cloud.

Certaines architectures réseau, comme celles qui suivent la norme ISA-95, cherchent à réduire le nombre de connexions Internet. Dans ces scénarios, vous pouvez configurer des appareils IoT Edge en aval sans connectivité Internet directe. Au-delà du routage des communications IoT Hub via leur appareil de passerelle, les appareils IoT Edge en aval peuvent s’appuyer sur cet appareil pour toutes les connexions au cloud.

Dans cette configuration réseau, seul l’appareil IoT Edge de la couche supérieure de la hiérarchie de passerelle doit posséder des connexions directes au cloud. Les appareils IoT Edge des couches inférieures ne peuvent communiquer qu’avec leur appareil parent et leurs appareils enfants. Les modules spéciaux sur les appareils de passerelle permettent ce scénario :

• Le module proxy d’API est requis sur toutes les passerelles IoT Edge sous lesquelles se trouve un autre appareil IoT Edge. Il doit donc se trouver sur chaque couche d’une hiérarchie de passerelle, à l’exception de la couche inférieure. Il utilise un proxy inverse nginx pour acheminer les données HTTP à travers les couches réseau sur un port unique. Il est extrêmement configurable par le biais de son jumeau de module et de ses variables d’environnement. Il peut donc être adapté en fonction des exigences de votre scénario de passerelle.

• Le module registre Docker peut être déployé sur la passerelle IoT Edge au niveau de la couche supérieure d’une hiérarchie de passerelle. Il est responsable de la récupération et de la mise en cache des images conteneur pour le compte de tous les appareils IoT Edge des couches inférieures. En dehors du déploiement de ce module au niveau de la couche supérieure, il existe d’autres possibilités : utiliser un registre local, ou charger manuellement les images conteneur sur les appareils et définir la stratégie de tirage (pull) de module sur never.

• Le module Stockage Blob Azure sur IoT Edge peut être déployé sur la passerelle IoT Edge au niveau de la couche supérieure d’une hiérarchie de passerelle. Il est responsable du chargement des objets blob pour le compte de tous les appareils IoT Edge des couches inférieures. La possibilité de charger des objets blob offre également des fonctionnalités de résolution des problèmes utiles pour les appareils IoT Edge des couches inférieures, notamment le chargement du journal de module et du Bundle de support.

Configuration réseau

Pour chacun des appareils de passerelle de la couche supérieure, les opérateurs réseau doivent effectuer plusieurs actions :

• Fournir une adresse IP statique ou un nom de domaine complet (FQDN)

• Autoriser les communications sortantes de cette adresse IP vers votre nom d’hôte Azure IoT Hub sur les ports 443 (HTTPS) et 5671 (AMQP)

• Autoriser les communications sortantes de cette adresse IP vers votre nom d’hôte Azure Container Registry sur le port 443 (HTTPS)

  Le module proxy d’API ne peut gérer les connexions qu’à un seul registre de conteneurs à la fois. Nous vous recommandons de stocker toutes les images conteneur, y compris les images publiques fournies par Microsoft Container Registry (mcr.microsoft.com), dans votre registre de conteneurs privé.

Pour chacun des appareils de passerelle des couches inférieures, les opérateurs réseau doivent effectuer plusieurs actions :

• Fournir une adresse IP statique
• Autoriser les communications sortantes de cette adresse IP vers l’adresse IP de la passerelle parente sur les ports 443 (HTTPS) et 5671 (AMQP)

Déploiement des modules sur les appareils de la couche supérieure

Il existe un ensemble de modules requis qui doivent être déployés sur l’appareil IoT Edge de la couche supérieure d’une hiérarchie de passerelle, en plus des éventuels modules de charge de travail qui s’exécutent sur l’appareil.

Le module proxy d’API a été conçu pour être personnalisé afin de gérer la plupart des scénarios de passerelle courants. Cet article donne un exemple de configuration de base des modules. Pour plus d’informations et d’exemples, consultez Configuration du module proxy d’API pour un scénario de hiérarchie de passerelle.

Déploiement de modules sur les appareils de couche inférieure

Il existe un module requis qui doit être déployé sur les appareils IoT Edge des couches inférieures d’une hiérarchie de passerelle, en plus des éventuels modules de charge de travail qui s’exécutent sur les appareils.

Acheminement des tirages (pull) d’images conteneur

Avant d’aborder le module proxy requis pour les appareils IoT Edge des hiérarchies de passerelle, il est important de comprendre comment les appareils IoT Edge des couches inférieures obtiennent leur image de module.

Si vos appareils de couche inférieure ne peuvent pas se connecter au cloud, mais que vous souhaitez qu’ils tirent (pull) les images de module comme d’habitude, vous devez configurer l’appareil de la couche supérieure de la hiérarchie de passerelle de façon à gérer ces demandes. Il doit exécuter un module registre Docker associé à votre registre de conteneurs. Configurez ensuite le module proxy d’API de sorte qu’il achemine les demandes de conteneur vers celui-ci. Ces informations sont abordées dans les sections précédentes de cet article. Dans cette configuration, les appareils de couche inférieure ne doivent pas pointer vers les registres de conteneurs cloud, mais vers le registre qui s’exécute dans la couche supérieure.

Par exemple, au lieu d’appeler mcr.microsoft.com/azureiotedge-api-proxy:1.1, les appareils de couche inférieure doivent appeler $upstream:443/azureiotedge-api-proxy:1.1.

Le paramètre $upstream pointe vers le parent d’un appareil de couche inférieure. La demande est donc acheminée à travers toutes les couches jusqu’à la couche supérieure possédant un environnement proxy qui route les demandes de conteneur au module registre. Le port :443 de cet exemple doit être remplacé par celui qu’écoute le module proxy d’API de l’appareil parent.

Le module proxy d’API ne peut acheminer les demandes que vers un module registre. Par ailleurs, un module registre ne peut être associé qu’à un seul registre de conteneurs. Il faut par conséquent que toutes les images que les appareils de couche inférieure doivent tirer (pull) soient stockées dans un même registre de conteneurs.

Si vous ne souhaitez pas que les appareils de couche inférieure effectuent des demandes de tirage (pull request) de module à travers une hiérarchie de passerelle, il existe une autre solution, qui consiste à gérer une solution de registre locale. Vous pouvez également envoyer (push) les images de module sur les appareils avant de créer des déploiements, puis définir imagePullPolicy sur never.

Démarrage de l’agent IoT Edge

L’agent IoT Edge est le premier composant de runtime à démarrer sur un appareil IoT Edge. Vous devez veiller à ce que les appareils IoT Edge en aval puissent accéder à l’image de module edgeAgent au démarrage, puis accéder aux déploiements et lancer les autres images de module.

Lorsque vous accédez au fichier config sur un appareil IoT Edge pour fournir ses informations d’authentification, ses certificats et son nom d’hôte parent, mettez également à jour l’image conteneur edgeAgent.

Si l’appareil de passerelle de la couche supérieure est configuré pour gérer les demandes d’images conteneur, remplacez mcr.microsoft.com par le nom d’hôte parent et le port d’écoute du proxy d’API. Dans le manifeste de déploiement, vous pouvez utiliser $upstream comme raccourci, mais il faut pour cela que le module edgeHub gère le routage et qu’il n’ait pas encore démarré. Par exemple :

[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image: "{Parent FQDN or IP}:443/azureiotedge-agent:1.5"

Si vous utilisez un registre de conteneurs local, ou fournissez les images conteneur manuellement sur l’appareil, mettez à jour le fichier config en conséquence.

Configuration du runtime et déploiement du module proxy

Le module proxy d’API est requis pour acheminer toutes les communications entre le cloud et tous les appareils IoT Edge en aval. Un appareil IoT Edge de la couche inférieure de la hiérarchie, dépourvu d’appareils IoT Edge en aval, n’a pas besoin de ce module.

Le module proxy d’API a été conçu pour être personnalisé afin de gérer la plupart des scénarios de passerelle courants. Cet article aborde brièvement la procédure de configuration de base des modules. Pour plus d’informations et d’exemples, consultez Configuration du module proxy d’API pour un scénario de hiérarchie de passerelle.

1. Accédez à votre IoT Hub dans le portail Azure.

2. Sélectionnez Appareils dans le menu Gestion des périphériques.

3. Sélectionnez l’appareil IoT Edge de la couche inférieure que vous configurez dans la liste.

4. Sélectionnez Définir des modules.

5. Dans la section Modules IoT Edge, sélectionnez Ajouter, puis choisissez Module IoT Edge.

6. Mettez à jour les paramètres de module suivants :

   Paramètre	Valeur
   Nom du module IoT	IoTEdgeAPIProxy
   URI d’image	mcr.microsoft.com/azureiotedge-api-proxy:latest
   Stratégie de redémarrage	always
   État souhaité	running

   Si vous souhaitez utiliser une autre version ou architecture du module proxy d’API, recherchez les images disponibles dans le Registre des artefacts Microsoft.

   1. Dans l’onglet Variables d’environnement, ajoutez une variable nommée NGINX_DEFAULT_PORT de type Texte avec une valeur de 443.

   2. Dans l’onglet Options de création de conteneur, mettez à jour les liaisons de port en indiquant le port 443.

      {
        "HostConfig": {
          "PortBindings": {
            "443/tcp": [
              {
                "HostPort": "443"
              }
            ]
          }
        }
      }
      

   Ces modifications permettent de configurer le module proxy d’API de sorte qu’il écoute le port 443. Pour éviter les collisions de liaison de port, vous devez configurer le module edgeHub de sorte qu’il n’écoute pas le port 443. Le module proxy d’API acheminera tout le trafic edgeHub sur le port 443.

7. Sélectionnez Paramètres du runtime.

8. Mettez à jour les paramètres du module edgeHub :

   1. Dans le champ Image, remplacez mcr.microsoft.com par $upstream:443.
   2. Dans le champ Options de création, supprimez la liaison du port 443, en laissant celles des ports 5671 et 8883.

   {
     "HostConfig": {
       "PortBindings": {
         "5671/tcp": [
           {
             "HostPort": "5671"
           }
         ],
         "8883/tcp": [
           {
             "HostPort": "8883"
           }
         ]
       }
     }
   }
   

9. Mettez à jour les paramètres du module edgeAgent :

   1. Dans le champ Image, remplacez mcr.microsoft.com par $upstream:443.

10. Sélectionnez Appliquer pour enregistrer les modifications apportées aux paramètres de runtime.

11. Sélectionnez Suivant : Itinéraires pour passer à l’étape suivante.

12. Pour permettre aux messages appareil-à-cloud issus des appareils en aval d’atteindre IoT Hub, ajoutez un itinéraire qui transmet tous les messages à $upstream. Le paramètre en amont pointe vers l’appareil parent dans le cas des appareils de couche inférieure. Par exemple :

    1. Nom : Route
    2. Valeur : FROM /messages/* INTO $upstream

13. Sélectionnez Vérifier + créer pour passer à l’étape finale.

14. Sélectionnez Créer pour effectuer le déploiement sur votre appareil.

Vérifier la connectivité de l’enfant au parent

1. Vérifiez la connexion TLS/SSL de l’enfant au parent en exécutant la commande openssl suivante sur l’appareil en aval. Remplacez <parent hostname> par le nom de domaine complet ou l’adresse IP du parent.

   openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
   

   La commande doit affirmer la validation réussie de la chaîne de certificats parente, comme dans l’exemple suivant :

   azureUser@child-vm:~$ openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
   Can't use SSL_get_servername
   depth=3 CN = Azure_IoT_Hub_CA_Cert_Test_Only
   verify return:1
   depth=2 CN = Azure_IoT_Hub_Intermediate_Cert_Test_Only
   verify return:1
   depth=1 CN = gateway.ca
   verify return:1
   depth=0 CN = <parent hostname>
   verify return:1
   DONE
   

   Le message « Impossible d’utiliser SSL_get_servername » peut être ignoré.

   La valeur depth=0 CN = doit correspondre au paramètre hostname spécifié dans le fichier de configuration config.toml du parent.

   Si la commande expire, des ports peuvent être bloqués entre les appareils enfants et parents. Passez en revue la configuration réseau et les paramètres des appareils.

   Avertissement

   Le fait de ne pas utiliser de certificat de chaîne complète dans la section [edge_ca] de la passerelle entraîne des erreurs de validation de certificat à partir de l’appareil en aval. Par exemple, la commande openssl s_client ... ci-dessus produit :

   Can't use SSL_get_servername
   depth=1 CN = gateway.ca
   verify error:num=20:unable to get local issuer certificate
   verify return:1
   depth=0 CN = <parent hostname>
   verify return:1
   DONE
   

   Le même problème se produit pour les appareils TLS qui se connectent à l’appareil IoT Edge en aval si le certificat d’appareil de chaîne complète n’est pas utilisé et configuré sur l’appareil en aval.

Intégrer Microsoft Defender pour IoT à la passerelle IoT Edge

Les appareils en aval peuvent être utilisés pour intégrer le micro-agent de Microsoft Defender pour IoT à la passerelle IoT Edge à l’aide d’un proxy d’appareil en aval.

En savoir plus sur le micro-agent Defender pour IoT.

Pour intégrer Microsoft Defender pour IoT à IoT Edge à l’aide d’un proxy d’appareil en aval :

1. Connectez-vous au portail Azure.

2. Accédez à IoT Hub>Your Hub>Gestion des périphériques>Appareils.

3. Sélectionnez votre appareil.

   

4. Sélectionnez le jumeau de module DefenderIotMicroAgent que vous avez créée à partir de ces instructions.

   

5. Sélectionnez le bouton pour copier la chaîne de connexion (clé primaire).

6. Collez la chaîne de connexion dans une application de modification de texte et ajoutez GatewayHostName à la chaîne. Le GatewayHostName est le nom de domaine complet ou l’adresse IP de l’appareil parent. Par exemple : HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.

7. Ouvrez un terminal sur l’appareil en aval.

8. Utilisez la commande suivante pour placer la chaîne de connexion encodée en utf-8 dans le répertoire de l’agent Defender pour le cloud dans le fichier connection_string.txt du chemin /etc/defender_iot_micro_agent/connection_string.txt :

   sudo bash -c 'echo "<connection string>" > /etc/defender_iot_micro_agent/connection_string.txt'
   

   Le fichier connection_string.txt doit maintenant se trouver dans le chemin suivant : /etc/defender_iot_micro_agent/connection_string.txt.

9. Redémarrez le service à l’aide de cette commande :

   sudo systemctl restart defender-iot-micro-agent.service 
   

10. Revenez à l’appareil.

    

11. Activez la connexion au hub IoT, puis sélectionnez l’icône en forme d’engrenage.

    

12. Sélectionnez l’appareil parent dans la liste affichée.

13. Assurez-vous que le port 8883 (MQTT) entre l’appareil en aval et l’appareil IoT Edge est ouvert.

Étapes suivantes

Guide pratique pour utiliser un appareil IoT Edge en tant que passerelle

Configuration du module proxy d’API pour un scénario de hiérarchie de passerelle