Condividi tramite

Configurare l'autenticazione del broker MQTT

  • Articolo

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.

Il broker MQTT supporta più metodi di autenticazione per i client ed è possibile configurare ogni porta del listener in modo che disponga delle proprie impostazioni di autenticazione con una risorsa BrokerAuthentication . Per un elenco delle impostazioni disponibili, vedere le informazioni di riferimento sull'API di autenticazione broker.

Le regole seguenti si applicano alla relazione tra le risorse BrokerListener e BrokerAuthentication :

  • Ogni BrokerListener può avere più porte. Ogni porta può essere collegata a una risorsa BrokerAuthentication .
  • Ogni BrokerAuthentication può supportare più metodi di autenticazione contemporaneamente.
  • Le porte che non collegano una risorsa BrokerAuthentication hanno disabilitato l'autenticazione.

Per collegare una porta BrokerListener a una risorsa BrokerAuthentication , specificare il authenticationRef campo nell'impostazione ports della risorsa BrokerListener. Per altre informazioni, vedere Risorsa BrokerListener.

Risorsa BrokerAuthentication predefinita

Azure IoT Operations distribuisce una risorsa BrokerAuthentication predefinita denominata default collegata al listener predefinito nello spazio dei azure-iot-operations nomi. È configurato per l'uso solo dei token dell'account del servizio Kubernetes per l'autenticazione.

Importante

Il metodo di autenticazione SAT (Service Account Token) nella risorsa BrokerAuthentication predefinita è necessario per il corretto funzionamento dei componenti nelle operazioni IoT di Azure. Evitare di aggiornare o eliminare la risorsa BrokerAuthentication predefinita.

  1. Nella portale di Azure passare all'istanza di Operazioni IoT.

  2. In Risorse di Operazioni IoT di Azure selezionare MQTT Broker.

  3. Seleziona la scheda Autenticazione.

  4. Nell'elenco dei criteri di autenticazione selezionare il nome del criterio predefinito .

    Screenshot che usa portale di Azure per visualizzare i criteri di autenticazione del broker MQTT predefiniti.

Per aggiungere nuovi metodi di autenticazione, selezionare Aggiungi metodo.

Flusso di autenticazione

L'ordine dei metodi di autenticazione specificati determina il modo in cui il broker MQTT autentica i client. Il broker MQTT tenta di autenticare le credenziali del client usando il primo metodo specificato e scorre i metodi specificati fino a quando non trova una corrispondenza o raggiunge la fine.

Per ogni metodo, il broker MQTT controlla innanzitutto se le credenziali del client sono rilevanti per tale metodo. Ad esempio, l'autenticazione SAT richiede un nome utente che inizia con K8S-SAT e l'autenticazione X.509 richiede un certificato client. Se le credenziali del client sono rilevanti, il broker MQTT verifica se sono validi. Per altre informazioni, vedere la sezione Configurare il metodo di autenticazione.

Per l'autenticazione personalizzata, il broker MQTT considera l'impossibilità di comunicare con il server di autenticazione personalizzato come credenziali non pertinenti. Questo comportamento consente al broker MQTT di eseguire il fallback ad altri metodi se il server di autenticazione personalizzato non è raggiungibile.

Il flusso di autenticazione termina quando:

  • Una di queste condizioni è vera:
    • Le credenziali del client sono rilevanti e valide per uno dei metodi.
    • Le credenziali del client non sono rilevanti per nessuno dei metodi.
    • Le credenziali del client sono rilevanti ma non valide per uno dei metodi.
  • Il broker MQTT concede o nega l'accesso al client in base al risultato del flusso di autenticazione.

Ad esempio:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

L'esempio precedente specifica custom e SAT. Quando un client si connette, il broker MQTT tenta di autenticare il client usando i metodi specificati nell'ordine personalizzato, quindi SAT.

  1. Il broker MQTT controlla se le credenziali del client sono valide per l'autenticazione personalizzata. Poiché l'autenticazione personalizzata si basa su un server esterno per determinare la validità delle credenziali, il broker considera tutte le credenziali rilevanti per l'autenticazione personalizzata e le inoltra al server di autenticazione personalizzato.
  2. Se il server di autenticazione personalizzato risponde con il risultato Pass o Fail, termina il flusso di autenticazione. Tuttavia, se il server di autenticazione personalizzato non è disponibile, il broker MQTT esegue il fallback ai metodi specificati rimanenti, con SAT successivo.
  3. Il broker MQTT tenta di autenticare le credenziali come credenziali SAT.

