Configurare TLS con la gestione automatica dei certificati per proteggere la comunicazione MQTT nell'anteprima mq di Azure IoT
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.
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
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.
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
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 servizioCLUSTER-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 denominatoaio-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.