Share via

Connettere dispositivi Azure IoT Edge per creare una gerarchia

  • Articolo

Si applica a:Segno di spunta IoT Edge 1.5 IoT Edge 1.5 Segno di spunta IoT Edge 1.4 IoT Edge 1.4

Importante

IoT Edge 1.5 LTS e IoT Edge 1.4 LTS sono versioni supportate. IoT Edge 1.4 LTS è di fine vita il 12 novembre 2024. Se si usa una versione precedente, vedere Aggiornare IoT Edge.

Questo articolo illustra i passaggi per stabilire una connessione attendibile tra un gateway IoT Edge e un dispositivo IoT Edge downstream. Questa configurazione è nota anche come arco annidato.

In uno scenario gateway, un dispositivo IoT Edge può essere sia un gateway che un dispositivo downstream. È possibile creare più gateway IoT Edge per creare una gerarchia di dispositivi. I dispositivi downstream (figlio) possono autenticare e inviare o ricevere messaggi tramite il dispositivo gateway (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, qualsiasi dispositivo che non ha un dispositivo padre ma si connette direttamente a hub IoT viene considerato nel livello superiore. Questo dispositivo è responsabile della gestione delle richieste da tutti i dispositivi sottostanti. L'altra configurazione si applica a qualsiasi dispositivo IoT Edge in un livello inferiore della gerarchia. Questi dispositivi possono essere un gateway per altri dispositivi IoT downstream e IoT Edge, ma devono anche instradare qualsiasi comunicazione 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 dispositivo gateway (padre) e tutti i dispositivi downstream (figlio).

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

  • Autenticazione: creare identità hub IoT per tutti i dispositivi nella gerarchia del gateway.
  • Autorizzazione: configurare la relazione padre/figlio in hub IoT per autorizzare i dispositivi downstream a connettersi al dispositivo padre in modo che si connettano a hub IoT.
  • Individuazione gateway: assicurarsi 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 per essere il 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.

Suggerimento

Questo articolo fornisce procedure dettagliate e opzioni che consentono di creare la gerarchia del gateway corretta per lo scenario. Per un'esercitazione guidata, vedere Creare una gerarchia di dispositivi IoT Edge usando i gateway.

Creare una gerarchia di gateway

È possibile creare una gerarchia di gateway IoT Edge definendo le 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à padre e gli elementi figlio di un'identità del dispositivo esistente.

Il passaggio di configurazione delle relazioni padre/figlio autorizza i dispositivi downstream a connettersi al dispositivo padre come si connetterebbe a hub IoT.

Solo i dispositivi IoT Edge possono essere dispositivi padre, ma entrambi i dispositivi IoT Edge e IoT possono essere figlio. Un padre può avere molti figli, ma un figlio può avere un solo padre. Una gerarchia di gateway viene creata concatenando i set padre/figlio in modo che l'elemento 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 Max Connessione edClients nel modulo edgeHub del dispositivo padre.

Nella portale di Azure è possibile gestire la relazione padre/figlio quando si creano nuove identità del dispositivo o modificando i dispositivi esistenti.

Quando si crea un nuovo dispositivo IoT Edge, è possibile scegliere i dispositivi padre e figlio dall'elenco dei dispositivi IoT Edge esistenti in tale hub.

  1. Nel portale di Azure passare all'hub IoT.
  2. Selezionare Dispositivi nel menu Gestione dispositivi.
  3. Selezionare Aggiungi dispositivo e quindi selezionare la casella di controllo Dispositivo IoT Edge.
  4. Insieme all'impostazione dell'ID dispositivo e delle impostazioni di autenticazione, è possibile impostare un dispositivo padre o Scegliere i dispositivi figlio.
  5. Scegliere il dispositivo o i dispositivi desiderati come padre o figlio.

È anche possibile creare o gestire relazioni padre/figlio per i dispositivi esistenti.

  1. Nel portale di Azure passare all'hub IoT.
  2. Selezionare Dispositivi nel menu Gestione dei dispositivi .
  3. Selezionare il dispositivo IoT Edge che si vuole gestire dall'elenco.
  4. Selezionare l'icona Imposta ingranaggio dispositivopadre o Gestisci dispositivi figlio.
  5. Aggiungere o rimuovere qualsiasi dispositivo padre o figlio.

Nota

Per stabilire relazioni padre-figlio a livello di codice, è possibile usare C#, Java o Node.js hub IoT Service SDK.

Di seguito è riportato un esempio di assegnazione di dispositivi figlio tramite C# SDK. L'attività RegistryManager_AddAndRemoveDeviceWithScope() mostra come creare a livello di codice una gerarchia a tre livelli. Un dispositivo IoT Edge è di livello 1, come elemento padre. Un altro dispositivo IoT Edge è nel livello 2, che funge sia da figlio che da padre. Infine, un dispositivo IoT è nel livello tre, come dispositivo figlio di livello più basso.

Generare i certificati

Per stabilire una comunicazione sicura tra loro, è necessario installare una catena coerente di certificati tra dispositivi nella stessa gerarchia del 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 del dispositivo.

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

Illustrazione della catena di certificati rilasciata dalla CA radice nel gateway e nel dispositivo downstream

Per altre informazioni sui requisiti dei certificati 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 più alto per tutti i dispositivi in una determinata gerarchia di gateway. Questo certificato viene installato in tutti i dispositivi.
    • Tutti i certificati intermedi da includere nella catena di certificati radice.
    • Un certificato ca del dispositivo e la relativa chiave privata, generati dai certificati radice e intermedi. È necessario un certificato ca univoco del dispositivo per ogni dispositivo IoT Edge nella gerarchia del gateway.

    È possibile usare un'autorità di certificazione autofirmato o acquistarne una da un'autorità di certificazione commerciale attendibile, ad esempio 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 del dispositivo IoT Edge per ogni dispositivo. In questo articolo si useranno i certificati di test generati usando i certificati della 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 i certificati creati dagli script di test per la produzione. Contengono password hardcoded e scadono per impostazione predefinita dopo 30 giorni. I certificati della CA di test vengono forniti a scopo dimostrativo per comprendere i certificati DELLA CA. Usare le procedure consigliate per la sicurezza per la creazione della certificazione e la gestione della durata nell'ambiente di produzione.

    Per altre informazioni sulla creazione di certificati di test, vedere Creare certificati demo per testare le funzionalità dei dispositivi 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 meglio corrispondano 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 univoco del dispositivo e una copia del certificato CA radice condiviso da tutti i dispositivi nella gerarchia del gateway.

  1. Verificare che i certificati soddisfino i requisiti di formato.

  2. Trasferire il certificato CA radice, il certificato CA 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 proprietà e 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 update-ca-trust di in EFLOW, vedere Gestione dei certificati DELLA CA SSL CBL-Mariner.

Il comando segnala 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 dovrebbe essere già installato IoT Edge. In caso contrario, seguire la procedura per effettuare manualmente il provisioning di un singolo dispositivo Linux IoT Edge.

  1. Verificare che il /etc/aziot/config.toml file di configurazione 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

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

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

    sudo nano /etc/aziot/config.toml

  3. Trovare il parametro hostname o aggiungerlo all'inizio del file di configurazione. Aggiornare il valore in modo che sia 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 (padre) deve specificare un parametro hostname che i dispositivi figlio useranno 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, richiede entrambi i parametri.

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

    Usare un nome host più breve di 64 caratteri, ovvero il limite di caratteri per un nome comune del certificato server.

    Essere coerenti con il modello hostname in una gerarchia del gateway. Usare FQDN o indirizzi IP, ma non entrambi. Per connettere i dispositivi downstream è necessario un nome di dominio completo 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 viene ricreato. 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 trust_bundle_cert parametro con l'URI del file al 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 pk privata con i percorsi dell'URI del file per i file di certificato e chiave full-chain 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. Verificare che il dispositivo IoT Edge usi la versione corretta dell'agente IoT Edge all'avvio. Trovare la sezione Default Edge Agent e impostare il valore dell'immagine per IoT Edge sulla versione 1.5. Ad esempio:

    [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 config.toml file di configurazione. Ad esempio, se si usa l'editor nano, selezionare CTRL+O - Write Out, 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 assicurarsi 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 IoT Edge:

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

    Impossibile controllare lo stato corrente del contenitore edgeHub

    Questo errore è previsto in un dispositivo di cui è stato appena effettuato il provisioning perché il modulo hub IoT Edge non è in esecuzione. Per risolvere l'errore, in 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 IoT Edge.

Verificare la configurazione padre

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

Per verificare il nome host, è necessario esaminare le variabili di ambiente del contenitore edgeHub .

  1. Elencare i contenitori IoT Edge in esecuzione.

    iotedge list

    Verificare che i contenitori edgeAgent e 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. Esaminare il contenitore edgeHub .

    sudo docker inspect edgeHub

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

    "EdgeDeviceHostName=10.0.0.4"

  4. Verificare che il valore del parametro EdgeDeviceHostName corrisponda all'impostazione config.tomlhostname. 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 e edgeHub vengono ricreati e avviati entro pochi minuti. Dopo l'esecuzione del contenitore edgeHub , esaminare il contenitore e verificare che il parametro EdgeDeviceHostName corrisponda al file di configurazione.

Configurare il dispositivo 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 univoco del dispositivo e una copia del certificato CA radice condiviso da tutti i dispositivi nella gerarchia del gateway.

  1. Verificare che i certificati soddisfino i requisiti di formato.

  2. Trasferire il certificato CA radice, il certificato della CA 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 update-ca-trust di in EFLOW, vedere Gestione dei certificati DELLA CA SSL CBL-Mariner.

Il comando segnala 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 dovrebbe essere già installato IoT Edge. In caso contrario, seguire la procedura per effettuare manualmente il provisioning di un singolo dispositivo Linux IoT Edge.

  1. Verificare che il /etc/aziot/config.toml file di configurazione 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

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

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

    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 identificarne l'elemento padre. Aggiornare il parent_hostname parametro in modo che sia il nome FQDN o l'indirizzo IP del dispositivo padre, che corrisponda a quello specificato 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 trust_bundle_cert parametro con l'URI del file al 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 pk privata con i percorsi dell'URI del file per i file di certificato e di chiave a catena completa nel dispositivo downstream di IoT Edge. 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. Verificare che il dispositivo IoT Edge usi la versione corretta dell'agente IoT Edge all'avvio. Trovare la sezione Default Edge Agent e impostare il valore dell'immagine per IoT Edge sulla versione 1.5. Ad esempio:

    [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 config.toml file di configurazione. Ad esempio, se si usa l'editor nano, selezionare CTRL+O - Write Out, 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 assicurarsi 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 di diagnostica. Se si vuole usare questo strumento nei dispositivi IoT Edge downstream, assicurarsi che possano accedere mcr.microsoft.com/azureiotedge-diagnostics:latesta 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 IoT Edge:

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

    Impossibile controllare lo stato corrente del contenitore edgeHub

    Questo errore è previsto in un dispositivo di cui è stato appena effettuato il provisioning perché il modulo hub IoT Edge non è in esecuzione. Per risolvere l'errore, in 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 IoT Edge.

Isolare di rete i dispositivi downstream

I passaggi finora descritti in questo articolo configurano i dispositivi IoT Edge come gateway o come dispositivo downstream e creano una connessione attendibile tra di essi. Il dispositivo gateway gestisce le interazioni tra il dispositivo downstream e hub IoT, tra cui l'autenticazione e il routing dei messaggi. I moduli distribuiti nei dispositivi IoT Edge downstream possono comunque creare connessioni personalizzate 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 hub IoT comunicazioni tramite il 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 nel livello superiore di una gerarchia di gateway disponga di connessioni dirette al cloud. I dispositivi IoT Edge nei livelli inferiori possono comunicare solo con il dispositivo padre o con qualsiasi dispositivo figlio. I moduli speciali nei dispositivi gateway abilitano questo scenario, tra cui:

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

  • Il modulo del Registro di sistema Docker può essere distribuito nel gateway IoT Edge al livello superiore di una gerarchia di gateway. Questo modulo è responsabile del recupero e della memorizzazione nella cache delle immagini del contenitore per conto di tutti i dispositivi IoT Edge in livelli inferiori. L'alternativa alla distribuzione di questo modulo al livello superiore consiste nell'usare un registro locale o caricare manualmente le immagini del contenitore nei dispositivi e impostare i criteri pull del modulo su mai.

  • Il Archiviazione BLOB di Azure in IoT Edge può essere distribuito nel gateway IoT Edge al livello superiore di una gerarchia di gateway. Questo modulo è responsabile del caricamento di BLOB per conto di tutti i dispositivi IoT Edge in livelli inferiori. La possibilità di caricare BLOB consente anche funzionalità utili per la risoluzione dei problemi per i dispositivi IoT Edge in livelli inferiori, ad esempio il caricamento del log dei moduli e il caricamento del bundle di supporto.

Configurazione di rete

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

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

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

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

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

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

  • Specificare un indirizzo IP statico.
  • Autorizzare le comunicazioni in uscita da questo indirizzo IP all'indirizzo IP del gateway padre sulle porte 443 (HTTPS) e 5671 (AMQP).

Distribuire moduli nei dispositivi di livello superiore

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

Il modulo proxy API è stato progettato per essere personalizzato per gestire gli scenari di gateway più comuni. Questo articolo fornisce un esempio per configurare i moduli in una configurazione di base. Per informazioni più dettagliate ed esempi, vedere Configurare il modulo proxy API per lo scenario della gerarchia del gateway.

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

  2. Selezionare Dispositivi nel menu Gestione dispositivi.

  3. Selezionare il dispositivo IoT Edge di livello superiore che si sta configurando nell'elenco.

  4. Selezionare Imposta moduli.

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

  6. Cercare e selezionare il modulo Proxy API IoT Edge.

  7. Selezionare il nome del modulo proxy API dall'elenco dei moduli distribuiti e aggiornare le impostazioni del modulo seguenti:

    1. Nella scheda Variabili di ambiente aggiornare il valore di NGINX_DEFAULT_PORT a 443.

    2. Nella scheda Opzioni di creazione del contenitore aggiornare le associazioni delle porte per fare 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 instrada invece qualsiasi traffico edgeHub sulla porta 443.

  8. Selezionare Runtime Impostazioni e trovare le opzioni di creazione del modulo edgeHub. Eliminare l'associazione di porte per la porta 443, lasciando le associazioni per le porte 5671 e 8883.

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

  9. Selezionare Salva per salvare le modifiche apportate alle impostazioni di runtime.

  10. Selezionare di nuovo Aggiungi , quindi scegliere modulo IoT Edge.

  11. Specificare i valori seguenti per aggiungere il modulo del Registro di sistema Docker alla distribuzione:

    1. Nome del modulo IoT Edge: registry

    2. Nella scheda Impostazioni modulo URI immagine:registry:latest

    3. Nella scheda Variabili di ambiente aggiungere le variabili di ambiente seguenti:

      • Nome: valore: REGISTRY_PROXY_REMOTEURLl'URL del registro contenitori a cui si vuole eseguire il mapping di questo modulo del Registro di sistema. Ad esempio: https://myregistry.azurecr.

        Il modulo del Registro di sistema può essere mappato solo a un registro contenitori, pertanto è consigliabile avere tutte le immagini del contenitore in un unico registro contenitori privato.

      • Nome: valore: REGISTRY_PROXY_USERNAMEnome utente per l'autenticazione nel registro contenitori.

      • Nome: valore: REGISTRY_PROXY_PASSWORDpassword per l'autenticazione nel registro contenitori.

    4. Nella scheda Opzioni di creazione del contenitore incollare:

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

  12. Selezionare Aggiungi per aggiungere il modulo alla distribuzione.

  13. Selezionare Avanti: Route per passare al passaggio successivo.

  14. Per abilitare i messaggi da dispositivo a cloud dai dispositivi downstream per raggiungere hub IoT, includere una route che passa tutti i messaggi a hub IoT. Ad esempio:

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

  15. Selezionare Rivedi e crea per passare al passaggio finale.

  16. Selezionare Crea per eseguire la distribuzione nel dispositivo.

Distribuire moduli in dispositivi di livello inferiore

I dispositivi IoT Edge in livelli inferiori di una gerarchia di gateway hanno un modulo necessario che deve essere distribuito in essi, oltre a tutti i moduli del carico di lavoro che è possibile eseguire nel dispositivo.

Eseguire il pull dell'immagine del contenitore di route

Prima di discutere del modulo proxy necessario per i dispositivi IoT Edge nelle gerarchie del gateway, è importante comprendere in che modo i dispositivi IoT Edge nei livelli inferiori ottengono le immagini del modulo.

Se i dispositivi di livello inferiore non possono connettersi al cloud, ma si vuole che estraggono le immagini del modulo come di consueto, il dispositivo di livello superiore della gerarchia del gateway deve essere configurato per gestire queste richieste. Il dispositivo di livello superiore deve eseguire un modulo del registro Docker mappato al registro contenitori. Configurare quindi il modulo proxy API per instradare le richieste di contenitore. 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 di sistema 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, quindi la richiesta verrà instradata attraverso tutti i livelli fino a raggiungere il livello superiore con un ambiente proxy che instrada le richieste di contenitori al modulo del Registro di sistema. La :443 porta 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 solo a un modulo del Registro di sistema e ogni modulo del Registro di sistema può eseguire il mapping a un solo registro contenitori. Pertanto, tutte le immagini che i dispositivi di livello inferiore devono eseguire il pull devono essere archiviate in un singolo registro contenitori.

Se non si vogliono dispositivi di livello inferiore che effettuano richieste pull del modulo tramite una gerarchia di gateway, un'altra opzione consiste nel gestire una soluzione del Registro di sistema locale. In alternativa, eseguire il push delle immagini del modulo nei dispositivi prima di creare le distribuzioni e quindi impostare imagePullPolicy su mai.

Bootstrap dell'agente IoT Edge

L'agente IoT Edge è il primo componente di runtime da avviare in qualsiasi dispositivo IoT Edge. È necessario assicurarsi che tutti i dispositivi IoT Edge downstream possano accedere all'immagine del modulo edgeAgent all'avvio, quindi 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 di 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 è necessario 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 specificano manualmente le immagini del contenitore nel dispositivo, aggiornare di conseguenza il file di configurazione.

Configurare il runtime e distribuire il modulo proxy

Il modulo proxy API è necessario per instradare tutte le comunicazioni tra il cloud e qualsiasi dispositivo IoT Edge downstream. Un dispositivo IoT Edge nel livello inferiore della gerarchia, senza dispositivi IoT Edge downstream, non richiede questo modulo.

Il modulo proxy API è stato progettato per essere personalizzato per gestire gli scenari di gateway più comuni. Questo articolo illustra brevemente i passaggi per configurare i moduli in una configurazione di base. Per informazioni più dettagliate ed esempi, vedere Configurare il modulo proxy API per lo scenario della gerarchia del gateway.

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

  2. Selezionare Dispositivi nel menu Gestione dispositivi.

  3. Selezionare il dispositivo IoT Edge di livello inferiore che si sta configurando nell'elenco.

  4. Selezionare Imposta moduli.

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

  6. Cercare e selezionare il modulo Proxy API IoT Edge.

  7. Selezionare il nome del modulo proxy API dall'elenco dei moduli distribuiti e aggiornare le impostazioni del modulo seguenti:

    1. Nella scheda Impostazioni modulo aggiornare il valore di URI immagine. Sostituisci mcr.microsoft.com con $upstream:443.

    2. Nella scheda Variabili di ambiente aggiornare il valore di NGINX_DEFAULT_PORT a 443.

    3. Nella scheda Opzioni di creazione del contenitore aggiornare le associazioni delle porte per fare 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 instrada invece qualsiasi traffico edgeHub sulla porta 443.

  8. Selezionare Runtime Impostazioni.

  9. Aggiornare le impostazioni del modulo edgeHub:

    1. Nel campo Immagine sostituire mcr.microsoft.com con $upstream:443.
    2. Nel campo Crea opzioni eliminare l'associazione di porte per la porta 443, lasciando le associazioni per le porte 5671 e 8883.
    {
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}

  10. Aggiornare le impostazioni del modulo edgeAgent:

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

  11. Selezionare Salva per salvare le modifiche apportate alle impostazioni di runtime.

  12. Selezionare Avanti: Route per passare al passaggio successivo.

  13. Per consentire ai messaggi da dispositivo a cloud dai dispositivi downstream di raggiungere hub IoT, includere una route 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

  14. Selezionare Rivedi e crea per passare al passaggio finale.

  15. Selezionare Crea per eseguire la distribuzione nel dispositivo.

Verificare la connettività da figlio a padre

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

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

    Il comando deve confermare la corretta convalida della catena di certificati padre 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 "Non può usare SSL_get_servername" può essere ignorato.

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

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

    Avviso

    L'uso di un certificato a catena completa nella sezione del [edge_ca] gateway genera errori di convalida del certificato dal dispositivo downstream. Ad esempio, il openssl s_client ... comando 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 proxy dei dispositivi downstream.

Altre informazioni sull'agente micro Defender per IoT.

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

  1. Accedere al portale di Azure.

  2. Passare a hub IoTYour Hub>> Dispositivi di gestione>dei dispositivi

  3. Selezionare il dispositivo.

    Screenshot che mostra dove si trova il dispositivo per la selezione.

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

    Screenshot che mostra il percorso di DefenderIotMicroAgent.

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

  6. Incollare la stringa Connessione ion in un'applicazione di modifica del testo e aggiungere GatewayHostName alla stringa. 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 inserire il stringa di connessione codificato in utf-8 nella directory dell'agente Defender per il cloud nel file connection_string.txt nel percorso seguente: /etc/defender_iot_micro_agent/connection_string.txt

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

    L'oggetto connection_string.txt dovrebbe ora trovarsi nel percorso /etc/defender_iot_micro_agent/connection_string.txtseguente.

  9. Riavviare il servizio usando questo comando:

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

  10. Tornare al dispositivo.

    Screenshot che mostra come tornare al dispositivo.

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

    Screenshot che mostra cosa selezionare per impostare un dispositivo padre.

  12. Selezionare il dispositivo padre dall'elenco visualizzato.

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

Passaggi successivi

Come usare un dispositivo Azure IoT Edge come gateway

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