Se il server di autenticazione personalizzato non è disponibile e tutti i metodi successivi determinano che le credenziali specificate non sono pertinenti, il broker nega la connessione client.

Configurare il metodo di autenticazione

È possibile aggiungere metodi di autenticazione come X.509, SAT o personalizzati ai criteri di autenticazione.

Per aggiungere un metodo di autenticazione a un criterio:

  1. Nella portale di Azure passare all'istanza di Operazioni IoT.

  2. In Risorse di Operazioni IoT di Azure selezionare MQTT Broker.

  3. Seleziona la scheda Autenticazione.

  4. Scegliere un criterio di autenticazione esistente o crearne uno nuovo.

  5. Aggiungere un nuovo metodo selezionando Aggiungi metodo.

  6. Scegliere il tipo di metodo dall'elenco a discesa e quindi selezionare Aggiungi dettagli per configurare il metodo.

    Screenshot che usa il portale di Azure per aggiungere un metodo di criteri di autenticazione broker MQTT.

Per altre informazioni su ognuna delle opzioni di autenticazione, vedere le sezioni successive per ogni metodo.

Per altre informazioni sull'abilitazione delle impostazioni sicure configurando un'istanza di Azure Key Vault e abilitando le identità del carico di lavoro, vedere Abilitare le impostazioni sicure nella distribuzione di Operazioni IoT di Azure.

X.509

Nell'autenticazione X.509, il broker MQTT usa un certificato CA attendibile per convalidare i certificati client. I client presentano un certificato rooted in questa CA per l'autenticazione da parte del broker MQTT. Sono supportate sia le chiavi EC che RSA, ma tutti i certificati nella catena devono usare lo stesso algoritmo di chiave. Poiché X.509 si basa su certificati client TLS, TLS deve essere abilitato per le porte che usano l'autenticazione X.509.

Per importare un certificato radice che può essere usato per convalidare i certificati client, archiviare il certificato PEM in un oggetto ConfigMap. Ad esempio:

kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations

In questo esempio il certificato della CA viene importato nella chiave client_ca.pem. Il broker MQTT considera attendibili tutti i certificati DELLA CA in ConfigMap, quindi il nome della chiave può essere qualsiasi cosa.

Per verificare che il certificato CA radice sia importato correttamente, eseguire kubectl describe configmap. Il risultato mostra la stessa codifica base64 del file di certificato PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
<Certificate>
-----END CERTIFICATE-----


BinaryData
====

Dopo l'importazione del certificato CA attendibile, abilitare l'autenticazione client X.509 aggiungendola come uno dei metodi di autenticazione in una risorsa BrokerAuthentication collegata a una porta del listener abilitata per TLS.

Attributi del certificato per l'autorizzazione

Gli attributi X.509 possono essere specificati nella risorsa BrokerAuthentication per autorizzare i client in base alle relative proprietà del certificato. Gli attributi sono definiti nel authorizationAttributes campo .

  1. Nella portale di Azure passare all'istanza di Operazioni IoT.

  2. In Risorse di Operazioni IoT di Azure selezionare MQTT Broker.

  3. Seleziona la scheda Autenticazione.

  4. Scegliere un criterio di autenticazione esistente o crearne uno nuovo.

  5. Aggiungere un nuovo metodo selezionando Aggiungi metodo.

  6. Scegliere il tipo di metodo X.509 dall'elenco a discesa e quindi selezionare Aggiungi dettagli per configurare il metodo.

    Screenshot che usa portale di Azure per impostare il metodo di autenticazione X.509 broker MQTT.

In questo esempio, ogni client con un certificato emesso dalla CA radice con nome CN = Contoso Root CA Cert, OU = Engineering, C = US distinto o ca intermedia con nome CN = Contoso Intermediate CA distinto riceve gli attributi elencati. Inoltre, il certificato client della ventola intelligente riceve attributi specifici.

