Configurare l'autenticazione in anteprima di Azure IoT MQ
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.
L'anteprima mq di Azure IoT supporta più metodi di autenticazione per i client ed è possibile configurare ogni listener per avere un proprio sistema di autenticazione con le risorse BrokerAuthentication .
Risorsa BrokerAuthentication predefinita
Azure IoT Operations Preview distribuisce una risorsa BrokerAuthentication predefinita denominata authn collegata con il listener predefinito denominato listener nello spazio dei azure-iot-operations nomi. È configurato per l'uso solo dei token dell'account del servizio Kubernetes per l'autenticazione. Per esaminarlo, eseguire:
kubectl get brokerauthentication authn -n azure-iot-operations -o yaml
L'output mostra la risorsa BrokerAuthentication predefinita, con i metadati rimossi per brevità:
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- sat:
audiences: ["aio-mq"]
Per modificare la configurazione, modificare l'impostazione authenticationMethods in questa risorsa BrokerAuthentication o creare una nuova risorsa BrokerAuthentication con un nome diverso. Quindi, distribuirlo usando kubectl apply.
Relazione tra BrokerListener e BrokerAuthentication
BrokerListener e BrokerAuthentication sono risorse separate, ma sono collegate insieme usando listenerRef. Si applicano le seguenti regole:
- Un BrokerListener può essere collegato a un solo BrokerAuthentication
- Un BrokerAuthentication può essere collegato a più BrokerListeners
- Ogni BrokerAuthentication può supportare più metodi di autenticazione contemporaneamente
Flusso di autenticazione
L'ordine dei metodi di autenticazione nella matrice determina il modo in cui Azure IoT MQ autentica i client. Azure IoT MQ tenta di autenticare le credenziali del client usando il primo metodo specificato e scorre la matrice fino a quando non trova una corrispondenza o raggiunge la fine.
Per ogni metodo, Azure IoT MQ controlla innanzitutto se le credenziali del client sono rilevanti per tale metodo. Ad esempio, l'autenticazione SAT richiede un nome utente che inizia con $sate l'autenticazione X.509 richiede un certificato client. Se le credenziali del client sono rilevanti, Azure IoT MQ verifica se sono valide. Per altre informazioni, vedere la sezione Configurare il metodo di autenticazione.
Per l'autenticazione personalizzata, Azure IoT MQ considera la mancata comunicazione con il server di autenticazione personalizzato come credenziali non pertinenti. Questo comportamento consente ad Azure IoT MQ di eseguire il fallback ad altri metodi se il server 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.
- Azure IoT MQ concede o nega l'accesso al client in base al risultato del flusso di autenticazione.
Con più metodi di autenticazione, Azure IoT MQ ha un meccanismo di fallback. Ad esempio:
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- custom:
# ...
- sat:
# ...
- usernamePassword:
# ...
L'esempio precedente specifica l'autenticazione personalizzata, SAT e username-password. Quando un client si connette, Azure IoT MQ tenta di autenticare il client usando i metodi specificati nell'ordine specificato con password utente-nome utente SAT > personalizzata>.
Azure IoT MQ 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.
Se il server di autenticazione personalizzato risponde con
PassoFailrisultato, termina il flusso di autenticazione. Tuttavia, se il server di autenticazione personalizzato non è disponibile, Azure IoT MQ esegue il fallback ai metodi specificati rimanenti, con sat successivo.Azure IoT MQ tenta di autenticare le credenziali come credenziali SAT. Se il nome utente MQTT inizia con
$sat, Azure IoT MQ valuta la password MQTT come sat. In caso contrario, il broker esegue il fallback a username-password e controlla se il nome utente e la password MQTT specificati sono validi.
Se il server di autenticazione personalizzato non è disponibile e tutti i metodi successivi hanno determinato che le credenziali specificate non sono pertinenti, il broker nega la connessione client.
Disabilitare l'autenticazione
Per i test, disabilitare l'autenticazione modificandola nella risorsa BrokerListener.
spec:
authenticationEnabled: false
Configurare il metodo di autenticazione
Per altre informazioni su ognuna delle opzioni di autenticazione, vedere le sezioni seguenti:
Nome utente e password
Ogni client ha le proprietà necessarie seguenti:
- Username
- Password (con codifica PBKDF2)
- Attributi per l'autorizzazione
Ad esempio, iniziare con un clients.toml oggetto con identità e password con codifica PBKDF2.
# Credential #1
# username: client1
# password: password
[client1]
password = "$pbkdf2-sha512$i=100000,l=64$HqJwOCHweNk1pLryiu3RsA$KVSvxKYcibIG5S5n55RvxKRTdAAfCUtBJoy5IuFzdSZyzkwvUcU+FPawEWFPn+06JyZsndfRTfpiEh+2eSJLkg"
[client1.attributes]
floor = "floor1"
site = "site1"
# Credential #2
# username: client2
# password: password2
[client2]
password = "$pbkdf2-sha512$i=100000,l=64$+H7jXzcEbq2kkyvpxtxePQ$jTzW6fSesiuNRLMIkDDAzBEILk7iyyDZ3rjlEwQap4UJP4TaCR+EXQXNukO7qNJWlPPP8leNnJDCBgX/255Ezw"
[client2.attributes]
floor = "floor2"
site = "site1"
Per codificare la password usando PBKDF2, usare l'estensione dell'interfaccia della riga di comando per le operazioni di Azure IoT che include il az iot ops mq get-password-hash comando . Genera un hash della password PBKDF2 da una frase password usando l'algoritmo SHA-512 e un salt casuale a 128 bit.
az iot ops mq get-password-hash --phrase TestPassword
L'output mostra l'hash della password PBKDF2 da copiare:
{
"hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}
Salvare quindi il file con passwords.toml nome e importarlo in un segreto Kubernetes sotto tale chiave.
kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations
Includere un riferimento al segreto nella risorsa personalizzata BrokerAuthentication
spec:
authenticationMethods:
- usernamePassword:
secretName: passwords-db
L'applicazione delle modifiche potrebbe richiedere alcuni minuti.
È possibile usare Azure Key Vault per gestire i segreti per Azure IoT MQ anziché i segreti Kubernetes. Per altre informazioni, vedere Gestire i segreti usando Azure Key Vault o i segreti Kubernetes.
Certificato client X.509
Prerequisiti
- Azure IoT MQ configurato con TLS abilitato.
- Interfaccia della riga di comando dettagliata
- Certificati client e catena di certificati emittente nei file PEM. Se non è disponibile, usare l'interfaccia della riga di comando del passaggio per generare alcuni elementi.
- Familiarità con la crittografia a chiave pubblica e i termini, ad esempio ca radice, chiave privata e certificati intermedi.
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 client usi lo stesso algoritmo di chiave delle CA.
Importare un certificato CA radice del client attendibile
Per convalidare il certificato client, è necessario un certificato CA radice attendibile. Per importare un certificato radice che può essere usato per convalidare i certificati client, importare prima il certificato PEM come ConfigMap sotto la chiave client_ca.pem. Per autenticarli, i certificati client devono essere radicati in questa CA per Azure IoT MQ.
kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations
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-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----
BinaryData
====
Importare il mapping da certificato a attributo
Per usare i criteri di autorizzazione per i client usando le proprietà nei certificati X.509, creare un file TOML di mapping da certificato a attributo e importarlo come segreto Kubernetes nella chiave x509Attributes.toml. Questo file esegue il mapping del nome soggetto del certificato client agli attributi che possono essere usati nei criteri di autorizzazione. È necessario anche se non si usano criteri di autorizzazione.
kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations
Per informazioni sulla sintassi dei file degli attributi, vedere Autorizzare i client che usano l'autenticazione X.509.
Analogamente all'autenticazione con nome utente-password, è possibile usare Azure Key Vault per gestire questo segreto invece dei segreti Kubernetes. Per altre informazioni, vedere Gestire i segreti usando Azure Key Vault o i segreti Kubernetes.
Abilitare l'autenticazione client X.509
Infine, dopo aver importato il certificato CA radice del client attendibile e il mapping da certificato a attributo, abilitare l'autenticazione client X.509 aggiungendo x509 come parte di una risorsa brokerAuthentication collegata a un listener abilitato per TLS. Ad esempio:
spec:
authenticationMethods:
- x509:
trustedClientCaCert: client-ca
attributes:
secretName: x509-attributes
Connessione client mosquitto all'anteprima mq di Azure IoT con certificato client X.509
Un client come mosquitto richiede tre file per potersi connettere ad Azure IoT MQ con TLS e l'autenticazione client X.509. Ad esempio:
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem
Nell'esempio:
- Il
--certparametro specifica il file PEM del certificato client. - Il
--keyparametro specifica il file PEM della chiave privata del client. - Il terzo parametro
--cafileè il più complesso: il database del certificato attendibile, usato per due scopi:- Quando il client mosquitto si connette ad Azure IoT MQ tramite TLS, convalida il certificato del server. Cerca i certificati radice nel database per creare una catena attendibile per il certificato del server. Per questo motivo, il certificato radice del server deve essere copiato in questo file.
- Quando Azure IoT MQ richiede un certificato client dal client mosquitto, richiede anche una catena di certificati valida da inviare al server. Il
--certparametro indica a mosquitto quale certificato inviare, ma non è sufficiente. Azure IoT MQ non è in grado di verificare questo certificato solo perché richiede anche il certificato intermedio. Mosquitto usa il file di database per compilare la catena di certificati necessaria. Per supportare questa operazione, devecafilecontenere sia i certificati intermedi che quelli radice.
Informazioni sul flusso di autenticazione client X.509 di Azure IoT MQ Preview
Di seguito sono riportati i passaggi per il flusso di autenticazione client:
- Quando l'autenticazione client X.509 è attivata, i client di connessione devono presentare il certificato client ed eventuali certificati intermedi per consentire ad Azure IoT MQ di compilare una catena di certificati rooted a uno dei certificati attendibili configurati.
- Il servizio di bilanciamento del carico indirizza la comunicazione a uno dei broker front-end.
- Dopo che il broker front-end ha ricevuto il certificato client, tenta di compilare una catena di certificati rooted in uno dei certificati configurati. Il certificato è necessario per un handshake TLS. 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 compilato.
- Il canale TLS è aperto, ma l'autenticazione client o l'autorizzazione non è ancora stata completata.
- Il client invia quindi un pacchetto CONNECT ad Azure IoT MQ.
- Il pacchetto CONNECT viene di nuovo indirizzato a un front-end.
- 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.
- 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.
- 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.
- Il servizio di autenticazione restituisce la decisione del broker front-end.
- 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 determinati dalle 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 ITS al broker MQTT di Azure IoT MQTT per l'autenticazione.
Azure IoT MQ usa i token dell'account del servizio associati, descritti in dettaglio nel post What GKE users to know about Kubernetes's new service account tokens (Cosa gli utenti GKE devono conoscere sui nuovi token del nuovo 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 Connessione (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
L'autenticazione dei client tramite SAT può facoltativamente avere annotate con attributi da usare con criteri di autorizzazione personalizzati. Per altre informazioni, vedere Autorizzare i client che usano i token dell'account del servizio Kubernetes.
Abilitare l'autenticazione SAT (Service Account Token)
Modificare l'impostazione authenticationMethods in una risorsa BrokerAuthentication per specificare sat 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 di Azure IoT MQ. È necessario specificare almeno un gruppo di destinatari e tutti i tipi di sicurezza devono corrispondere a uno dei gruppi di destinatari specificati.
spec:
authenticationMethods:
- sat:
audiences: ["aio-mq", "my-audience"]
Applicare le modifiche con kubectl apply. L'applicazione delle modifiche potrebbe richiedere alcuni minuti.
Testare l'autenticazione SAT
L'autenticazione SAT deve essere usata da un client nello stesso cluster di Azure IoT MQ. Il comando seguente specifica un pod con il client mosquitto e monta il sat creato nei passaggi precedenti nel pod.
apiVersion: v1
kind: Pod
metadata:
name: mqtt-client
namespace: azure-iot-operations
spec:
serviceAccountName: mqtt-client
containers:
- image: efrecon/mqtt-client
name: mqtt-client
command: ["sleep", "infinity"]
volumeMounts:
- name: mqtt-client-token
mountPath: /var/run/secrets/tokens
volumes:
- name: mqtt-client-token
projected:
sources:
- serviceAccountToken:
path: mqtt-client-token
audience: my-audience
expirationSeconds: 86400
In questo caso, il serviceAccountName campo nella configurazione del pod deve corrispondere all'account del servizio associato al token usato. Inoltre, il serviceAccountToken.audience campo nella configurazione del pod deve essere uno dei audiences configurati nella risorsa BrokerAuthentication.
Dopo aver creato il pod, avviare una shell nel pod:
kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh
Il token viene montato nel percorso specificato nella configurazione /var/run/secrets/tokens nell'esempio precedente. Recuperare il token e usarlo per l'autenticazione.
token=$(cat /var/run/secrets/tokens/mqtt-client-token)
mosquitto_pub -h aio-mq-dmqtt-frontend -V mqttv5 -t hello -m world -u '$sat' -P "$token"
Il nome utente MQTT deve essere impostato su $sat. La password MQTT deve essere impostata sul sat stesso.
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/mqtt-client-token. 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 ad Azure IoT MQ e l'autenticazione personalizzata è abilitata, Azure IoT MQ delega la verifica delle credenziali client a un server di autenticazione personalizzato con una richiesta HTTP 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 da Azure IoT MQ.
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 Azure IoT MQ 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
Azure IoT MQ invia richieste contenenti credenziali client riservate al server di autenticazione personalizzato. Per proteggere queste credenziali, la comunicazione tra Azure IoT MQ e il server di autenticazione personalizzato deve essere crittografata con TLS.
Il server di autenticazione personalizzato deve presentare un certificato server e Azure IoT MQ deve avere un certificato CA radice attendibile per convalidare il certificato del server. Facoltativamente, il server di autenticazione personalizzato potrebbe richiedere ad Azure IoT MQ di presentare un certificato client per l'autenticazione.
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:
- custom:
# Endpoint for custom authentication requests. Required.
endpoint: https://auth-server-template
# Trusted CA certificate for validating custom authentication server certificate.
# Required unless the server certificate is publicly-rooted.
caCert: custom-auth-ca
# Authentication between Azure IoT MQ with the custom authentication server.
# The broker may present X.509 credentials or no credentials to the server.
auth:
x509:
secretName: 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