Condividi tramite

Gestire i certificati per la distribuzione di Azure IoT Operations

Le operazioni IoT di Azure usano TLS per crittografare la comunicazione tra tutti i componenti. Questo articolo descrive come gestire i certificati per le comunicazioni interne ed esterne e come usare un'autorità di certificazione (CA) per le comunicazioni interne in una distribuzione di produzione.

Prerequisiti

  • Per gestire i certificati per le comunicazioni esterne, è necessaria un'istanza di Operazioni IoT di Azure distribuita con impostazioni sicure. Se sono state distribuite le operazioni IoT di Azure con le impostazioni di test, è prima necessario abilitare le impostazioni sicure.

Gestire i certificati per le comunicazioni interne

Tutte le comunicazioni all'interno delle operazioni IoT di Azure vengono crittografate tramite TLS. Per iniziare, Operazioni di Azure IoT è distribuito con una CA radice predefinita e un'autorità di certificazione per i certificati server TLS. È possibile usare la configurazione predefinita per scopi di sviluppo e test. Per una distribuzione di produzione, è consigliabile usare un'autorità di certificazione personalizzata e una soluzione PKI aziendale.

Emittente autofirmato predefinito e certificato CA radice per certificati server TLS

Per iniziare, Operazioni di Azure IoT viene distribuito con un emittente autofirmato predefinito e un certificato CA radice per certificati server TLS. È possibile usare questo emittente per lo sviluppo e il test. Operazioni di Azure IoT usa cert-manager per gestire i certificati TLS e trust-manager per distribuire bundle di attendibilità ai componenti.

  • Il certificato della CA è autofirmato e non è considerato attendibile da alcun client all'esterno delle Operazioni di Azure IoT. L'oggetto del certificato della CA è CN=Azure IoT Operations Quickstart Root CA - Not for Production. Il certificato della CA viene ruotato automaticamente da cert-manager.

  • Il certificato CA radice viene archiviato in un segreto Kubernetes denominato azure-iot-operations-aio-ca-certificate nello spazio dei nomi cert-manager.

  • La parte pubblica del certificato CA radice viene archiviata in un oggetto ConfigMap denominato azure-iot-operations-aio-ca-trust-bundle nello spazio dei nomi azure-iot-operations. È possibile recuperare il certificato della CA da ConfigMap ed esaminarlo con kubectl e openssl. ConfigMap viene mantenuto aggiornato da trust-manager quando il certificato della CA viene ruotato da cert-manager.

    kubectl get configmap azure-iot-operations-aio-ca-trust-bundle -n azure-iot-operations -o "jsonpath={.data['ca\.crt']}" | openssl x509 -text -noout

    Certificate: 
    Data: 
        Version: 3 (0x2) 
        Serial Number: 
            <SERIAL-NUMBER> 
        Signature Algorithm: sha256WithRSAEncryption 
        Issuer: O=Microsoft, CN=Azure IoT Operations Quickstart Root CA - Not for Production 
        Validity 
            Not Before: Sep 18 20:42:19 2024 GMT 
            Not After : Sep 18 20:42:19 2025 GMT 
        Subject: O=Microsoft, CN=Azure IoT Operations Quickstart Root CA - Not for Production 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption 
                Public-Key: (2048 bit) 
                Modulus: <MODULUS> 
                                    Exponent: 65537 (0x10001) 
        X509v3 extensions: 
            X509v3 Key Usage: critical 
                Certificate Sign, CRL Sign 
            X509v3 Basic Constraints: critical 
                CA:TRUE 
            X509v3 Subject Key Identifier: 
                <SUBJECT-KEY-IDENTIFIER> 
    Signature Algorithm: sha256WithRSAEncryption 
[Signature]

  • Per impostazione predefinita, esiste già un emittente configurata nel azure-iot-operations namespace denominato azure-iot-operations-aio-certificate-issuer. Viene usato come emittente comune per tutti i certificati server TLS per Operazioni loT. Il broker MQTT usa un emittente creato dallo stesso certificato CA firmato dall'emittente autofirmato per rilasciare certificati server TLS per il listener TLS predefinito sulla porta 18883. È possibile esaminare l'autorità emittente con il comando seguente:

    kubectl get clusterissuer azure-iot-operations-aio-certificate-issuer -o yaml

    apiVersion: cert-manager.io/v1 
kind: ClusterIssuer 
metadata: 
  creationTimestamp: "2024-09-18T20:42:17Z" 
  generation: 1 
  name: azure-iot-operations-aio-certificate-issuer 
  resourceVersion: "36665" 
  uid: 592700a6-95e0-4788-99e4-ea93934bd330 
spec: 
  ca: 
    secretName: azure-iot-operations-aio-ca-certificate 
status: 
  conditions: 
  - lastTransitionTime: "2024-09-18T20:42:22Z" 
    message: Signing CA verified 
    observedGeneration: 1 
    reason: KeyPairVerified 
    status: "True" 
    type: Ready

Usare un emittente personalizzato

Per le distribuzioni di produzione, è consigliabile configurare le operazioni di Azure IoT con un'infrastruttura a chiave pubblica aziendale per gestire i certificati e che si usa un'autorità di certificazione personalizzata che funziona con l'infrastruttura a chiave pubblica aziendale, anziché usare l'emittente autofirmato predefinito per rilasciare certificati TLS per le comunicazioni interne.