La corrispondenza per gli attributi inizia sempre dal certificato client foglia e quindi va lungo la catena. L'assegnazione dell'attributo viene arrestata dopo la prima corrispondenza. Nell'esempio precedente, anche se smart-fan ha il certificato intermedio CN = Contoso Intermediate CA, non ottiene gli attributi associati.

Le regole di autorizzazione possono essere applicate ai client usando certificati X.509 con questi attributi. Per altre informazioni, vedere Autorizzare i client che usano l'autenticazione X.509.

Connettere il client mosquitto al broker MQTT con il certificato client X.509

Un client come mosquitto richiede due file per potersi connettere al broker MQTT con TLS e l'autenticazione client X.509.

  • Il parametro --cert specifica il file PEM del certificato client. Questo file deve includere anche tutti i certificati intermedi per aiutare il broker MQTT a compilare la catena di certificati completa.
  • Il parametro --key specifica il file PEM della chiave privata del client.

Nei casi in cui il broker MQTT usa un certificato CA autofirmato per rilasciare il certificato del server TLS, è necessario il --cafile parametro . Questo file contiene il certificato ca usato dal client mosquitto per convalidare il certificato server del broker durante la connessione tramite TLS. Se l'autorità emittente del certificato server del broker MQTT fa parte dell'archivio radice di sistema ,ad esempio ca pubbliche note, il --cafile parametro può essere omesso.

Ad esempio:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem

Informazioni sul flusso di autenticazione client X.509 broker MQTT

Diagramma del flusso di autenticazione client X.509.

Di seguito sono riportati i passaggi per l'autenticazione client:

  1. Quando l'autenticazione client X.509 è attivata, i client di connessione devono presentare un certificato client ed eventuali certificati intermedi per consentire a MQTT broker di compilare una catena di certificati rooted a uno dei certificati attendibili configurati.
  2. Il servizio di bilanciamento del carico indirizza la comunicazione a uno dei broker front-end.
  3. Dopo che il broker front-end ha ricevuto il certificato client, tenta di compilare una catena di certificati con accesso root a uno dei certificati configurati. Se il broker front-end ha creato correttamente una catena e la catena presentata viene verificata, termina l'handshake TLS. Il client di connessione è in grado di inviare pacchetti MQTT al front-end tramite il canale TLS.
  4. Il canale TLS è aperto, ma l'autenticazione client o l'autorizzazione non è ancora stata completata.
  5. Il client invia quindi un pacchetto CONNECT al broker MQTT.
  6. Il pacchetto CONNECT viene di nuovo indirizzato a un front-end.
  7. Il front-end raccoglie tutte le credenziali presentate finora dal client, ad esempio i campi nome utente e password, i dati di autenticazione del pacchetto CONNECT e la catena di certificati client presentata durante l'handshake TLS.
  8. Il front-end invia queste credenziali al servizio di autenticazione. Il servizio di autenticazione controlla nuovamente la catena di certificati e raccoglie i nomi dei soggetti di tutti i certificati nella catena.
  9. Il servizio di autenticazione usa le regole di autorizzazione configurate per determinare quali attributi hanno i client di connessione. Questi attributi determinano le operazioni che il client può eseguire, incluso il pacchetto CONNECT stesso.
  10. Il servizio di autenticazione restituisce la decisione del broker front-end.
  11. Il broker front-end conosce gli attributi client e se è autorizzato a connettersi. In tal caso, la connessione MQTT viene completata e il client può continuare a inviare e ricevere pacchetti MQTT in base alle regole di autorizzazione.

Token dell'account del servizio Kubernetes

I token dell'account del servizio Kubernetes sono token WEB JSON associati agli account del servizio Kubernetes. I client presentano token di sicurezza al broker MQTT per l'autenticazione.

Il broker MQTT usa i token dell'account del servizio limitati, descritti in dettaglio nel post Ciò che gli utenti GKE hanno bisogno di sapere sui nuovi token dell'account del servizio Kubernetes. Ecco le caratteristiche salienti del post:

Avviato in Kubernetes 1.13 e diventando il formato predefinito nella versione 1.21, i token associati indirizzano tutte le funzionalità limitate dei token legacy e altro ancora:

  • I token stessi sono più difficili da rubare e uso improprio; sono associati al tempo, al gruppo di destinatari e associati a oggetti.
  • Adottano un formato standardizzato: OpenID Connect (OIDC), con individuazione OIDC completa, semplificando l'accettazione da parte dei provider di servizi.
  • Vengono distribuiti in modo più sicuro ai pod, usando un nuovo tipo di volume proiettato Kubelet.

