Connettere dispositivi Azure IoT Edge per creare una gerarchia

Si applica a: IoT Edge 1.5 IoT Edge 1.4

Questo articolo fornisce la procedura per la creazione di una connessione attendibile tra un gateway IoT Edge e un dispositivo IoT Edge downstream. Questa configurazione è nota anche come edge annidato.

In uno scenario gateway, un dispositivo IoT Edge può essere sia un gateway che un dispositivo downstream. È possibile creare più livelli di gateway IoT Edge per creare una gerarchia di dispositivi. I dispositivi downstream (elementi figlio) possono autenticare e inviare o ricevere messaggi tramite il relativo dispositivo gateway (elemento padre).

Esistono due configurazioni diverse per i dispositivi IoT Edge in una gerarchia di gateway e questo articolo riguarda entrambi. Il primo è il dispositivo IoT Edge di livello superiore. Quando più dispositivi IoT Edge si connettono tra loro, qualunque dispositivo che non ha un dispositivo padre ma si connette direttamente all’hub IoT viene considerato nel livello superiore. Questo dispositivo effettua la gestione delle richieste da tutti i dispositivi sottostanti. L'altra configurazione si applica a qualunque dispositivo IoT Edge in un livello inferiore della gerarchia. Questi dispositivi possono essere un gateway per altri dispositivi IoT e IoT Edge downstream, ma devono anche instradare tutte le comunicazioni tramite i propri dispositivi padre.

Alcune architetture di rete richiedono che solo il dispositivo IoT Edge principale in una gerarchia possa connettersi al cloud. In questa configurazione, tutti i dispositivi IoT Edge in livelli inferiori di una gerarchia possono comunicare solo con il relativo dispositivo gateway (elemento padre) e qualunque dispositivo downstream (elemento figlio).

Tutti i passaggi descritti in questo articolo si basano sulla Configurazione di un dispositivo IoT Edge per in modo che funga da gateway trasparente, che configura un dispositivo IoT Edge come gateway per i dispositivi IoT downstream. Gli stessi passaggi base si applicano a tutti gli scenari gateway:

• Autenticazione: creare identità hub IoT per tutti i dispositivi nella gerarchia di gateway.
• Autorizzazione: configurare la relazione padre/figlio nell’hub IoT per autorizzare i dispositivi downstream a connettersi al relativo dispositivo padre come se si connettesse all’hub IoT.
• Individuazione gateway: accertarsi che il dispositivo downstream possa trovare il dispositivo padre nella rete locale.
• Connessione sicura: stabilire una connessione sicura con certificati attendibili che fanno parte della stessa catena.

Prerequisiti

• Un hub IoT gratuito o standard.
• Almeno due dispositivi IoT Edge, uno come dispositivo di livello superiore e uno o più dispositivi di livello inferiore. Se non sono disponibili dispositivi IoT Edge, è possibile Eseguire Azure IoT Edge in macchine virtuali Ubuntu.
• Se si usa l’interfaccia della riga di comando di Azure per creare e gestire i dispositivi, installare l’estensione Azure IoT.

Creare una gerarchia di gateway

È possibile creare una gerarchia di gateway IoT Edge definendo relazioni padre/figlio per i dispositivi IoT Edge nello scenario. È possibile impostare un dispositivo padre quando si crea una nuova identità del dispositivo oppure è possibile gestire l'identità dell’elemento padre e degli elementi figli di un'identità del dispositivo esistente.

Il passaggio di configurazione della relazione padre/figlio autorizza i dispositivi downstream a connettersi al relativo dispositivo padre come se si connettesse all’hub IoT.

Solo i dispositivi IoT Edge possono essere dispositivi padre, ma sia i dispositivi IoT Edge che i dispositivi IoT possono essere figli. Un elemento padre può avere molti figli, ma un figlio può avere un solo elemento padre. Una gerarchia di gateway viene creata concatenando i set padre/figlio in modo che il figlio di un dispositivo sia l'elemento padre di un altro.

Per impostazione predefinita, un padre può avere fino a 100 elementi figlio. È possibile modificare questo limite impostando la variabile di ambiente MaxConnectedClients nel modulo edgeHub del dispositivo padre.

Generare i certificati

Per stabilire una comunicazione sicura tra loro, è necessario installare una catena coerente di certificati tra dispositivi nella stessa gerarchia di gateway. Ogni dispositivo nella gerarchia, che si tratti di un dispositivo IoT Edge o di un dispositivo downstream IoT, richiede una copia dello stesso certificato CA radice. Ogni dispositivo IoT Edge nella gerarchia usa quindi tale certificato CA radice come radice per il certificato CA Edge.

Con questa configurazione, ogni dispositivo IoT Edge downstream può verificare l'identità del relativo elemento padre verificando che edgeHub a cui si connette abbia un certificato server firmato dal certificato CA radice condiviso.

Per altre informazioni sui requisiti del certificato IoT Edge, vedere Informazioni su come Azure IoT Edge usa i certificati.

1. Creare o richiedere i certificati seguenti:

   • Un certificato CA radice, che è il certificato condiviso superiore per tutti i dispositivi in una determinata gerarchia di gateway. Questo certificato è installato su tutti i dispositivi.
   • Qualunque certificato intermedio da includere nella catena di certificati radice.
   • Un certificato della CA Edge e la relativa chiave privata, generati dai certificati radice e intermedi. È necessario un certificato CA Edge univoco per ogni dispositivo IoT Edge nella gerarchia del gateway.

   È possibile usare un'autorità di certificazione autofirmata o acquistarne una da un'autorità di certificazione commerciale attendibile, come Baltimore, Verisign, Digicert o GlobalSign.

2. Se non si hanno certificati personalizzati da usare per il test, creare un set di certificati radice e intermedi, quindi creare certificati CA Edge per ogni dispositivo. In questo articolo si useranno certificati di test generati usando certificati CA di test per esempi ed esercitazioni. Ad esempio, i comandi seguenti creano un certificato CA radice, un certificato del dispositivo padre e un certificato del dispositivo figlio.

   # !!! 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"
   

   Avviso

   Non usare certificati creati dagli script di test per la produzione. Questi contengono password hardcoded e per impostazione predefinita scadono dopo 30 giorni. I certificati CA di test vengono forniti a scopo dimostrativo per facilitare la comprensione dei certificati CA. Usare le proprie procedure consigliate per la creazione della certificazione e la gestione della durata in produzione.

   Per altre informazioni sulla creazione di certificati di test, vedere Creare certificati demo per testare le funzionalità del dispositivo IoT Edge.

3. Sarà necessario trasferire i certificati e le chiavi in ogni dispositivo. È possibile usare un'unità USB, un servizio come Azure Key Vault o una funzione come la copia sicura dei file. Scegliere uno di questi metodi che corrisponde meglio al proprio scenario. Copiare i file nella directory preferita per certificati e chiavi. Usare /var/aziot/certs per i certificati e /var/aziot/secrets per le chiavi.

Per altre informazioni sull'installazione dei certificati in un dispositivo, vedere Gestire i certificati in un dispositivo IoT Edge.

Configurare il dispositivo padre

Per configurare il dispositivo padre, aprire una shell dei comandi locale o remota.

Per abilitare connessioni sicure, ogni dispositivo padre IoT Edge in uno scenario gateway deve essere configurato con un certificato CA Edge univoco e una copia del certificato CA radice condiviso da tutti i dispositivi nella gerarchia del gateway.

1. Accertarsi che i certificati soddisfino i requisiti del formato.

2. Trasferire il certificato CA radice, il certificato CA Edge padre e la chiave privata padre nel dispositivo padre.

3. Copiare i certificati e le chiavi nelle directory corrette. Le directory preferite per i certificati del dispositivo sono /var/aziot/certs per i certificati e /var/aziot/secrets per le chiavi.

   ### 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. Modificare la proprietà e le autorizzazioni dei certificati e delle chiavi.

   # 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
   

   L'output dell'elenco con la proprietà e l’autorizzazione corrette è simile al seguente:

   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. Installare il certificato CA radice nel dispositivo IoT Edge padre aggiornando l'archivio certificati nel dispositivo usando il comando specifico della piattaforma.

   # 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
   

   Per altre informazioni sull'uso di update-ca-trust in EFLOW, vedere Gestione dei certificati CA SSL CBL-Mariner.

Il comando indica che è stato aggiunto un certificato a /etc/ssl/certs.

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

Aggiornare il file di configurazione padre

Nel dispositivo deve essere già installato IoT Edge. In caso contrario, seguire la procedura per il Provisioning manuale di un singolo dispositivo IoT Edge Linux.

1. Accertarsi che il file di configurazione /etc/aziot/config.toml esista nel dispositivo padre.

   Se il file di configurazione non esiste nel dispositivo, usare il comando seguente per crearlo in base al file modello:

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

   È possibile usare anche il file modello come riferimento per aggiungere parametri di configurazione in questa sezione.

2. Aprire il file di configurazione IoT Edge usando un editor. Usare, ad esempio, l'editor nano per aprire il file /etc/aziot/config.toml.

   sudo nano /etc/aziot/config.toml
   

3. Trovare il parametro hostname o aggiungerlo all'inizio del file di configurazione. Aggiornare il valore con il nome di dominio completo (FQDN) o l'indirizzo IP del dispositivo padre IoT Edge. Ad esempio:

   hostname = "10.0.0.4"
   

   Per abilitare l’individuazione del gateway, ogni dispositivo gateway IoT Edge (elemento padre) deve specificare un parametro hostname che verrà utilizzato dai dispositivi figlio per trovarlo nella rete locale. Ogni dispositivo IoT Edge downstream deve specificare un parametro parent_hostname per identificare il relativo elemento padre. In uno scenario gerarchico in cui un singolo dispositivo IoT Edge è sia un dispositivo padre che un dispositivo figlio, sono necessari entrambi i parametri.

   I parametri hostname e trust_bundle_cert devono essere all'inizio del file di configurazione prima di qualunque sezione. L'aggiunta del parametro prima delle sezioni definite garantisce che venga applicato correttamente.

   Usare un nome host di lunghezza inferiore a 64 caratteri, cioè il limite di caratteri per un nome comune del certificato del server.

   Il modello nome host deve essere coerente in una gerarchia di gateway. Usare FQDN o indirizzi IP, ma non entrambi. Per connettere i dispositivi downstream è necessario un FQDN o un indirizzo IP.

   Impostare il nome host prima della creazione del contenitore edgeHub. Se edgeHub è in esecuzione, la modifica del nome host nel file di configurazione non avrà effetto finché il contenitore non verrà creato nuovamente. Per altre informazioni su come verificare l'applicazione del nome host, vedere la sezione verificare la configurazione padre.

4. Trovare il parametro Trust bundle cert o aggiungerlo all'inizio del file di configurazione.

   Aggiornare il parametro trust_bundle_cert con l’URI del file nel certificato CA radice nel dispositivo. Ad esempio:

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

