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

  • Article

S’applique à :Coche IoT Edge 1.4 IoT Edge 1.4

Important

IoT Edge 1.4 est la version prise en charge. Si vous utilisez une version antérieure, consultez l’article Mettre à jour IoT Edge.

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

Conseil

Cet article vous donne la procédure détaillée et les options permettant de créer une hiérarchie de passerelle adaptée à votre scénario. Pour un tutoriel guidé, consultez Création d’une hiérarchie d’appareils IoT Edge à l’aide de passerelles.

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.

Sur le Portail Azure, vous pouvez gérer la relation parent/enfant lorsque vous créez de nouvelles identités d’appareil ou en modifiant des appareils existants.

Lors de la création d’un appareil IoT Edge, il est possible de choisir des appareils parents et enfants dans la liste des appareils IoT Edge existants dans ce hub.

  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 Ajouter un appareil, puis cochez la case Appareil IoT Edge.
  4. En plus de l’ID de l’appareil et des paramètres d’authentification, vous pouvez Définir un appareil parent ou Choisir des appareils enfants.
  5. Choisissez le ou les appareils parent et enfants.

Vous pouvez également créer ou gérer les relations parent/enfant d’appareils existants.

  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 que vous souhaitez gérer dans la liste.
  4. Sélectionnez Définir un appareil parent (icône d’engrenage) ou Gérer des appareils enfants.
  5. Ajoutez ou supprimez des appareils parent ou enfants.

Remarque

Si vous souhaitez établir des relations parent-enfant par programme, vous pouvez utiliser le Kit de développement logiciel IOT Hub servic C#, Java ou Node.js.

Voici un exemple d’affectation d’un appareil enfant avec le SDK C#. La tâche RegistryManager_AddAndRemoveDeviceWithScope() montre comment créer par programmation une hiérarchie à trois couches. Un appareil IoT Edge se trouve dans la couche 1 en tant que parent. Un autre appareil IoT Edge se trouve dans la couche 2, qui sert à la fois d’enfant et de parent. Enfin, un appareil IoT se trouve dans la couche 3, en tant qu’appareil enfant de la couche enfant la plus basse.

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 comme racine de son certificat d’autorité de certification d’appareil.

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.

Illustration de la chaîne de certificats émise par l’AC racine sur la passerelle et l’appareil en aval.

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 d’appareil et sa clé privée, générés par les certificats racine et intermédiaires. Un certificat d’autorité de certification d’appareil unique est nécessaire pour chacun des appareils IoT Edge de la hiérarchie de 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 d’appareil IoT 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.

La condition pour permettre les connexions sécurisées est que chacun des appareils parents IoT Edge d’un scénario de passerelle soit configuré avec un seul certificat d’autorité de certification d’appareil et une copie du certificat d’autorité de certification racine partagé par tous les appareils de la hiérarchie de 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 de l’appareil parent et la clé privée du parent vers 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.4. Par exemple :

    [agent.config]
image = "mcr.microsoft.com/azureiotedge-agent:1.4"

  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.4
edgeHub                     running          Up 6 seconds     mcr.microsoft.com/azureiotedge-hub:1.4

  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.

La condition pour permettre les connexions sécurisées est que chacun des appareils en aval IoT Edge d’un scénario de passerelle soit configuré avec un seul certificat d’autorité de certification d’appareil et une copie du certificat d’autorité de certification racine partagé par tous les appareils de la hiérarchie de 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 d’appareil enfant et la clé privée 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.4. Par exemple :

    [agent.config]
image: "mcr.microsoft.com/azureiotedge-agent:1.4"

  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.

  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 supé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 Place de marché.

  6. Recherchez et sélectionnez le module Proxy d’API IoT Edge.

  7. Sélectionnez le nom du module proxy d’API dans la liste des modules déployés et mettez à jour les paramètres de module suivants :

    1. Dans l’onglet Variables d’environnement, remplacez la valeur de NGINX_DEFAULT_PORT par 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.

  8. Sélectionnez Paramètres de runtime et recherchez les options de création du module edgeHub. 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. Sélectionnez Enregistrer pour enregistrer les modifications apportées aux paramètres de runtime.

  10. Sélectionnez à nouveau Ajouter, puis choisissez Module IoT Edge.

  11. Indiquez les valeurs suivantes pour ajouter le module registre Docker à votre déploiement :

    1. Nom du module IoT Edge : registry.

    2. Dans l’onglet Paramètres du module, URI de l’image : registry:latest.

    3. Dans l’onglet Variables d’environnement, ajoutez les variables d’environnement suivantes :

      • Nom: REGISTRY_PROXY_REMOTEURLValeur: L'URL du registre de conteneurs auquel vous souhaitez que ce module de registre soit associé. Par exemple : https://myregistry.azurecr.

        Le module registre ne peut être associé qu’à un seul registre de conteneurs. Nous vous recommandons donc de conserver toutes les images conteneur dans un même registre de conteneurs privé.

      • Nom: REGISTRY_PROXY_USERNAMEValeur: Nom d'utilisateur pour s'authentifier auprès du registre des conteneurs.

      • Nom: REGISTRY_PROXY_PASSWORDValeur: Mot de passe pour s'authentifier auprès du registre des conteneurs.

    4. Dans l’onglet Options de création de conteneur, collez :

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

  12. Sélectionnez Ajouter pour ajouter le module au déploiement.

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

  14. Pour permettre aux messages appareil-à-cloud issus des appareils en aval d’atteindre IoT Hub, ajoutez un itinéraire qui transmet tous les messages à IoT Hub. Par exemple :

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

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

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

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

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 Place de marché.

  6. Recherchez et sélectionnez le module Proxy d’API IoT Edge.

  7. Sélectionnez le nom du module proxy d’API dans la liste des modules déployés et mettez à jour les paramètres de module suivants :

    1. Dans l’onglet Paramètres du module, mettez à jour la valeur URI d’image. Remplacez mcr.microsoft.com par $upstream:443.

    2. Dans l’onglet Variables d’environnement, remplacez la valeur de NGINX_DEFAULT_PORT par 443.

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

  8. Sélectionnez Paramètres du runtime.

  9. 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"
        }
      ]
    }
  }
}

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

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

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

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

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

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

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

    Capture d’écran montrant l’emplacement de votre appareil pour la sélection.

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

    Capture d’écran montrant l’emplacement de DefenderIotMicroAgent.

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

    Capture d’écran montrant comment revenir à votre appareil.

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

    Capture d’écran montrant ce qu’il faut sélectionner pour définir un appareil parent.

  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