Il broker verifica i token usando l'API di revisione dei token Kubernetes. Abilitare la funzionalità Kubernetes TokenRequestProjection per specificare audiences (impostazione predefinita dalla versione 1.21). Se questa funzionalità non è abilitata, non è possibile usare le buste di sicurezza.

Creare un account di servizio

Per creare i criteri di sicurezza, creare prima di tutto un account del servizio. Il comando seguente crea un account del servizio denominato mqtt-client.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Aggiungere attributi per l'autorizzazione

I client che eseguono l'autenticazione tramite SAT possono facoltativamente avere gli account di servizio annotati con attributi da usare con i criteri di autorizzazione. Per altre informazioni, vedere Autorizzare i client che usano i token dell'account del servizio Kubernetes.

Abilitare l'autenticazione Token account del servizio (SAT)

Modificare l'impostazione authenticationMethods in una risorsa BrokerAuthentication per specificare ServiceAccountToken come metodo di autenticazione valido. audiences specifica l'elenco di gruppi di destinatari validi per i token. Scegliere valori univoci che identificano il servizio broker MQTT. È necessario specificare almeno un gruppo di destinatari e tutti i tipi di sicurezza devono corrispondere a uno dei gruppi di destinatari specificati.

  1. Nella portale di Azure passare all'istanza di Operazioni IoT.
  2. In Risorse di Operazioni IoT di Azure selezionare MQTT Broker.
  3. Seleziona la scheda Autenticazione.
  4. Scegliere un criterio di autenticazione esistente o crearne uno nuovo.
  5. Aggiungere un nuovo metodo selezionando Aggiungi metodo.
  6. Scegliere il tipo di metodo KUBernetes SAT dall'elenco a discesa e quindi selezionare Aggiungi dettagli per configurare il metodo.

Screenshot che usa il portale di Azure per impostare il metodo di autenticazione SAT del broker MQTT.

Testare l'autenticazione SAT

L'autenticazione SAT usa i campi di autenticazione avanzata MQTT v5. Un client deve impostare il metodo di autenticazione avanzata su K8S-SAT e i dati di autenticazione avanzati sul token.

Ad esempio, usando mosquitto (alcuni campi omessi per brevità):

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

<TOKEN> Ecco il token dell'account del servizio. Per ottenere un token di test, eseguire:

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

Di seguito è <SERVICE_ACCOUNT> riportato il nome dell'account del servizio creato ed <AUDIENCE> è uno dei gruppi di destinatari configurati nella risorsa BrokerAuthentication .

Per un esempio su come configurare un pod Kubernetes per l'uso dell'autenticazione SAT, vedere Connettersi al listener predefinito all'interno del cluster.

Nella configurazione del pod, il serviceAccountName campo in deve corrispondere all'account del servizio associato al token usato e il serviceAccountToken.audience campo deve essere uno dei audiences configurati nella risorsa BrokerAuthentication .

Aggiornare i token dell'account del servizio

I token dell'account del servizio sono validi per un periodo di tempo limitato e configurati con expirationSeconds. Tuttavia, Kubernetes aggiorna automaticamente il token prima della scadenza. Il token viene aggiornato in background e il client non deve eseguire alcuna operazione diversa da recuperarla di nuovo.

Ad esempio, se il client è un pod che usa il token montato come volume, come nell'esempio di autenticazione SAT di test, il token più recente è disponibile nello stesso percorso /var/run/secrets/tokens/broker-sat. Quando si effettua una nuova connessione, il client può recuperare il token più recente e usarlo per l'autenticazione. Il client deve anche disporre di un meccanismo per gestire gli errori MQTT non autorizzati recuperando il token più recente e ritentando la connessione.

Autenticazione personalizzata

Estendere l'autenticazione client oltre i metodi di autenticazione forniti con l'autenticazione personalizzata. È collegabile perché il servizio può essere qualsiasi elemento, purché sia conforme all'API.

