Configurer l’authentification Azure IoT MQ (préversion)
Important
Opérations Azure IoT (préversion) – activé parc Azure Arc est actuellement en PRÉVERSION. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.
Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
Azure IoT MQ (préversion) prend en charge plusieurs méthodes d’authentification pour les clients, et vous pouvez configurer chaque écouteur pour qu’il ait son propre système d’authentification avec des ressources BrokerAuthentication.
Ressource BrokerAuthentication par défaut
Opérations Azure IoT (préversion) déploie une ressource BrokerAuthentication par défaut nommée authn liée à l’écouteur par défaut nommé listener dans l’espace de noms azure-iot-operations. Elle est configurée pour utiliser uniquement des jetons de compte de service (SAT) Kubernetes pour l’authentification. Pour l’inspecter, exécutez :
kubectl get brokerauthentication authn -n azure-iot-operations -o yaml
La sortie affiche la ressource BrokerAuthentication par défaut, avec les métadonnées supprimées pour la concision :
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- sat:
audiences: ["aio-mq"]
Pour modifier la configuration, modifiez le paramètre authenticationMethods dans cette ressource BrokerAuthentication ou créez une ressource BrokerAuthentication avec un autre nom. Ensuite, déployez-la à l’aide de kubectl apply.
Relation entre BrokerListener et BrokerAuthentication
BrokerListener et BrokerAuthentication sont des ressources distinctes, mais elles sont liées ensemble à l’aide de listenerRef. Les règles suivantes s’appliquent :
- Un BrokerListener ne peut être lié qu’à un BrokerAuthentication
- Un BrokerAuthentication peut être lié à plusieurs BrokerListeners
- Chaque BrokerAuthentication peut prendre en charge plusieurs méthodes d’authentification à la fois
Flux d’authentification
L’ordre des méthodes d’authentification dans le tableau détermine comment Azure IoT MQ authentifie les clients. Azure IoT MQ tente d’authentifier les informations d’identification du client à l’aide de la première méthode spécifiée et effectue une itération dans le tableau jusqu’à ce qu’il trouve une correspondance ou atteigne la fin.
Pour chaque méthode, Azure IoT MQ vérifie d’abord si les informations d’identification du client sont pertinentes pour cette méthode. Par exemple, l’authentification SAT nécessite un nom d’utilisateur commençant par $sat, et l’authentification X.509 nécessite un certificat client. Si les informations d’identification du client sont pertinentes, Azure IoT MQ vérifie ensuite si elles sont valides. Pour plus d’informations, consultez la section Configurer la méthode d’authentification.
Pour l’authentification personnalisée, Azure IoT MQ traite l’échec de la communication avec le serveur d’authentification personnalisé comme des informations d’identification non pertinentes. Ce comportement permet à Azure IoT MQ de revenir à d’autres méthodes si le serveur personnalisé est inaccessible.
Le flux d’authentification se termine lorsque :
- L’une de ces conditions est vraie :
- Les informations d’identification du client sont pertinentes et valides pour l’une des méthodes.
- Les informations d’identification du client ne sont pertinentes pour aucune des méthodes.
- Les informations d’identification du client sont pertinentes mais non valides pour l’une des méthodes.
- Azure IoT MQ accorde ou refuse l’accès au client en fonction du résultat du flux d’authentification.
Avec plusieurs méthodes d’authentification, Azure IoT MQ a un mécanisme de secours. Par exemple :
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- custom:
# ...
- sat:
# ...
- usernamePassword:
# ...
L’exemple précédent spécifie l’authentification personnalisée, SAT et par nom d’utilisateur/mot de passe. Lorsqu’un client se connecte, Azure IoT MQ tente d’authentifier le client à l’aide des méthodes spécifiées dans l’ordre suivant personnalisé > SAT > nom d’utilisateur/mot de passe.
Azure IoT MQ vérifie si les informations d’identification du client sont valides pour l’authentification personnalisée. Étant donné que l’authentification personnalisée s’appuie sur un serveur externe pour déterminer la validité des informations d’identification, le répartiteur considère toutes les informations d’identification pertinentes pour l’authentification personnalisée et les transfère au serveur d’authentification personnalisé.
Si le serveur d’authentification personnalisé répond avec le résultat
PassouFail, le flux d’authentification se termine. Toutefois, si le serveur d’authentification personnalisé n’est pas disponible, Azure IoT MQ revient aux méthodes spécifiées restantes, la méthode SAT étant la suivante.Azure IoT MQ tente d’authentifier les informations d’identification en tant qu’informations d’identification SAT. Si le nom d’utilisateur MQTT commence par
$sat, Azure IoT MQ évalue le mot de passe MQTT en tant que SAT. Sinon, le répartiteur revient au nom d’utilisateur/mot de passe et vérifie si le nom d’utilisateur et le mot de passe MQTT fournis sont valides.
Si le serveur d’authentification personnalisé n’est pas disponible et que toutes les méthodes suivantes ont déterminé que les informations d’identification fournies ne sont pas pertinentes, le répartiteur refuse la connexion cliente.
Désactiver l’authentification
Pour les tests, désactivez l’authentification en la modifiant dans la ressource BrokerListener.
spec:
authenticationEnabled: false
Configurer la méthode d'authentification
Pour en savoir plus sur chacune des options d’authentification, consultez les sections suivantes :
Nom d’utilisateur et mot de passe
Chaque client dispose des propriétés requises suivantes :
- Nom d’utilisateur
- Mot de passe (encodé PBKDF2)
- Attributs pour l’autorisation
Par exemple, commencez avec un clients.toml avec des identités et des mots de passe codés 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"
Pour encoder le mot de passe à l’aide de PBKDF2, utilisez l’extension d’interface CLI Opérations Azure IoT qui inclut la commande az iot ops mq get-password-hash. Elle génère un hachage de mot de passe PBKDF2 à partir d’une phrase de mot de passe à l’aide de l’algorithme SHA-512 et d’un salt aléatoire 128 bits.
az iot ops mq get-password-hash --phrase TestPassword
La sortie affiche le hachage de mot de passe PBKDF2 à copier :
{
"hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}
Ensuite, enregistrez le fichier sous passwords.toml et importez-le dans un secret Kubernetes sous cette clé.
kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations
Inclure une référence au secret dans la ressource personnalisée BrokerAuthentication
spec:
authenticationMethods:
- usernamePassword:
secretName: passwords-db
Patientez quelques minutes pour que les modifications soient prises en compte.
Vous pouvez utiliser Azure Key Vault pour gérer les secrets pour Azure IoT MQ au lieu des secrets Kubernetes. Pour plus d’informations, consultez Gérer les secrets à l’aide d’Azure Key Vault ou de secrets Kubernetes.
Certificat client X.509
Prérequis
- Azure IoT MQ configuré avec TLS activé.
- Step-CLI
- Certificats clients et chaîne de certificats d’émission dans les fichiers PEM. Si vous n’en avez pas, utilisez l’interface CLI Step pour en générer.
- Connaissance du chiffrement par clé publique et des termes tels que l’autorité de certification racine, la clé privée et les certificats intermédiaires.
Les clés EC et RSA sont prises en charge, mais tous les certificats de la chaîne doivent utiliser le même algorithme de clé. Si vous importez vos propres certificats d’autorité de certification, vérifiez que le certificat client utilise le même algorithme de clé que les autorités de certification.
Importer un certificat d’autorité de certification racine du client approuvé
Un certificat d’autorité de certification racine approuvé est requis pour valider le certificat client. Pour importer un certificat racine qui peut être utilisé pour valider les certificats clients, commencez par importer le certificat PEM en tant que ConfigMap sous la clé client_ca.pem. Les certificats clients doivent être associés à une racine dans cette autorité de certification pour Azure IoT MQ pour les authentifier.
kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations
Pour vérifier que le certificat d’autorité de certification racine est correctement importé, exécutez kubectl describe configmap. Le résultat montre le même encodage base64 du fichier de certificat 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
====
Importer le mappage de certificat à attribut
Pour utiliser des stratégies d’autorisation pour les clients qui utilisent des propriétés sur les certificats X.509, créez un fichier TOML de mappage de certificat à attribut et importez-le en tant que secret Kubernetes sous la clé x509Attributes.toml. Ce fichier mappe le nom du sujet du certificat client aux attributs qui peuvent être utilisés dans les stratégies d’autorisation. Il est nécessaire même si vous n’utilisez pas de stratégies d’autorisation.
kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations
Pour en savoir plus sur la syntaxe des fichiers d’attributs, consultez Autoriser les clients qui utilisent l’authentification X.509.
Comme avec l’authentification par nom d'utilisateur/mot de passe, vous pouvez utiliser Azure Key Vault pour gérer ce secret au lieu des secrets Kubernetes. Pour plus d’informations, consultez Gérer les secrets à l’aide d’Azure Key Vault ou de secrets Kubernetes.
Activer l’authentification du client X.509
Enfin, une fois que le certificat d’autorité de certification racine du client approuvé et le mappage de certificat à attribut sont importés, activez l’authentification du client X.509 en ajoutant x509 entant qu’une des méthodes d’authentification dans le cadre d’une ressource BrokerAuthentication liée à un écouteur compatible TLS. Par exemple :
spec:
authenticationMethods:
- x509:
trustedClientCaCert: client-ca
attributes:
secretName: x509-attributes
Connecter le client mosquitto à Azure IoT MQ (préversion) avec le certificat client X.509
Un client tel que mosquitto a besoin de trois fichiers pour pouvoir se connecter à Azure IoT MQ avec l’authentification du client TLS et X.509. Par exemple :
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
Dans l’exemple :
- Le paramètre
--certspécifie le fichier PEM du certificat client. - Le paramètre
--keyspécifie le fichier PEM de clé privée du client. - Le troisième paramètre
--cafileest le plus complexe : la base de données de certificats approuvée, utilisée à deux fins :- Lorsque le client mosquitto se connecte à Azure IoT MQ via TLS, il valide le certificat de serveur. Il recherche les certificats racines dans la base de données pour créer une chaîne approuvée vers le certificat de serveur. Pour cette raison, le certificat racine du serveur doit être copié dans ce fichier.
- Quand Azure IoT MQ demande un certificat client à partir du client mosquitto, il nécessite également une chaîne de certificats valide à envoyer au serveur. Le paramètre
--certindique à mosquitto quel certificat envoyer, mais ce n’est pas suffisant. Azure IoT MQ ne peut pas vérifier ce certificat seul, car il a également besoin du certificat intermédiaire. Mosquitto utilise le fichier de base de données pour générer la chaîne de certificats nécessaire. Pour prendre en charge ce problème, lecafiledoit contenir à la fois les certificats intermédiaires et racines.
Comprendre le flux d’authentification du client X.509 d’Azure IoT MQ (préversion)
Voici les étapes du flux d’authentification du client :
- Lorsque l’authentification du client X.509 est activée, la connexion des clients doit présenter son certificat client et tous les certificats intermédiaires pour permettre à Azure IoT MQ de générer une chaîne de certificats enracinée dans l’un de ses certificats approuvés configurés.
- L’équilibreur de charge dirige la communication vers l’un des répartiteurs front-end.
- Une fois que le répartiteur front-end a reçu le certificat client, il tente de générer une chaîne de certificats qui est enracinée dans l’un des certificats configurés. Le certificat est requis pour l’établissement d’une liaison TLS. Si le répartiteur front-end a correctement créé une chaîne et que la chaîne présentée est vérifiée, il termine l’établissement d’une liaison TLS. Le client qui se connecte est en mesure d’envoyer des paquets MQTT au front-end via le canal TLS généré.
- Le canal TLS est ouvert, mais l’authentification ou l’autorisation du client n’est pas encore terminée.
- Le client envoie ensuite un paquet CONNECT à Azure IoT MQ.
- Le paquet CONNECT est routé à nouveau vers le serveur front-end.
- Le serveur front-end collecte toutes les informations d’identification présentées par le client jusqu’à présent, telles que les champs nom d’utilisateur et mot de passe, les données d’authentification à partir du paquet CONNECT et la chaîne de certificats client présentée lors de l’établissement d’une liaison TLS.
- Le serveur front-end envoie ces informations d’identification au service d’authentification. Le service d’authentification vérifie à nouveau la chaîne de certificats et collecte les noms d’objet de tous les certificats de la chaîne.
- Le service d’authentification utilise ses règles d’autorisation configurées pour déterminer les attributs dont disposent les clients qui se connectent. Ces attributs déterminent les opérations que le client peut exécuter, y compris le paquet CONNECT lui-même.
- Le service d’authentification retourne la décision au répartiteur front-end.
- Le répartiteur front-end connaît les attributs du client et s’il est autorisé à se connecter. Si c’est le cas, la connexion MQTT est terminée et le client peut continuer à envoyer et recevoir des paquets MQTT déterminés par ses règles d’autorisation.
Jetons de compte de service Kubernetes
Les jetons de compte de service (SAT) Kubernetes sont des JSON Web Tokens associés à des comptes de service Kubernetes. Les clients présentent des SAT au répartiteur MQTT Azure IoT MQ pour s’authentifier eux-mêmes.
Azure IoT MQ utilise des jetons de compte de service liés qui sont détaillés dans la publication Ce que les utilisateurs de GKE doivent savoir sur les nouveaux jetons de compte de service Kubernetes. Voici les principales fonctionnalités de la publication :
Lancés dans Kubernetes 1.13 et devenus le format par défaut dans la version 1.21, les jetons liés répondent à toutes les fonctionnalités limitées des jetons traditionnels, et plus encore :
- Les jetons eux-mêmes sont plus difficiles à voler et à utiliser à mauvais escient. Ils sont limités dans le temps, limités à l’audience et limités à l’objet.
- Ils adoptent un format standardisé : OpenID Connect (OIDC), avec détection OIDC complète, ce qui permet aux fournisseurs de services de les accepter plus facilement.
- Ils sont distribués aux pods de manière plus sécurisée, à l’aide d’un nouveau type de volume projeté Kubelet.
Le répartiteur vérifie les jetons à l’aide de l’API de révision des jetons Kubernetes. Activez la fonctionnalité TokenRequestProjection Kubernetes pour spécifier audiences (par défaut depuis la version 1.21). Si cette fonctionnalité n’est pas activée, les SAT ne peuvent pas être utilisés.
Création d’un compte de service
Pour créer des SAT, commencez par créer un compte de service. La commande suivante crée un compte de service appelé mqtt-client.
kubectl create serviceaccount mqtt-client -n azure-iot-operations
Ajouter des attributs pour l’autorisation
Les clients qui s’authentifient via SAT peuvent éventuellement faire annoter leurs SAT avec des attributs à utiliser avec des stratégies d’autorisation personnalisées. Pour plus d’informations, consultez Autoriser les clients qui utilisent des jetons de compte de service Kubernetes.
Activer l’authentification par jeton de compte de service (SAT)
Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier sat comme méthode d’authentification valide. Le audiences spécifie la liste des audiences valides pour les jetons. Choisissez des valeurs uniques qui identifient le service de répartiteur d’Azure IoT MQ. Vous devez spécifier au moins une audience, et tous les SAT doivent correspondre à l’une des audiences spécifiées.
spec:
authenticationMethods:
- sat:
audiences: ["aio-mq", "my-audience"]
Appliquez vos modifications avec kubectl apply. Patientez quelques minutes pour que les modifications soient prises en compte.
Tester l’authentification SAT
L’authentification SAT doit être utilisée à partir d’un client dans le même cluster qu’Azure IoT MQ. La commande suivante spécifie un pod qui a le client mosquitto et monte le SAT créé dans les étapes précédentes dans le 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
Ici, le champ serviceAccountName de la configuration du pod doit correspondre au compte de service associé au jeton utilisé. En outre, le champ serviceAccountToken.audience de la configuration du pod doit être l’un des audiences configurés dans la ressource BrokerAuthentication.
Une fois le pod créé, démarrez un interpréteur de commandes dans le pod :
kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh
Le jeton est monté sur le chemin spécifié dans la configuration /var/run/secrets/tokens de l’exemple précédent. Récupérez le jeton et utilisez-le pour vous authentifier.
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"
Le nom d’utilisateur MQTT doit être défini sur $sat. Le mot de passe MQTT doit être défini sur le SAT lui-même.
Actualiser les jetons de compte de service
Les jetons de compte de service sont valides pendant une durée limitée et configurés avec expirationSeconds. Toutefois, Kubernetes actualise automatiquement le jeton avant son expiration. Le jeton est actualisé en arrière-plan et le client a seulement besoin de le récupérer à nouveau.
Par exemple, si le client est un pod qui utilise le jeton monté en tant que volume, comme dans l’exemple tester l’authentification SAT, le dernier jeton est disponible au même chemin d’accès /var/run/secrets/tokens/mqtt-client-token. Lorsque vous effectuez une nouvelle connexion, le client peut récupérer le dernier jeton et l’utiliser pour s’authentifier. Le client doit également disposer d’un mécanisme permettant de gérer les erreurs non autorisées MQTT en récupérant le dernier jeton et en réessayant la connexion.
Authentification personnalisée
Étendez l’authentification du client au-delà des méthodes d’authentification fournies avec l’authentification personnalisée. Le service est enfichable car il peut être n’importe quoi tant qu’il respecte l’API.
Lorsqu’un client se connecte à Azure IoT MQ et que l’authentification personnalisée est activé, Azure IoT MQ délègue la vérification des informations d’identification du client à un serveur d’authentification personnalisé avec une requête HTTP accompagnée de toutes les informations d’identification que le client présente. Le serveur d’authentification personnalisé répond par l’approbation ou le refus du client avec les attributs pour l’autorisation du client.
Créer un service d’authentification personnalisé
Le serveur d’authentification personnalisé est implémenté et déployé séparément d’Azure IoT MQ.
Un exemple de serveur d’authentification personnalisé et des instructions sont disponibles sur GitHub. Utilisez cet exemple en tant que modèle pour implémenter votre propre logique d’authentification personnalisée.
API
L’API entre Azure IoT MQ et le serveur d’authentification personnalisé suit la spécification de l’API pour l’authentification personnalisée. La spécification OpenAPI est disponible sur GitHub.
HTTPS avec chiffrement TLS requis
Azure IoT MQ envoie des requêtes contenant des informations d’identification client sensibles au serveur d’authentification personnalisé. Pour protéger ces informations d’identification, la communication entre Azure IoT MQ et le serveur d’authentification personnalisé doit être chiffrée avec TLS.
Le serveur d’authentification personnalisé doit présenter un certificat de serveur, et Azure IoT MQ doit disposer d’un certificat d’autorité de certification racine approuvé pour valider le certificat de serveur. Si vous le souhaitez, le serveur d’authentification personnalisé peut exiger qu’Azure IoT MQ présente un certificat client pour s’authentifier lui-même.
Activer l’authentification personnalisée pour un écouteur
Modifiez le paramètre authenticationMethods dans une ressource BrokerAuthentication pour spécifier custom comme méthode d’authentification valide. Ensuite, spécifiez les paramètres nécessaires pour communiquer avec un serveur d’authentification personnalisé.
Cet exemple montre tous les paramètres possibles. Les paramètres exacts requis dépendent des exigences de chaque serveur personnalisé.
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
Contenu connexe
Commentaires
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour