Condividi tramite

Configurare TLS con la gestione automatica dei certificati per proteggere la comunicazione MQTT nell'anteprima mq di Azure IoT

  • Articolo

Importante

Anteprima delle operazioni di Azure IoT: abilitata da Azure Arc è attualmente disponibile in ANTEPRIMA. Non è consigliabile usare questo software di anteprima negli ambienti di produzione.

Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

È possibile configurare TLS per proteggere la comunicazione MQTT tra il broker MQTT e il client usando una risorsa BrokerListener. È possibile configurare TLS con la gestione manuale o automatica dei certificati.

Verificare l'installazione di cert-manager

Con la gestione automatica dei certificati, si usa cert-manager per gestire il certificato del server TLS. Per impostazione predefinita, cert-manager viene installato insieme a Azure IoT Operations Preview nello spazio dei azure-iot-operations nomi già. Verificare l'installazione prima di procedere.

  1. Usare kubectl per verificare la presenza di pod corrispondenti alle etichette dell'app cert-manager.

    $ kubectl get pods --namespace azure-iot-operations -l 'app in (cert-manager,cainjector,webhook)'
NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

  2. Se vengono visualizzati i pod come pronti e in esecuzione, cert-manager viene installato e pronto per l'uso.

Suggerimento

Per verificare ulteriormente l'installazione, controllare la documentazione di cert-manager verificare l'installazione. Ricordarsi di usare lo spazio dei azure-iot-operations nomi .

Creare un'autorità di certificazione per il certificato del server TLS

La risorsa autorità di certificazione cert-manager definisce il modo in cui i certificati vengono rilasciati automaticamente. Cert-manager supporta diversi tipi di autorità emittenti in modo nativo. Supporta anche un tipo di autorità di certificazione esterna per estendere le funzionalità oltre le autorità emittenti supportate in modo nativo. L'anteprima mq di Azure IoT può essere usata con qualsiasi tipo di autorità di certificazione cert-manager.

Importante

Durante la distribuzione iniziale, Le operazioni di Azure IoT vengono installate con un'autorità di certificazione predefinita per i certificati server TLS. È possibile usare questa autorità emittente per lo sviluppo e il test. Per altre informazioni, vedere Autorità di certificazione radice e autorità di certificazione predefinite con operazioni IoT di Azure. I passaggi seguenti sono necessari solo se si vuole usare un'autorità emittente diversa.

L'approccio per creare l'autorità emittente è diverso a seconda dello scenario in uso. Le sezioni seguenti elencano esempi utili per iniziare.

L'autorità di certificazione è utile per lo sviluppo e il test. Deve essere configurato con un certificato e una chiave privata archiviata in un segreto Kubernetes.

Configurare il certificato radice come segreto Kubernetes

Se si dispone di un certificato CA esistente, creare un segreto Kubernetes con il certificato della CA e i file PEM della chiave privata. Eseguire il comando seguente ed è stato configurato il certificato radice come segreto Kubernetes e ignorare la sezione successiva.

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

Se non si dispone di un certificato CA, cert-manager può generare automaticamente un certificato CA radice. L'uso di cert-manager per generare un certificato CA radice è noto come bootstrap di un'autorità di certificazione con un certificato autofirmato.

  1. Iniziare creando ca.yaml:

    apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

  2. Creare il certificato ca autofirmato con il comando seguente:

    kubectl apply -f ca.yaml

Cert-manager crea un certificato CA usando le impostazioni predefinite. Le proprietà di questo certificato possono essere modificate modificando la specifica certificate. Per un elenco di opzioni valide, vedere la documentazione di cert-manager.

Distribuire il certificato radice

L'esempio precedente archivia il certificato della CA in un segreto Kubernetes denominato test-ca. Il certificato in formato PEM può essere recuperato dal segreto e archiviato in un file ca.crt con il comando seguente:

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

Questo certificato deve essere distribuito e considerato attendibile da tutti i client. Ad esempio, usare il --cafile flag per un client mosquitto.

È possibile usare Azure Key Vault per gestire i segreti per IoT MQ invece dei segreti Kubernetes. Per altre informazioni, vedere Gestire i segreti usando Azure Key Vault o i segreti Kubernetes.

Creare un'autorità di certificazione basata sul certificato ca

Cert-manager richiede un'autorità di certificazione basata sul certificato CA generato o importato nel passaggio precedente. Creare il file seguente come issuer-ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
  namespace: azure-iot-operations
spec:
  ca:
    # Must match secretName of generated or imported CA cert
    secretName: test-ca

Creare l'autorità emittente con il comando seguente:

kubectl apply -f issuer-ca.yaml

Il comando precedente crea un'autorità emittente per il rilascio dei certificati del server TLS. Prendere nota del nome e del tipo dell'emittente. Nell'esempio assegnare un nome my-issuer e un tipo Issuer. Questi valori vengono impostati nella risorsa BrokerListener in un secondo momento.

Abilitare TLS per una porta

Modificare l'impostazione tls in una risorsa BrokerListener per specificare una porta TLS e un'autorità di certificazione per i front-end. Di seguito è riportato un esempio di risorsa BrokerListener che abilita TLS sulla porta 8884 con gestione automatica dei certificati.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: my-new-tls-listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  authenticationEnabled: false # If set to true, a BrokerAuthentication resource must be configured
  authorizationEnabled: false
  serviceType: loadBalancer # Optional; defaults to 'clusterIP'
  serviceName: my-new-tls-listener # Avoid conflicts with default service name 'aio-mq-dmqtt-frontend'
  port: 8884 # Avoid conflicts with default port 8883
  tls:
    automatic:
      issuerRef:
        name: my-issuer
        kind: Issuer

Dopo aver configurato la risorsa BrokerListener, IoT MQ crea automaticamente un nuovo servizio con la porta specificata e TLS abilitata.

Facoltativo: configurare i parametri del certificato del server

Gli unici parametri obbligatori sono issuerRef.name e issuerRef.kind. Tutte le proprietà dei certificati server TLS generati vengono scelte automaticamente. Tuttavia, IoT MQ consente di personalizzare determinate proprietà specificandole nella risorsa BrokerListener, in tls.automatic.issuerRef. Di seguito è riportato un esempio di tutte le proprietà supportate:

# cert-manager issuer for TLS server certificate. Required.
issuerRef:
  # Name of issuer. Required.
  name: my-issuer
  # 'Issuer' or 'ClusterIssuer'. Required.
  kind: Issuer
  # Issuer group. Optional; defaults to 'cert-manager.io'.
  # External issuers may use other groups.
  group: cert-manager.io
# Namespace of certificate. Optional; omit to use default namespace.
namespace: az
# Where to store the generated TLS server certificate. Any existing
# data at the provided secret will be overwritten.
# Optional; defaults to 'my-issuer-{port}'.
secret: my-issuer-8884
# Parameters for the server certificate's private key.
# Optional; defaults to rotationPolicy: Always, algorithm: ECDSA, size: 256.
privateKey:
  rotationPolicy: Always
  algorithm: ECDSA
  size: 256
# Total lifetime of the TLS server certificate. Optional; defaults to '720h' (30 days).
duration: 720h
# When to begin renewing the certificate. Optional; defaults to '240h' (10 days).
renewBefore: 240h
# Any additional SANs to add to the server certificate. Omit if not required.
san:
  dns:
  - iotmq.example.com
  ip:
  - 192.168.1.1

Verificare la distribuzione

Usare kubectl per verificare che il servizio associato alla risorsa BrokerListener sia in esecuzione. Nell'esempio precedente il nome del servizio è my-new-tls-listener e lo spazio dei nomi è azure-iot-operations. Il comando seguente controlla lo stato del servizio:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
my-new-tls-listener    LoadBalancer   10.43.241.171   XXX.XX.X.X    8884:32457/TCP   33s

Connessione al broker con TLS

Dopo aver configurato il certificato del server, TLS è abilitato. Per testare con mosquitto:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

L'argomento --cafile abilita TLS nel client mosquitto e specifica che il client deve considerare attendibili tutti i certificati server rilasciati dal file specificato. È necessario specificare un file contenente l'autorità emittente del certificato del server TLS configurato.

Sostituire $HOST con l'host appropriato:

  • Se ci si connette dall'interno dello stesso cluster, sostituire con il nome del servizio specificato (my-new-tls-listener ad esempio) o il servizio CLUSTER-IP.
  • Se ci si connette dall'esterno del cluster, il servizio EXTERNAL-IP.

Ricordarsi di specificare i metodi di autenticazione, se necessario. Ad esempio, nome utente e password.

CA radice e autorità di certificazione predefinite con l'anteprima di Azure IoT Operations

Per iniziare, Le operazioni di Azure IoT vengono distribuite con una CA radice e un'autorità di certificazione radice predefinita "guida introduttiva" per i certificati server TLS. È possibile usare questa autorità emittente per lo sviluppo e il test.

  • Il certificato della CA è autofirmato e non è considerato attendibile da alcun client all'esterno delle operazioni IoT di Azure. L'oggetto del certificato della CA è CN = Azure IoT Operations Quickstart Root CA - Not for Production e scade entro 30 giorni dal momento dell'installazione.

  • Il certificato CA radice viene archiviato in un segreto Kubernetes denominato aio-ca-key-pair-test-only.

  • La parte pubblica del certificato CA radice viene archiviata in un oggetto ConfigMap denominato aio-ca-trust-bundle-test-only. È possibile recuperare il certificato della CA da ConfigMap ed esaminarlo con kubectl e openssl.

    $ kubectl get configmap aio-ca-trust-bundle-test-only -n azure-iot-operations -o json | jq -r '.data["ca.crt"]' | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            74:d8:b6:fe:63:5a:7d:24:bd:c2:c0:25:c2:d2:c7:94:66:af:36:89
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = Azure IoT Operations Quickstart Root CA - Not for Production
        Validity
            Not Before: Nov  2 00:34:31 2023 GMT
            Not After : Dec  2 00:34:31 2023 GMT
        Subject: CN = Azure IoT Operations Quickstart Root CA - Not for Production
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:51:43:93:2c:dd:6b:7e:10:18:a2:0f:ca:2e:7b:
                    bb:ba:5c:78:81:7b:06:99:b5:a8:11:4f:bb:aa:0d:
                    e0:06:4f:55:be:f9:5f:9e:fa:14:75:bb:c9:01:61:
                    0f:20:95:cd:9b:69:7c:70:98:f8:fa:a0:4c:90:da:
                    5b:1a:d7:e7:6b
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: 
                Certificate Sign
            X509v3 Subject Key Identifier: 
                B6:DD:8A:42:77:05:38:7A:51:B4:8D:8E:3F:2A:D1:79:32:E9:43:B9
    Signature Algorithm: ecdsa-with-SHA256
        30:44:02:20:21:cd:61:d7:21:86:fd:f8:c3:6d:33:36:53:e3:
        a6:06:3c:a6:80:14:13:55:16:f1:19:a8:85:4b:e9:5d:61:eb:
        02:20:3e:85:8a:16:d1:0f:0b:0d:5e:cd:2d:bc:39:4b:5e:57:
        38:0b:ae:12:98:a9:8f:12:ea:95:45:71:bd:7c:de:9d

  • Per impostazione predefinita, esiste già un'autorità di certificazione configurata nello spazio dei azure-iot-operations nomi denominato aio-ca-issuer. Viene usato come autorità di certificazione comune per tutti i certificati server TLS per le operazioni IoT. IoT MQ usa un'autorità di certificazione creata dallo stesso certificato DELLA CA per rilasciare certificati server TLS per il listener TLS predefinito sulla porta 8883. È possibile esaminare l'autorità emittente con il comando seguente:

    $ kubectl get issuer aio-ca-issuer -n azure-iot-operations -o yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  annotations:
    meta.helm.sh/release-name: azure-iot-operations
    meta.helm.sh/release-namespace: azure-iot-operations
  creationTimestamp: "2023-11-01T23:10:24Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: aio-ca-issuer
  namespace: azure-iot-operations
  resourceVersion: "2036"
  uid: c55974c0-e0c3-4d35-8c07-d5a0d3f79162
spec:
  ca:
    secretName: aio-ca-key-pair-test-only
status:
  conditions:
  - lastTransitionTime: "2023-11-01T23:10:59Z"
    message: Signing CA verified
    observedGeneration: 1
    reason: KeyPairVerified
    status: "True"
    type: Ready

Per la produzione, è necessario configurare un'autorità di certificazione con un certificato da una CA attendibile, come descritto nelle sezioni precedenti.

Contenuto correlato