Proteggere la comunicazione del broker MQTT tramite BrokerListener
Importante
Questa pagina include istruzioni per la gestione dei componenti di Operazioni IoT di Azure usando i manifesti di distribuzione kubernetes, disponibile in anteprima. Questa funzionalità viene fornita con diverse limitazioni e non deve essere usata per i carichi di lavoro 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.
Una risorsa BrokerListener corrisponde a un endpoint di rete che espone il broker ai client in rete. È possibile disporre di una o più risorse BrokerListener per ogni broker, con più porte e controllo di accesso diverso per ogni broker.
Ogni porta BrokerListener può avere regole di autenticazione e autorizzazione proprie che definiscono chi può connettersi a tale porta del listener e quali azioni possono eseguire sul broker. È possibile usare le risorse BrokerAuthentication e BrokerAuthorization per specificare i criteri di controllo di accesso per ogni porta del listener. Questa flessibilità consente di ottimizzare le autorizzazioni e i ruoli per i client MQTT in base alle esigenze e ai casi d'uso.
Suggerimento
La distribuzione predefinita del broker MQTT è un servizio IP del cluster che richiede ai client di connettersi con il protocollo TLS (Transport Layer Security) ed eseguire l'autenticazione con i token dell'account del servizio. I client che si connettono dall'esterno del cluster necessitano di una configurazione aggiuntiva prima di potersi connettere.
I listener broker presentano le caratteristiche seguenti:
- Nome: nome del listener. Questo nome è anche il nome del servizio Kubernetes a meno che non venga sottoposto a override.
- Tipo di servizio: è possibile avere fino a tre listener, uno per tipo di servizio. Il listener predefinito è il tipo di
ClusterIpservizio . - Porte: ogni listener supporta più porte. Le porte non possono essere in conflitto con listener diversi.
- Riferimenti all'autenticazione e all'autorizzazione: BrokerAuthentication e BrokerAuthorization sono configurati per porta.
- TLS: la configurazione TLS manuale o automatica viene applicata per ogni porta.
- Protocollo: MQTT su WebSocket può essere abilitato per ogni porta.
Per un elenco di tutte le impostazioni disponibili, vedere le informazioni di riferimento sull'API del listener broker.
BrokerListener predefinito
Quando si distribuisce Azure IoT Operations, la distribuzione crea una risorsa BrokerListener denominata default. Questo listener viene usato per la comunicazione interna crittografata tra i componenti operazioni IoT. Il listener predefinito fa parte del broker predefinito.
- Espone un servizio ClusterIp sulla porta 18883.
- Richiede ai client di usare l'autenticazione dell'account del servizio Kubernetes.
- Ha un certificato TLS gestito automaticamente.
- Non configura alcun criterio di autorizzazione client.
Attenzione
Per evitare di interrompere la comunicazione interna delle operazioni IoT, mantenere invariato il listener predefinito e dedicato per l'uso interno. Per la comunicazione esterna, creare un nuovo listener. Se è necessario usare il ClusterIp servizio, aggiungere altre porte al listener predefinito senza modificare alcuna delle impostazioni esistenti.
Per visualizzare o modificare il listener predefinito, seguire questa procedura.
Nella portale di Azure passare all'istanza di Operazioni IoT.
In Componenti selezionare MqTT Broker.
Nell'elenco listener broker selezionare il listener predefinito .
Esaminare le impostazioni del listener, ma evitare di modificare le impostazioni esistenti. Creare invece una nuova porta e configurarla in base alle esigenze.
Evitare di modificare il listener broker predefinito
Per evitare l'interruzione della comunicazione interna delle operazioni IoT, mantenere invariato il listener predefinito e dedicato per l'uso interno. Per la comunicazione esterna, creare un nuovo listener.
Poiché il listener broker predefinito usa il tipo di ClusterIpservizio e è possibile avere un solo listener per tipo di servizio, aggiungere altre porte al listener predefinito senza modificare alcuna delle impostazioni esistenti se è necessario usare il ClusterIp servizio.
Creare nuovi listener broker
Per creare un nuovo listener, specificare le impostazioni seguenti:
- Nome: nome del listener. Questo nome è anche il nome del servizio Kubernetes a meno che non venga sottoposto a override.
- Tipo di servizio: tipo del servizio Kubernetes. Vedere Tipo di servizio.
- Porte: elenco di porte su cui rimanere in ascolto. Vedere Porte.
- Nome servizio (facoltativo): eseguire l'override del nome del servizio Kubernetes. Vedere Nome del servizio.
Esempio: Creare un nuovo listener con due porte
Questo esempio illustra come creare un nuovo listener con il LoadBalancer tipo di servizio. La risorsa BrokerListener definisce due porte che accettano connessioni MQTT dai client.
- La prima porta è in ascolto sulla porta 1883 senza TLS e autenticazione. Questa configurazione è adatta solo per i test. Non usare questa configurazione nell'ambiente di produzione.
- La seconda porta è in ascolto sulla porta 8883 con TLS e l'autenticazione abilitata. Solo i client autenticati con un token dell'account del servizio Kubernetes possono connettersi. TLS è impostato sulla modalità automatica, usando cert-manager per gestire il certificato server dall'autorità emittente predefinita. Questa configurazione è più vicina a una configurazione di produzione.
Nella portale di Azure passare all'istanza di Operazioni IoT.
In Componenti selezionare MqTT Broker.
Selezionare il listener broker MQTT per LoadBalancer Create (Crea loadBalancer).>
Immetti le impostazioni seguenti:
Impostazione Description Nome Nome della risorsa BrokerListener. Nome servizio Nome del servizio Kubernetes. Lasciare vuoto per usare il nome del listener come nome del servizio. Tipo di servizio LoadBalancer già selezionato. In Porte immettere le impostazioni seguenti per la prima porta:
Impostazione Descrizione Porta Immettere 1883. Autenticazione Scegliere Nessuna Autorizzazione Scegliere Nessuna Protocollo Scegliere MQTT. TLS Non aggiungere. Selezionare Aggiungi voce di porta per aggiungere una seconda porta e immettere le impostazioni seguenti:
Impostazione Descrizione Porta Immettere 8883. Autenticazione Scegliere il valore predefinito. Autorizzazione Scegliere Nessuna Protocollo Scegliere MQTT. TLS Selezionare Aggiungi. Nel riquadro configurazione TLS immettere le impostazioni seguenti:
Impostazione Descrizione Modalità TLS Scegliere Automatico. Nome dell'autorità emittente Immetti azure-iot-operations-aio-certificate-issuer.Tipo autorità di certificazione Scegliere ClusterIssuer. Lasciare le altre impostazioni predefinite e selezionare Applica.
Selezionare Crea listener.
Tipo di servizio
Ogni risorsa BrokerListener viene mappata a un servizio Kubernetes. Il tipo di servizio determina la modalità di esposizione del broker alla rete. I tipi di servizio supportati sono:
- ClusterIp: espone il broker in un indirizzo IP interno del cluster. I client possono connettersi al broker dall'interno del cluster. Questo tipo di servizio predefinito è per il listener predefinito.
- NodePort: espone il broker sull'INDIRIZZO IP di ogni nodo a una porta statica. I client possono connettersi al broker dall'esterno del cluster. Questo tipo di servizio è utile per lo sviluppo e il test.
- LoadBalancer: espone esternamente il broker. Al servizio viene assegnato un indirizzo IP esterno che i client possono usare per connettersi al broker. Questo tipo di servizio è il più comune per le distribuzioni di produzione.
Solo un listener per tipo di servizio
È consentito un solo listener per tipo di servizio. Se è necessaria una maggiore connettività dello stesso tipo di servizio, aggiungere altre porte al listener esistente di tale tipo di servizio.
Nome servizio
Il nome del servizio è il nome del servizio Kubernetes associato al broker. Se non specificato, il nome del listener broker viene usato come nome del servizio. Il nome del servizio deve essere univoco all'interno dello spazio dei nomi .
Suggerimento
Per evitare il sovraccarico di gestione, è consigliabile lasciare vuoto il nome del servizio. Il nome del listener è univoco ed è possibile usarlo per identificare il servizio. Usare il nome del servizio come override solo quando non è possibile denominare il servizio dopo il listener.
Porti
Ogni listener può avere più porte e ogni porta può avere le proprie impostazioni per l'autenticazione, l'autorizzazione, il protocollo e TLS.
Per usare la propria impostazione di autenticazione o autorizzazione per una porta, è necessario creare le risorse corrispondenti prima di usarla con un listener. Per altre informazioni, vedere Configurare l'autenticazione del broker MQTT e Configurare l'autorizzazione del broker MQTT.
Per usare TLS, vedere le sezioni Configurare TLS con la gestione automatica dei certificati o Configurare TLS con la gestione manuale dei certificati.
Usare la stessa porta tra listener
L'uso dello stesso numero di porta tra listener diversi non è supportato. Ogni numero di porta deve essere univoco all'interno del broker MQTT operazioni IoT.
Ad esempio, se si dispone di un listener usando la porta 1883, non è possibile creare un altro listener con la porta 1883. Analogamente, il listener predefinito usa la porta 18883, quindi non è possibile creare un altro listener con la porta 18883.
Supporto di WebSocket
Il broker MQTT operazioni IoT supporta MQTT su WebSocket. Per abilitare WebSocket, impostare il protocollo su WebSockets per la porta.
Configurare TLS con la gestione automatica dei certificati
Per abilitare TLS con la gestione automatica dei certificati, specificare le impostazioni TLS in una porta del listener.
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 alle operazioni IoT nello spazio dei cert-manager 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 cert-manager -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) 4d20hSe 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 per verificare l'installazione. Ricordarsi di usare lo spazio dei nomi cert-manager.
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 esterno issuer per estendere le funzionalità oltre le autorità emittenti supportate in modo nativo. È possibile usare un broker MQTT con qualsiasi tipo di emittente di cert-manager.
Importante
Durante la distribuzione iniziale, le operazioni 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 predefinita e autorità di certificazione 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à emittente 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 CA e i file PEM della chiave privata della CA. Eseguire il comando seguente per importare il certificato della CA 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 DELLA CA. L'uso di cert-manager per generare un certificato DELLA CA è 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: 256Creare il certificato della CA autofirmato con il comando seguente:
kubectl apply -f ca.yaml
Cert-manager crea un certificato DELLA CA usando le impostazioni predefinite. È possibile modificare le proprietà di questo certificato modificando la specifica del certificato. Per un elenco delle 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. È possibile recuperare il certificato in formato PEM dal segreto e archiviarlo nel 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.
Creare un'autorità emittente basata sul certificato della CA
Cert-manager richiede un'autorità emittente basata sul certificato della 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 l'emissione di certificati server TLS. Prendere nota del nome e del tipo dell'autorità emittente. Nell'esempio il nome è my-issuer e il tipo è Issuer. Questi valori vengono impostati nella risorsa BrokerListener in un secondo momento.
Abilitare la gestione automatica dei certificati TLS per una porta
L'esempio seguente è una risorsa BrokerListener che abilita TLS sulla porta 8884 con gestione automatica dei certificati.
Nella portale di Azure passare all'istanza di Operazioni IoT.
In Componenti selezionare MqTT Broker.
Selezionare o creare un listener. È possibile creare un solo listener per tipo di servizio. Se si dispone già di un listener dello stesso tipo di servizio, è possibile aggiungere altre porte al listener esistente.
È possibile aggiungere impostazioni TLS al listener selezionando TLS su una porta esistente o aggiungendo una nuova porta.
Immetti le impostazioni seguenti:
Impostazione Description Nome Nome della risorsa BrokerListener. Immetti aio-broker-loadbalancer-tls.Porta Numero di porta in cui BrokerListener è in ascolto delle connessioni MQTT. Immettere 8884. Autenticazione Informazioni di riferimento sulle risorse di autenticazione. Autorizzazione Riferimento alla risorsa di autorizzazione. TLS Seleziona il pulsante Aggiungi. Nome dell'autorità emittente Nome dell'emittente cert-manager. Obbligatorio. Tipo autorità di certificazione Tipo di autorità emittente del gestore di certificati. Obbligatorio. Gruppo autorità di certificazione Gruppo dell'autorità emittente di cert-manager. Obbligatorio. Algoritmo di chiave privata Algoritmo per la chiave privata. Criteri di rotazione delle chiavi private Criteri per la rotazione della chiave privata. Nomi DNS Nomi alternativi del soggetto DNS per il certificato. Indirizzi IP Indirizzi IP dei nomi alternativi del soggetto per il certificato. Nome segreto Segreto Kubernetes contenente un certificato client X.509. Durata La durata totale del certificato server TLS per impostazione predefinita è 90 giorni. Rinnovare prima Quando iniziare a rinnovare il certificato. Selezionare Applica per salvare le impostazioni TLS.
Dopo aver configurato la risorsa BrokerListener, il broker MQTT 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 Issuer name e Issuer kind. Vengono scelte automaticamente tutte le altre proprietà dei certificati server TLS generati. Tuttavia, il broker MQTT consente di personalizzare determinate proprietà seguendo la stessa sintassi dei certificati cert-manager. Ad esempio, è possibile specificare l'algoritmo di chiave privata e i criteri di rotazione. Queste impostazioni si trovano in tls.certManagerCertificateSpec o nel riquadro di configurazione TLS nel portale di Azure.
Per un elenco completo di queste impostazioni, vedere Informazioni di riferimento sulle API Broker Listener CertManagerCertificateSpec.
Verificare la distribuzione
Usare kubectl per verificare che il servizio associato alla risorsa BrokerListener sia in esecuzione. Nell'esempio precedente il nome del servizio è aio-broker-loadbalancer-tls 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
aio-broker-loadbalancer-tls LoadBalancer 10.X.X.X 172.X.X.X 8884:32457/TCP 33s
Connettersi 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 specifico. È 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-listenerad esempio) o il servizioCLUSTER-IP. - Se ci si connette dall'esterno del cluster, usare il servizio
EXTERNAL-IP.
Ricordarsi di specificare i metodi di autenticazione, se necessario.
CA radice e autorità di certificazione predefinite
Per iniziare, le operazioni IoT vengono distribuite con un certificato ca e un'autorità di certificazione predefinita "guida introduttiva" 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 per i certificati server TLS.
Per la produzione, è necessario configurare un'autorità emittente di certificazione con un certificato da un'autorità di certificazione attendibile, come descritto nelle sezioni precedenti.
Configurare TLS con la gestione manuale dei certificati
Per configurare manualmente un broker MQTT per l'uso di un certificato TLS specifico, specificarlo in una risorsa BrokerListener con un riferimento a un segreto Kubernetes e distribuirlo usando kubectl. Questo articolo illustra un esempio che configura TLS con certificati autofirmato per il test.
Creare un'autorità di certificazione con l'interfaccia della riga di comando passaggio
Il passaggio è un gestore certificati che consente di iniziare rapidamente a funzionare quando si crea e si gestisce la propria CA privata.
Installare l'interfaccia della riga di comando del passaggio e creare un certificato e una chiave ca radice.
step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.keyCreare un certificato ca intermedio e una chiave firmati dalla CA radice.
step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \ --ca root_ca.crt --ca-key root_ca.key
Creare un certificato del server
Usare l'interfaccia della riga di comando del passaggio per creare un certificato server dal certificato e dalla chiave ca intermedia.
step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure
mqtts-endpoint In questo caso, e localhost sono i nomi alternativi del soggetto (SAN) per il front-end del broker MQTT rispettivamente in Kubernetes e nei client locali. Per connettersi tramite Internet, aggiungere un --san con un indirizzo IP esterno. I flag --no-password --insecure vengono usati per il test per ignorare le richieste di password e disabilitare la protezione della password per la chiave privata perché è archiviata in un segreto Kubernetes. Per l'ambiente di produzione, usare una password e archiviare la chiave privata in una posizione sicura, ad esempio Azure Key Vault.
Requisiti dell'algoritmo di chiave del certificato
Sono supportate sia le chiavi EC che RSA, ma tutti i certificati nella catena devono usare lo stesso algoritmo di chiave. Se si importano certificati CA personalizzati, assicurarsi che il certificato del server usi lo stesso algoritmo di chiave delle CA.
Importare la catena di certificati server come segreto Kubernetes
Creare una catena di certificati server completa, in cui l'ordine dei certificati è importante. Il certificato del server è il primo nel file e l'intermedio è il secondo.
cat mqtts-endpoint.crt intermediate_ca.crt > server_chain.crtCreare un segreto Kubernetes con la catena di certificati del server e la chiave del server usando kubectl.
kubectl create secret tls server-cert-secret -n azure-iot-operations \ --cert server_chain.crt \ --key mqtts-endpoint.key
Abilitare la gestione manuale dei certificati TLS per una porta
L'esempio seguente mostra una risorsa BrokerListener che abilita TLS sulla porta 8884 con gestione manuale dei certificati.
Nella portale di Azure passare all'istanza di Operazioni IoT.
In Componenti selezionare MqTT Broker.
Selezionare o creare un listener. È possibile creare un solo listener per tipo di servizio. Se si dispone già di un listener dello stesso tipo di servizio, è possibile aggiungere altre porte al listener esistente. Per seguire l'esempio, specificare il nome del servizio listener come
mqtts-endpoint.È possibile aggiungere impostazioni TLS al listener selezionando TLS su una porta esistente o aggiungendo una nuova porta.
Immetti le impostazioni seguenti:
Impostazione Descrizione Porta Numero di porta in cui BrokerListener è in ascolto delle connessioni MQTT. Obbligatorio. Autenticazione Informazioni di riferimento sulle risorse di autenticazione. Autorizzazione Riferimento alla risorsa di autorizzazione. TLS Seleziona il pulsante Aggiungi. Nome segreto Segreto Kubernetes contenente un certificato client X.509. Selezionare Applica per salvare le impostazioni TLS.
Connettersi al broker con TLS
Per testare la connessione TLS con il client Mosquitto, pubblicare un messaggio e passare il certificato CA radice nel parametro --cafile.
mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt
Ricordarsi di specificare elementi come nome utente e password se l'autenticazione del broker MQTT è abilitata.
Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT
Suggerimento
Per usare localhost, la porta deve essere disponibile nel computer host. Un esempio è kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Con alcune distribuzioni Kubernetes come K3d, è possibile aggiungere una porta inoltrata con k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.
Per connettersi al broker, è necessario distribuire la radice di attendibilità, nota anche come bundle di attendibilità, a tutti i client. In questo caso, la radice dell'attendibilità è la CA radice autofirmato creata dall'interfaccia della riga di comando del passaggio. Per verificare la catena di certificati server, è necessaria la distribuzione della radice di attendibilità. Se i client MQTT sono carichi di lavoro nel cluster Kubernetes, è anche necessario creare un Oggetto ConfigMap con la CA radice e montarlo nel pod.
Usare l'indirizzo IP esterno per il certificato del server
Per connettersi con TLS tramite Internet, il certificato del server del broker MQTT deve avere il nome host esterno o l'indirizzo IP come SAN. Nell'ambiente di produzione, queste informazioni sono in genere un nome DNS o un indirizzo IP noto. Durante lo sviluppo/test, è possibile che non si conosca il nome host o l'indirizzo IP esterno assegnato prima della distribuzione. Per risolvere questo problema, distribuire prima il listener senza il certificato del server, creare prima il certificato del server e il segreto con l'indirizzo IP esterno e importare il segreto nel listener.
Se si tenta di distribuire il listener TLS di esempio manual-tls-listener ma il segreto Kubernetes di riferimento server-cert-secret non esiste, il servizio associato viene creato, ma i pod non vengono avviati. Il servizio viene creato perché l'operatore deve riservare l'indirizzo IP esterno per il listener.
kubectl get svc mqtts-endpoint -n azure-iot-operations
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mqtts-endpoint LoadBalancer 10.X.X.X 172.X.X.X 8885:30674/TCP 1m15s
Questo comportamento è previsto durante l'importazione del certificato del server. I log di Health Manager indicano che il broker MQTT è in attesa del certificato del server.
kubectl logs -l app=health-manager -n azure-iot-operations
...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.
Nota
In genere, in un sistema distribuito, i log dei pod non sono deterministici e devono essere usati con cautela. Il modo giusto per visualizzare informazioni come questa è tramite gli eventi Kubernetes e lo stato delle risorse personalizzate, che si trova nel backlog. Considerare il passaggio precedente come soluzione alternativa temporanea.
Anche se i pod front-end non sono aggiornati, l'indirizzo IP esterno è già disponibile.
kubectl get svc mqtts-endpoint -n azure-iot-operations
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mqtts-endpoint LoadBalancer 10.X.X.X 172.X.X.X 8885:30674/TCP 1m15s
Da qui seguire gli stessi passaggi illustrati in precedenza per creare un certificato server con questo indirizzo IP esterno in --san e creare il segreto Kubernetes nello stesso modo. Dopo aver creato il segreto, viene importato automaticamente nel listener.