Per configurare le operazioni di Azure IoT con il proprio emittente per le comunicazioni interne, seguire questa procedura prima di distribuire un'istanza nel cluster:

  1. Seguire la procedura descritta in Preparare il cluster per configurare il cluster.

  2. Installare cert-manager. Cert-manager gestisce i certificati TLS.

  3. Installare trust-manager. Durante l'installazione del gestore attendibilità, impostare trust namespace su cert-manager. Per esempio:

    helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --set app.trust.namespace=cert-manager --wait

    Trust-manager viene usato per distribuire un bundle di attendibilità ai componenti.

  4. Creare lo spazio dei nomi Operazioni di Azure IoT.

    kubectl create namespace azure-iot-operations

  5. Distribuire un emittente che funzioni con cert-manager. Per un elenco di tutti gli emittenti supportati, vedere Emittenti di cert-manager.

    L'emittente può essere di tipo ClusterIssuer o Issuer. Se si usa Issuer, la risorsa dell'emittente deve essere creata nello spazio dei nomi Operazioni di Azure IoT.

  6. Configurare il bundle di attendibilità nello spazio dei nomi Operazioni di Azure IoT.

    1. Per configurare il bundle di attendibilità, creare un oggetto ConfigMap nello spazio dei nomi Operazioni di Azure IoT. Inserire la parte chiave pubblica del certificato della CA nella mappa di configurazione con un nome di chiave di propria scelta.

    2. Ottenere la parte della chiave pubblica del certificato della CA. I passaggi per ottenere la chiave pubblica dipendono dall'emittente scelto.

    3. Creare ConfigMap. Per esempio:

      kubectl create configmap -n azure-iot-operations <YOUR_CONFIGMAP_NAME> --from-file=<CA_CERTIFICATE_FILENAME_PEM_OR_DER>

  7. Seguire i passaggi descritti in Distribuire Operazioni di Azure IoT per eseguire la distribuzione, con alcune modifiche.

    1. Aggiungere il parametro --user-trust durante la preparazione del cluster. Per esempio:

      az iot ops init --subscription <SUBSCRIPTION_ID> --cluster <CLUSTER_NAME>  -g <RESOURCE_GROUP> --user-trust

    2. Aggiungere il parametro --trust-settings con le informazioni necessarie durante la distribuzione di Operazioni di Azure IoT. Per esempio:

    az iot ops create --subscription <SUBSCRIPTION_ID> -g <RESOURCE_GROUP> --cluster <CLUSTER_NAME> --custom-location <CUSTOM_LOCATION> -n <INSTANCE_NAME> --sr-resource-id <SCHEMAREGISTRY_RESOURCE_ID> --trust-settings configMapName=<CONFIGMAP_NAME> configMapKey=<CONFIGMAP_KEY_WITH_PUBLICKEY_VALUE> issuerKind=<CLUSTERISSUER_OR_ISSUER> issuerName=<ISSUER_NAME>

Gestire i certificati per le comunicazioni esterne

L'esperienza di gestione dei certificati per le comunicazioni esterne usa Azure Key Vault come soluzione dell'insieme di credenziali gestito nel cloud. I certificati vengono aggiunti all'insieme di credenziali delle chiavi come segreti e sincronizzati con il bordo come segreti Kubernetes tramite l'estensione dell'archivio segreti di Azure Key Vault.

Ad esempio, il connettore per OPC UA usa l'esperienza di gestione dei certificati per configurare l'autenticazione dell'applicazione client OPC UA in un server OPC UA esterno. Le operazioni IoT di Azure gestiscono due archivi certificati distinti per il connettore per OPC UA: uno per la lista di fiducia e uno per la lista dei certificati emittenti. Per altre informazioni su come il connettore per OPC UA usa i certificati per stabilire un trust reciproco con un server OPC UA, vedere Infrastruttura di certificati OPC UA per il connettore per OPC UA.

Quando si distribuiscono le operazioni di Azure IoT con impostazioni sicure, è possibile iniziare ad aggiungere certificati ad Azure Key Vault e sincronizzarli con il cluster Kubernetes da usare nell'elenco Attendibilità e negli archivi dell'elenco autorità di certificazione per le connessioni OPC UA:

Screenshot che mostra le opzioni Carica certificato e Aggiungi da Azure Key Vault quando si aggiunge un nuovo certificato alla pagina degli endpoint dell'asset.

  • Carica certificato: carica un certificato che viene quindi aggiunto come segreto ad Azure Key Vault e sincronizzato automaticamente con l'estensione Secret Store.

    Suggerimento

    • Visualizzare i dettagli del certificato dopo il caricamento, per assicurarsi di disporre del certificato corretto prima di aggiungere Azure Key Vault e sincronizzare il cluster.
    • Usare un nome intuitivo in modo da poter riconoscere facilmente il segreto che rappresenta il proprio segreto in futuro.

    Annotazioni

    Caricare semplicemente il certificato non aggiungerà il segreto ad Azure Key Vault e non lo sincronizzerà con il cluster; è necessario selezionare Applica per applicare le modifiche.

  • Aggiungi da Azure Key Vault: aggiungere un segreto esistente dall'insieme di credenziali delle chiavi di Azure da sincronizzare con il cluster.

    Annotazioni

    Assicurarsi di selezionare il segreto che contiene il certificato da sincronizzare con il cluster. Se si seleziona un segreto che non è il certificato corretto, la connessione non riesce.

Usando la visualizzazione elenco è possibile gestire i certificati sincronizzati. È possibile visualizzare tutti i certificati sincronizzati e l'archivio certificati in cui è sincronizzato:

Screenshot che mostra l'elenco dei certificati nella pagina degli endpoint degli asset e come filtrare in base all'elenco di attendibilità e all'elenco di emittenti.

È anche possibile eliminare i certificati sincronizzati. Quando si elimina un certificato sincronizzato, esso viene eliminato solo dal cluster Kubernetes e non viene eliminato il riferimento segreto contenuto in Azure Key Vault. È necessario eliminare manualmente il secret del certificato dal Key Vault.