Quando un client si connette al broker MQTT e all'autenticazione personalizzata è abilitato, il broker MQTT delega la verifica delle credenziali client a un server di autenticazione personalizzato con una richiesta HTTPS insieme a tutte le credenziali presentate dal client. Il server di autenticazione personalizzato risponde con approvazione o rifiuto per il client con gli attributi del client per l'autorizzazione.

Creare un servizio di autenticazione personalizzato

Il server di autenticazione personalizzato viene implementato e distribuito separatamente dal broker MQTT.

Un server di autenticazione personalizzato di esempio e le istruzioni sono disponibili in GitHub. Usare questo esempio come modello e punto di partenza per implementare la propria logica di autenticazione personalizzata.

API

L'API tra il broker MQTT e il server di autenticazione personalizzato segue la specifica API per l'autenticazione personalizzata. La specifica OpenAPI è disponibile in GitHub.

HTTPS con crittografia TLS è obbligatorio

Il broker MQTT invia richieste contenenti credenziali client riservate al server di autenticazione personalizzato. Per proteggere queste credenziali, la comunicazione tra il broker MQTT e il server di autenticazione personalizzato deve essere crittografata con TLS.

Il server di autenticazione personalizzato deve presentare un certificato server e il broker MQTT deve avere un certificato CA radice attendibile per convalidare il certificato del server. Facoltativamente, il server di autenticazione personalizzato potrebbe richiedere al broker MQTT di presentare un certificato client per autenticarsi.

Abilitare l'autenticazione personalizzata per un listener

Modificare l'impostazione authenticationMethods in una risorsa BrokerAuthentication per specificare Custom come metodo di autenticazione valido. Specificare quindi i parametri necessari per comunicare con un server di autenticazione personalizzato.

Questo esempio mostra tutti i possibili parametri. I parametri esatti necessari dipendono dai requisiti di ogni server personalizzato.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Disabilitare l'autenticazione

Per i test, è possibile disabilitare l'autenticazione per una porta del listener broker. La disabilitazione dell'autenticazione non è consigliata per gli ambienti di produzione.

  1. Nella portale di Azure passare all'istanza di Operazioni IoT.
  2. In Risorse di Operazioni IoT di Azure selezionare MQTT Broker.
  3. Selezionare il listener broker da modificare nell'elenco.
  4. Nella porta da disabilitare l'autenticazione selezionare Nessuno nell'elenco a discesa autenticazione.

I client si disconnettono dopo la scadenza delle credenziali

Il broker MQTT disconnette i client alla scadenza delle credenziali. Disconnettersi dopo la scadenza delle credenziali si applica a tutti i client che si connettono ai front-end del broker MQTT, tra cui:

  • I client autenticati con SAT si disconnettono alla scadenza del SAT
  • I client autenticati con X.509 si disconnettono alla scadenza del certificato client
  • I client autenticati con autenticazione personalizzata si disconnettono in base all'ora di scadenza restituita dal server di autenticazione personalizzato.

In caso di disconnessione, la connessione di rete del client viene chiusa. Il client non riceverà un pacchetto MQTT DISCONNECT, ma il broker registra un messaggio che ha disconnesso il client.

I client MQTT v5 autenticati con certificati di sicurezza e l'autenticazione personalizzata possono ripetere l'autenticazione con una nuova credenziale prima della scadenza della credenziale iniziale. I client X.509 non possono ripetere l'autenticazione e devono ristabilire la connessione perché l'autenticazione viene eseguita a livello TLS.

I client possono ripetere l'autenticazione inviando un pacchetto MQTT v5 AUTH con motivo ReAuth.

I client SAT inviano un client AUTH con i campi method: K8S-SAT, data: <token>. I client di autenticazione personalizzati impostano il metodo e il campo dati come richiesto dal server di autenticazione personalizzato.

La riautenticazione ha esito positivo aggiorna la scadenza delle credenziali del client con l'ora di scadenza della nuova credenziale e il broker risponde con un pacchetto Success AUTH. Autenticazione non riuscita a causa di problemi temporanei, ad esempio il server di autenticazione personalizzato non disponibile, causa la risposta del broker con un pacchetto AUTH continueAuthentication . Il client può riprovare più tardi. Altri errori di autenticazione causano l'invio di un pacchetto DISCONNECT da parte del broker e la chiusura della connessione di rete del client.

Contenuto correlato