5. Trovare o aggiungere la sezione Certificato CA Edge nel file di configurazione. Aggiornare i parametri del certificato cert e della chiave privata pk con i percorsi dell'URI del file per i file di chiave e certificato a catena completa nel dispositivo IoT Edge padre. IoT Edge richiede che il certificato e la chiave privata siano in formato PEM (Privacy Enhanced Mail) basato su testo. Ad esempio:

   [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. Accertarsi che il dispositivo IoT Edge usi la versione corretta dell'agente IoT Edge all'avvio. Trovare la sezione Agente Edge predefinito e impostare il valore dell'immagine per IoT Edge sulla versione 1.5. Ad esempio:

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

7. L'inizio del file di configurazione padre dovrebbe essere simile all'esempio seguente.

   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. Salvare e chiudere il file di configurazione config.toml. Ad esempio, se si usa l’editor nano, selezionare Ctrl+O - Scrivi, Invio e Ctrl+X - Esci.

9. Se in precedenza sono stati usati altri certificati per IoT Edge, eliminare i file nelle due directory seguenti per accertarsi che vengano applicati i nuovi certificati:

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

10. Applicare le modifiche.

    sudo iotedge config apply
    

11. Verificare la presenza di eventuali errori nella configurazione.

    sudo iotedge check --verbose
    

    Nota

    In un dispositivo di cui è stato appena effettuato il provisioning potrebbe essere visualizzato un errore correlato all'hub di IoT Edge:

    × idoneità alla produzione: la directory di archiviazione dell'hub di Edge è persistente nel file system host - Errore

    Non è stati possibile controllare lo stato corrente del contenitore edgeHub

    Questo errore è previsto in un dispositivo di cui è stato appena effettuato il provisioning, perché il modulo hub di IoT Edge non è in esecuzione. Per risolvere l'errore, nell'hub IoT impostare i moduli per il dispositivo e creare una distribuzione. La creazione di una distribuzione per il dispositivo avvia i moduli nel dispositivo, incluso il modulo hub di IoT Edge.

Verificare la configurazione padre

hostname deve essere un nome di dominio completo (FQDN) o l'indirizzo IP del dispositivo IoT Edge perché IoT Edge usa questo valore nel certificato del server quando i dispositivi downstream si connettono. I valori devono corrispondere, altrimenti si otterrà un errore di mancata corrispondenza dell'indirizzo IP.

Per verificare l’hostname, è necessario esaminare le variabili di ambiente del contenitore edgeHub.

1. Elencare i contenitori IoT Edge in esecuzione.

   iotedge list
   

   Accertarsi che i contenitori edgeAgent ed edgeHub siano in esecuzione. L'output del comando dovrebbe essere simile all'esempio seguente.

   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. Ispezionare il contenitore edgeHub.

   sudo docker inspect edgeHub
   

3. Nell'output, trovare il parametro EdgeDeviceHostName nella sezione Env.

   "EdgeDeviceHostName=10.0.0.4"
   

4. Accertarsi che il valore del parametro EdgeDeviceHostName corrisponda all’impostazione hostname config.toml. Se non corrisponde, il contenitore edgeHub era in esecuzione quando è stata modificata e applicata la configurazione. Per aggiornare EdgeDeviceHostName, rimuovere il contenitore edgeAgent.

   sudo docker rm -f edgeAgent
   

   I contenitori edgeAgent ed edgeHub vengono creati nuovamente e avviati in pochi minuti. Una volta che il contenitore edgeHub è in esecuzione, ispezionare il contenitore e accertarsi che il parametro EdgeDeviceHostName corrisponda al file di configurazione.

Configurare un dispositivo a downstream

Per configurare il dispositivo downstream, aprire una shell dei comandi locale o remota.

Per abilitare connessioni sicure, ogni dispositivo downstream IoT Edge in uno scenario gateway deve essere configurato con un certificato CA Edge univoco e una copia del certificato CA radice condiviso da tutti i dispositivi nella gerarchia del gateway.

1. Accertarsi che i certificati soddisfino i requisiti del formato.

2. Trasferire il certificato CA radice, il certificato ca edge figlio e la chiave privata figlio nel dispositivo downstream.

3. Copiare i certificati e le chiavi nelle directory corrette. Le directory preferite per i certificati del dispositivo sono /var/aziot/certs per i certificati e /var/aziot/secrets per le chiavi.

   ### 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. Modificare la proprietà e le autorizzazioni dei certificati e delle chiavi.

   # 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. Installare il certificato CA radice nel dispositivo IoT Edge downstream aggiornando l'archivio certificati nel dispositivo usando il comando specifico della piattaforma.

   # 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
   

   Per altre informazioni sull'uso di update-ca-trust in EFLOW, vedere Gestione dei certificati CA SSL CBL-Mariner.

Il comando indica che è stato aggiunto un certificato a /etc/ssl/certs.

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

Aggiornare il file di configurazione downstream

Nel dispositivo deve essere già installato IoT Edge. In caso contrario, seguire la procedura per il Provisioning manuale di un singolo dispositivo IoT Edge Linux.

1. Accertarsi che il file di configurazione /etc/aziot/config.toml esista nel dispositivo downstream.

   Se il file di configurazione non esiste nel dispositivo, usare il comando seguente per crearlo in base al file modello:

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

   È possibile usare anche il file modello come riferimento per aggiungere parametri di configurazione in questa sezione.

2. Aprire il file di configurazione IoT Edge usando un editor. Usare, ad esempio, l'editor nano per aprire il file /etc/aziot/config.toml.

   sudo nano /etc/aziot/config.toml
   

3. Trovare il parametro parent_hostname o aggiungerlo all'inizio del file di configurazione. Ogni dispositivo IoT Edge downstream deve specificare un parametro parent_hostname per identificare il relativo elemento padre. Aggiornare il parametro parent_hostname come FQDN o indirizzo IP del dispositivo padre, che corrisponde a quello fornito come nome host nel file di configurazione del dispositivo padre. Ad esempio:

   parent_hostname = "10.0.0.4"
   

4. Trovare il parametro Trust bundle cert o aggiungerlo all'inizio del file di configurazione.

   Aggiornare il parametro trust_bundle_cert con l’URI del file nel certificato CA radice nel dispositivo. Ad esempio:

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

5. Trovare o aggiungere la sezione Certificato CA Edge nel file di configurazione. Aggiornare i parametri del certificato cert e della chiave privata pk con i percorsi dell'URI del file per i file di chiave e certificato a catena completa nel dispositivo IoT Edge downstream. IoT Edge richiede che il certificato e la chiave privata siano in formato PEM (Privacy Enhanced Mail) basato su testo. Ad esempio:

   [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. Accertarsi che il dispositivo IoT Edge usi la versione corretta dell'agente IoT Edge all'avvio. Trovare la sezione Agente Edge predefinito e impostare il valore dell'immagine per IoT Edge sulla versione 1.5. Ad esempio:

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

7. L'inizio del file di configurazione downstream dovrebbe essere simile all'esempio seguente.

   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. Salvare e chiudere il file di configurazione config.toml. Ad esempio, se si usa l’editor nano, selezionare Ctrl+O - Scrivi, Invio e Ctrl+X - Esci.

9. Se in precedenza sono stati usati altri certificati per IoT Edge, eliminare i file nelle due directory seguenti per accertarsi che vengano applicati i nuovi certificati:

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

10. Applicare le modifiche.

    sudo iotedge config apply
    

11. Verificare la presenza di eventuali errori nella configurazione.

    sudo iotedge check --verbose
    

    Suggerimento

    Lo strumento di controllo di IoT Edge usa un contenitore per eseguire alcuni controlli diagnostici. Se si desidera usare questo strumento nei dispositivi IoT Edge downstream, accertarsi che possano accedere a mcr.microsoft.com/azureiotedge-diagnostics:latest o avere l'immagine del contenitore nel registro contenitori privato.

    Nota

    In un dispositivo di cui è stato appena effettuato il provisioning potrebbe essere visualizzato un errore correlato all'hub di IoT Edge:

    × idoneità alla produzione: la directory di archiviazione dell'hub di Edge è persistente nel file system host - Errore

    Non è stati possibile controllare lo stato corrente del contenitore edgeHub

    Questo errore è previsto in un dispositivo di cui è stato appena effettuato il provisioning, perché il modulo hub di IoT Edge non è in esecuzione. Per risolvere l'errore, nell'hub IoT impostare i moduli per il dispositivo e creare una distribuzione. La creazione di una distribuzione per il dispositivo avvia i moduli nel dispositivo, incluso il modulo hub di IoT Edge.

Dispositivi downstream isolati di rete

La procedura descritta finora in questo articolo configura i dispositivi IoT Edge come gateway o dispositivo downstream e crea una connessione attendibile tra loro. Il dispositivo gateway gestisce le interazioni tra il dispositivo downstream e l'hub IoT, inclusa l'autenticazione e il routing dei messaggi. I moduli distribuiti nei dispositivi IoT Edge downstream possono comunque creare proprie connessioni ai servizi cloud.

Alcune architetture di rete, come quelle che seguono lo standard ISA-95, cercano di ridurre al minimo il numero di connessioni Internet. In questi scenari, è possibile configurare dispositivi IoT Edge downstream senza connettività Internet diretta. Oltre al routing delle comunicazioni dell'hub IoT tramite il relativo dispositivo gateway, i dispositivi IoT Edge downstream possono basarsi sul dispositivo gateway per tutte le connessioni cloud.

Questa configurazione di rete richiede che solo il dispositivo IoT Edge di livello superiore di una gerarchia di gateway disponga di connessioni dirette al cloud. I dispositivi IoT Edge di livelli inferiori possono comunicare solo con il relativo dispositivo padre o con qualunque dispositivo figlio. Questo scenario è abilitato da moduli speciali nei dispositivi gateway:

• Il modulo proxy API è necessario in qualunque gateway IoT Edge che ha un altro dispositivo IoT Edge al di sotto. Ciò implica che deve trovarsi in ogni livello di una gerarchia di gateway, tranne il livello inferiore. Questo modulo usa un proxy inverso nginx per instradare dati HTTP tramite livelli di rete su una singola porta. È altamente configurabile tramite il relativo modulo gemello e le variabili di ambiente, quindi può essere regolato in base ai requisiti dello scenario gateway.

• Il modulo del registro Docker può essere distribuito nel gateway IoT Edge al livello superiore di una gerarchia di gateway. Questo modulo effettua il recupero e la memorizzazione nella cache delle immagini del contenitore per conto di tutti i dispositivi IoT Edge di livello inferiore. L'alternativa alla distribuzione di questo modulo al livello superiore consiste nell'uso di un registro locale o nel caricamento manuale delle immagini del contenitore nei dispositivi e nell’impostazione dei criteri pull del modulo su mai.

• L’archiviazione BLOB di Azure su IoT Edge può essere distribuita nel gateway IoT Edge al livello superiore di una gerarchia di gateway. Questo modulo effettua il caricamento dei BLOB per conto di tutti i dispositivi IoT Edge di livello inferiore. La possibilità di caricare BLOB consente anche utili funzionalità di risoluzione dei problemi per i dispositivi IoT Edge di livello inferiore, come il caricamento del log del modulo e il caricamento del bundle di supporto.

Configurazione di rete

Per ogni dispositivo gateway di livello superiore, gli operatori di rete devono:

• Fornire un indirizzo IP statico o un nome di dominio completo (FQDN).

• Autorizzare le comunicazioni in uscita da questo indirizzo IP al nome host dell'hub IoT di Azure sulle porte 443 (HTTPS) e 5671 (AMQP).

• Autorizzare le comunicazioni in uscita da questo indirizzo IP al nome host del Registro Azure Container sulla porta 443 (HTTPS).

  Il modulo proxy API può gestire le connessioni a un solo registro contenitori alla volta. È consigliabile avere tutte le immagini del contenitore, incluse le immagini pubbliche fornite da Registro Container Microsoft (mcr.microsoft.com), archiviate nel registro contenitori privato.

Per ogni dispositivo gateway di livello inferiore, gli operatori di rete devono:

• Fornire un indirizzo IP statico.
• Autorizzare le comunicazioni in uscita da questo indirizzo IP all’indirizzo IP del gateway padre sulla porta 443 (HTTPS) e 5671 (AMQP).

Distribuire i moduli nei dispositivi di livello superiore

Il dispositivo IoT Edge di livello superiore di una gerarchia di gateway include un set di moduli necessari che devono essere distribuiti in tale dispositivo, oltre a tutti i moduli del carico di lavoro che è possibile eseguire nel dispositivo.

Il modulo proxy API è stato concepito per essere personalizzato per la gestione degli scenari gateway più comuni. Questo articolo fornisce un esempio di configurazione dei moduli in una configurazione base. Per informazioni ed esempi più dettagliati, fare riferimento a Configurare il modulo proxy API per lo scenario della gerarchia di gateway.

Distribuire i moduli nei dispositivi di livello inferiore

I dispositivi IoT Edge di livello inferiore di una gerarchia di gateway includono un modulo necessari che deve essere distribuito in tali dispositivi, oltre a tutti i moduli del carico di lavoro che è possibile eseguire nel dispositivo.

Instradare i pull dell'immagine del contenitore

Prima di descrivere il modulo proxy necessario per i dispositivi IoT Edge nelle gerarchie di gateway, è importante comprendere in che modo i dispositivi IoT Edge di livello inferiore ottengono le relative immagini del modulo.

Se i dispositivi di livello inferiore non possono connettersi al cloud, ma si desidera che eseguano il pull delle immagini del modulo come di consueto, il dispositivo di livello superiore della gerarchia di gateway deve essere configurato per gestire tali richieste. Il dispositivo di livello superiore deve eseguire modulo registro Docker di cui è stato eseguito il mapping al registro contenitori. Configurare, quindi, il modulo proxy API per instradare le richieste del contenitore in tale modulo. Questi dettagli sono descritti nelle sezioni precedenti di questo articolo. In questa configurazione, i dispositivi di livello inferiore non devono puntare ai registri contenitori cloud, ma al registro in esecuzione nel livello superiore.

Ad esempio, invece di chiamare mcr.microsoft.com/azureiotedge-api-proxy:1.1, i dispositivi di livello inferiore devono chiamare $upstream:443/azureiotedge-api-proxy:1.1.

Il parametro $upstream punta all'elemento padre di un dispositivo di livello inferiore, per cui la richiesta verrà instradata attraverso tutti i livelli fino a quando raggiunge il livello superiore che ha un ambiente proxy che esegue il routing delle richieste del contenitore al modulo del registro. La porta :443 in questo esempio deve essere sostituita con la porta su cui è in ascolto il modulo proxy API nel dispositivo padre.

Il modulo proxy API può instradare a un solo modulo del registro e ogni modulo del registro può eseguire il mapping a un solo registro contenitori. Pertanto, tutte le immagini per cui i dispositivi di livello inferiore devono eseguire il pull devono essere archiviate in un singolo registro contenitori.

Se si desidera che i dispositivi di livello inferiore non creino richieste di pull del modulo tramite una gerarchia di gateway, un'altra opzione consiste nella gestione di una soluzione del registro locale. In alternativa, eseguire il push delle immagini del modulo nei dispositivi prima di creare distribuzioni, quindi impostare imagePullPolicy su mai.

Eseguire il bootstrap dell'agente IoT Edge

L'agente IoT Edge è il primo componente di runtime da avviare in un dispositivo IoT Edge. È necessario accertarsi che tutti i dispositivi IoT Edge downstream possano accedere all'immagine del modulo edgeAgent all'avvio e che possono accedere alle distribuzioni e avviare il resto delle immagini del modulo.

Quando si passa al file di configurazione in un dispositivo IoT Edge per fornire le informazioni di autenticazione, i certificati e il nome host padre, aggiornare anche l'immagine del contenitore edgeAgent.

Se il dispositivo gateway di primo livello è configurato per gestire le richieste dell’immagine del contenitore, sostituire mcr.microsoft.com con il nome host padre e la porta di ascolto del proxy API. Nel manifesto della distribuzione, è possibile usare $upstream come collegamento, ma ciò richiede che il modulo edgeHub gestisca il routing e che il modulo non sia stato avviato a questo punto. Ad esempio:

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

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

Se si usa un registro contenitori locale o si forniscono manualmente le immagini del contenitore nel dispositivo, aggiornare anche il file di configurazione.

Configurare il runtime e distribuire il modulo proxy

Il modulo proxy API è necessario per il routing di tutte le comunicazioni tra il cloud e tutti i dispositivi IoT Edge downstream. Un dispositivo IoT Edge di livello inferiore nella gerarchia, senza dispositivi IoT Edge downstream, non richiede questo modulo.

Il modulo proxy API è stato concepito per essere personalizzato per la gestione degli scenari gateway più comuni. Questo articolo descrive brevemente la procedura di configurazione dei moduli in una configurazione base. Per informazioni ed esempi più dettagliati, fare riferimento a Configurare il modulo proxy API per lo scenario della gerarchia di gateway.

1. Nel portale di Azure passare all'hub IoT.

2. Selezionare Dispositivi nel menu Gestione dispositivi.

3. Dall’elenco, selezionare il dispositivo IoT Edge di livello inferiore che si sta configurando.

4. Selezionare Imposta moduli.

5. Nella sezione Moduli IoT Edge, selezionare Aggiungi e scegliere Modulo IoT Edge.

6. Aggiornare le impostazioni del modulo seguenti:

   Impostazione	Valore
   Nome modulo IoT	IoTEdgeAPIProxy
   URI immagine	mcr.microsoft.com/azureiotedge-api-proxy:latest
   Criterio di riavvio	always
   Stato desiderato	running

   Se si desidera usare una versione o un'architettura diversa del modulo proxy API, trovare le immagini disponibili nel Registro artefatti Microsoft.

   1. Nella scheda Variabili di ambiente aggiungere una variabile denominata NGINX_DEFAULT_PORT di tipo Testo con un valore 443.

   2. Nella scheda Opzioni di creazione contenitore, aggiornare le associazioni delle porte in modo che facciano riferimento alla porta 443.

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

   Queste modifiche configurano il modulo proxy API per l'ascolto sulla porta 443. Per evitare conflitti di associazione delle porte, è necessario configurare il modulo edgeHub in modo che non sia in ascolto sulla porta 443. Il modulo proxy API, invece, instraderà qualunque traffico edgeHub sulla porta 443.

7. Selezionare Impostazioni di runtime.

8. Aggiornare le impostazioni del modulo edgeHub:

   1. Nel campo Immagine, sostituire mcr.microsoft.com con $upstream:443.
   2. Nel campo Opzioni di creazione, eliminare l’associazione porta per la porta 443, lasciando le associazioni per le porte 5671 e 8883.

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

9. Aggiornare le impostazioni del modulo edgeAgent:

   1. Nel campo Immagine, sostituire mcr.microsoft.com con $upstream:443.

10. Selezionare Applica per salvare l modifiche nelle impostazioni del runtime.

11. Selezionare Avanti: percorso per passare alla fase successiva.

12. Per abilitare i messaggi da dispositivo a cloud dai dispositivi downstream per raggiungere l'hub IoT, includere un percorso che passa tutti i messaggi a $upstream. Il parametro upstream punta al dispositivo padre nel caso di dispositivi di livello inferiore. Ad esempio:

    1. Nome: Route
    2. Valore: FROM /messages/* INTO $upstream

13. Selezionare Rivedi + Crea per passare al passaggio finale.

14. Selezionare Crea per la distribuzione nel dispositivo.

Verificare la connettività dall’elemento figlio all’elemento padre

1. Verificare la connessione TLS/SSL dall’elemento figlio all'elemento padre eseguendo il comando openssl seguente nel dispositivo downstream. Sostituire <parent hostname> con il FQDN o l’indirizzo IP dell’elemento padre.

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

   Il comando deve asserire la corretta convalida della catena di certificati padre, in maniera simile all'esempio seguente:

   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
   

   Il messaggio "Impossibile usare SSL_get_servername" può essere ignorato.

   Il valore depth=0 CN = deve corrispondere al parametro hostname specificato nel file di configurazione config.toml dell’elemento padre.

   Se si verifica il timeout del comando, potrebbero esistere porte bloccate tra i dispositivi figlio e padre. Rivedere la configurazione di rete e le impostazioni per i dispositivi.

   Avviso

   Se non si usa un certificato a catena completa nella sezione [edge_ca] del gateway, si verificano errori di convalida del certificato dal dispositivo downstream. Ad esempio, il comando openssl s_client ... precedente produrrà:

   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
   

   Lo stesso problema si verifica per i dispositivi abilitati per TLS che si connettono al dispositivo IoT Edge downstream se il certificato del dispositivo con catena completa non viene usato e configurato nel dispositivo downstream.

Integrare Microsoft Defender per IoT con il gateway IoT Edge

I dispositivi downstream possono essere usati per integrare l’agente micro di Microsoft Defender per IoT con il gateway IoT Edge usando il proxying dei dispositivi downstream.

Altre informazioni sull'agente micro di Defender per IoT.

Per integrare Microsoft Defender per IoT con IoT Edge usando il proxying dei dispositivi downstream:

1. Accedere al portale di Azure.

2. Passare a Hub IoT>Your Hub>Gestione dispositivi>Dispositivi

3. Selezionare il dispositivo.

   

4. Selezionare il modulo gemello DefenderIotMicroAgent creato da queste istruzioni.

   

5. Selezionare il pulsante per copiare la stringa di connessione (chiave primaria).

6. Incollare la stringa di connessione in un'applicazione di modifica del testo e aggiungere GatewayHostName alla stringa. GatewayHostName è il nome di dominio completo o l'indirizzo IP del dispositivo padre. Ad esempio: HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.

7. Aprire un terminale nel dispositivo downstream.

8. Usare il comando seguente per collocare la stringa di connessione codificata in UTF-8 nella directory dell'agente di Defender per il cloud nel file connection_string.txt nel percorso /etc/defender_iot_micro_agent/connection_string.txt seguente:

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

   connection_string.txt ora dovrebbe trovarsi nel percorso /etc/defender_iot_micro_agent/connection_string.txt seguente.

9. Riavviare il servizio utilizzando questo comando:

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

10. Tornare al dispositivo.

    

11. Abilitare la connessione all'hub IoT e selezionare l'icona a forma di ingranaggio.

    

12. Selezionare il dispositivo padre dall'elenco visualizzato.

13. Accertarsi che la porta 8883 (MQTT) tra il dispositivo downstream e il dispositivo IoT Edge sia aperta.

Passaggi successivi

Come usare un dispositivo Azure IoT Edge come gateway

Configurare il modulo proxy API per lo scenario della gerarchia di gateway