Partager via

Sécuriser la communication de l’Agent MQTT à l’aide de BrokerListener

  • Article

Important

Opérations Azure IoT Préversion avec Azure Arc est actuellement en préversion. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Lorsqu’une version en disponibilité générale sera publiée, vous devrez déployer une nouvelle installation d’Opérations Azure IoT. Vous ne pourrez pas mettre à niveau une installation en préversion.

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.

Pour personnaliser l’accès réseau et la sécurité, utilisez la ressource BrokerListener. Un écouteur correspond à un point de terminaison réseau qui expose le répartiteur au réseau. Vous pouvez avoir une ou plusieurs ressources BrokerListener pour chaque ressource Broker, et donc plusieurs ports avec chacun un contrôle d’accès différent.

Chaque port d’écouteur peut avoir ses propres règles d’authentification et d’autorisation qui définissent qui peut se connecter à l’écouteur et quelles actions il peut effectuer sur le répartiteur. Vous pouvez utiliser les ressources BrokerAuthentication et BrokerAuthorization pour spécifier les stratégies de contrôle d’accès pour chaque écouteur. Cette flexibilité vous permet d’affiner les autorisations et les rôles de vos clients MQTT, en fonction de leurs besoins et de leurs cas d’usage.

Conseil

Vous pouvez accéder au déploiement du MQTT broker par défaut seulement en utilisant l’adresse IP du cluster, le protocole TLS et un jeton de compte de service. Les clients se connectant depuis l’extérieur du cluster ont besoin d’une configuration supplémentaire pour pouvoir se connecter.

Les écouteurs présentent les caractéristiques suivantes :

  • Vous pouvez avoir jusqu’à trois écouteurs. Un écouteur par type de service de loadBalancer, de clusterIp ou de nodePort. Le BrokerListener par défaut nommé par défaut est un type de service clusterIp.
  • Chaque écouteur prend en charge plusieurs ports
  • Les références à BrokerAuthentication et à BrokerAuthorization se font pour un port donné.
  • La configuration TLS fonctionne par port
  • Les noms de service doivent être uniques
  • Les ports ne peuvent pas entrer en conflit sur différents écouteurs

Pour obtenir la liste des paramètres disponibles, consultez les informations de référence sur l’API Écouteur de broker.

BrokerListener par défaut

Lorsque vous déployez Opérations Azure IoT (préversion), le déploiement crée également une ressource BrokerListener nommée default dans l’espace de noms azure-iot-operations. Cet écouteur est lié à la ressource Broker par défaut nommée default qui est également créée pendant le déploiement. L’écouteur par défaut expose le broker sur le port 18883 avec TLS et l’authentification SAT activée. Le certificat TLS est automatiquement managé par le gestionnaire de certificats. L’autorisation est désactivée par défaut.

Pour voir ou modifier l’écouteur :

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

    Capture d’écran de l’utilisation du portail Azure pour afficher la configuration MQTT d’Opérations Azure IoT.

  3. Dans la liste des écouteurs du broker, sélectionnez l’écouteur par défaut.

    Capture d’écran de l’utilisation du portail Azure pour afficher ou modifier l’écouteur de broker par défaut.

  4. Passez en revue les paramètres de l’écouteur et apportez les modifications nécessaires.

Créer des écouteurs de broker

Cet exemple montre comment créer une ressource BrokerListener nommée loadbalancer-listener pour une ressource Broker. La ressource BrokerListener définit deux ports qui acceptent les connexions MQTT venant des clients.

  • Le premier port écoute le port 1883 sans TLS et l’authentification désactivée. Les clients peuvent se connecter au répartiteur sans chiffrement ni authentification.
  • Le second port écoute le port 18883 avec TLS et l’authentification activée. Seuls les clients authentifiés peuvent se connecter au répartiteur avec le chiffrement TLS. TLS est défini sur automatic, ce qui signifie que l’écouteur utilise le gestionnaire de certificats pour obtenir et renouveler son certificat de serveur.

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

  3. Sélectionnez Écouteur de l’Agent MQTT pour LoadBalancer>Créer. Vous ne pouvez créer qu’un seul écouteur par type de service. Si vous avez déjà un écouteur du même type de service, vous pouvez ajouter d’autres ports à l’écouteur existant.

    Capture d’écran de l’utilisation du portail Azure pour créer l’Agent MQTT pour l’écouteur de l’équilibreur de charge.

    Entrez les paramètres suivants :

    Setting Description
    Nom Nom de la ressource BrokerListener.
    Nom du service Nom du service Kubernetes associé au BrokerListener.
    Type de service Type de service broker, comme LoadBalancer, NodePort ou ClusterIP.
    Port Numéro de port sur lequel BrokerListener écoute les connexions MQTT.
    Authentification Les informations de référence sur les ressources d’authentification.
    Autorisation Les informations de référence sur les ressources d’autorisation.
    TLS Indique si TLS est activé pour une communication sécurisée. Peut être défini sur Automatique ou sur Manuel.

  4. Sélectionnez Créer un écouteur.

Configurer TLS avec la gestion automatique des certificats

Pour activer TLS avec la gestion automatique des certificats, spécifiez les paramètres TLS sur un port d’écouteur.

Vérifier l’installation du gestionnaire de certificats

Avec la gestion automatique des certificats, vous utilisez le gestionnaire de certificats pour gérer le certificat de serveur TLS. Par défaut, le gestionnaire de certificats est déjà installé en même temps que les Opérations Azure IoT (préversion) dans l’espace de noms azure-iot-operations. Vérifiez l’installation avant de continuer.

  1. Utilisez kubectl pour rechercher les pods correspondant aux étiquettes d’application du gestionnaire de certificats.

    kubectl get pods --namespace azure-iot-operations -l 'app in (cert-manager,cainjector,webhook)'

    NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

  2. Si vous voyez les pods affichés comme prêts et en cours d’exécution, le gestionnaire de certificats est installé et prêt à être utilisé.

Conseil

Pour vérifier davantage l’installation, consultez la documentation du gestionnaire de certificats vérifier l’installation. N’oubliez pas d’utiliser l’espace de noms azure-iot-operations.

Créer un émetteur pour le certificat de serveur TLS

La ressource Émetteur du gestionnaire de certificats définit la façon dont les certificats sont émis automatiquement. Cert-manager prend en charge plusieurs types d’émetteurs en mode natif. Il prend également en charge un type d’émetteur externe pour étendre les fonctionnalités au-delà des émetteurs pris en charge en mode natif. Vous pouvez utiliser l’agent MQTT avec n’importe quel type d’émetteur de gestionnaire de certificats.

Important

Pendant le déploiement initial, Opérations Azure IoT est installé avec un émetteur par défaut pour les certificats de serveur TLS. Vous pouvez utiliser cet émetteur pour le développement et le test. Pour plus d’informations, consultez autorité de certification racine et émetteur par défaut avec Opérations Azure IoT. Les étapes ci-dessous ne sont requises que si vous souhaitez utiliser un autre émetteur.

L’approche de création de l’émetteur est différente en fonction de votre scénario. Les sections suivantes répertorient des exemples pour vous aider à commencer.

L’émetteur de l’autorité de certification est utile pour le développement et le test. Il doit être configuré avec un certificat et une clé privée stockés dans un secret Kubernetes.

Configurer le certificat racine en tant que secret Kubernetes

Si vous disposez d’un certificat d’autorité de certification existant, créez un secret Kubernetes avec le certificat d’autorité de certification et les fichiers PEM de clé privée. Exécutez la commande suivante et vous avez configuré le certificat racine en tant que secret Kubernetes et pouvez ignorer la section suivante.

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

Si vous n’avez pas de certificat d’autorité de certification, le gestionnaire de certificats peut générer un certificat d’autorité de certification racine pour vous. L'utilisation du gestionnaire de certificats pour générer un certificat d'autorité de certification racine est connue sous le nom de démarrage d'un émetteur d'autorité de certification à l'aide d'un certificat auto-signé.

  1. Commencez par créer ca.yaml :

    apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

  2. Créez le certificat d’autorité de certification auto-signé avec la commande suivante :

    kubectl apply -f ca.yaml

Le gestionnaire de certificats crée un certificat d’autorité de certification à l’aide de ses valeurs par défaut. Vous pouvez modifier les propriétés de ce certificat en modifiant la spécification du certificat. Consultez la documentation du gestionnaire de certificats pour obtenir la liste des options valides.

Distribuer le certificat racine

L’exemple précédent stocke le certificat d’autorité de certification dans un secret Kubernetes appelé test-ca. Le certificat au format PEM peut être récupéré à partir du secret et stocké dans un fichier ca.crt avec la commande suivante :

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

Ce certificat doit être distribué et approuvé par tous les clients. Par exemple, utilisez un indicateur --cafile pour un client mosquitto.

Créer un émetteur basé sur un certificat d’autorité de certification

Le gestionnaire de certificats a besoin d’un émetteur basé sur le certificat d’autorité de certification généré ou importé à l’étape précédente. Créez le fichier suivant en tant que 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

Créez l’émetteur avec la commande suivante :

kubectl apply -f issuer-ca.yaml

La commande précédente crée un émetteur pour émettre les certificats de serveur TLS. Notez le nom et le type de l’émetteur. Dans l’exemple, nom my-issuer et type Issuer. Ces valeurs sont définies dans la ressource BrokerListener ultérieurement.

Activer la gestion automatique des certificats TLS pour un port

Voici un exemple de ressource BrokerListener qui active TLS sur le port 8884 avec la gestion automatique des certificats.

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

  3. Sélectionnez ou créez un écouteur. Vous ne pouvez créer qu’un seul écouteur par type de service. Si vous avez déjà un écouteur du même type de service, vous pouvez ajouter d’autres ports à l’écouteur existant.

  4. Vous pouvez ajouter des paramètres TLS à l’écouteur en sélectionnant le protocole TLS sur un port existant ou en ajoutant un nouveau port.

    Capture d’écran de l’utilisation du portail Azure pour créer l’Agent MQTT pour l’écouteur de l’équilibreur de charge avec certificats TLS automatiques.

    Entrez les paramètres suivants :

    Setting Description
    Port Numéro de port sur lequel BrokerListener écoute les connexions MQTT. Obligatoire.
    Authentification Les informations de référence sur les ressources d’authentification.
    Autorisation Les informations de référence sur les ressources d’autorisation.
    TLS Cliquez sur le bouton Ajouter.
    Nom de l'émetteur Nom de l’émetteur du gestionnaire de certificats. Obligatoire.
    Type d’émetteur Type de l’émetteur du gestionnaire de certificats. Obligatoire.
    Groupe d’émetteurs Groupe de l’émetteur du gestionnaire de certificats. Obligatoire.
    Algorithme de clé privée Algorithme de la clé privée.
    Stratégie de rotation de clé privée Stratégie de rotation de la clé privée.
    Noms DNS Autres noms de l’objet DNS pour le certificat.
    Adresses IP Adresses IP des autres noms de l’objet pour le certificat.
    Nom du secret Secret Kubernetes contenant un certificat client X.509.
    Durée Durée de vie totale du certificat de serveur TLS (par défaut : 90 jours).
    Renouveler avant Quand commencer le renouvellement du certificat.

  5. Sélectionnez Enregistrer pour enregistrer les paramètres TLS.

Se connecter au répartiteur avec TLS

Une fois le certificat de serveur configuré, TLS est activé. Pour tester avec mosquitto :

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

L’argument --cafile active TLS sur le client mosquitto et spécifie que le client doit approuver tous les certificats de serveur émis par le fichier donné. Vous devez spécifier un fichier qui contient l’émetteur du certificat de serveur TLS configuré.

Remplacez $HOST par l’hôte approprié :

  • Si vous vous connectez à partir du même cluster, remplacez par le nom du service donné (my-new-tls-listener par exemple) ou le service CLUSTER-IP.
  • Si vous vous connectez à partir de l’extérieur du cluster, le service EXTERNAL-IP.

N’oubliez pas de spécifier les méthodes d’authentification si nécessaire.

Autorité de certification racine et émetteur par défaut

Pour vous aider à commencer, Opérations Azure IoT est déployé avec une autorité de certification racine « démarrage rapide » par défaut et un émetteur pour les certificats de serveur TLS. Vous pouvez utiliser cet émetteur pour le développement et le test. Pour plus d’informations, voir AC racine par défaut et émetteur des certificats de serveur TLS.

Pour la production, vous devez configurer un émetteur d’autorité de certification avec un certificat d’une autorité de certification approuvée, comme décrit dans les sections précédentes.

Configurer TLS avec la gestion manuelle des certificats

Pour configurer manuellement l’agent MQTT pour utiliser un certificat TLS spécifique, spécifiez-le dans une ressource BrokerListener avec une référence à un secret Kubernetes. Déployez-le ensuite à l’aide de kubectl. Cet article montre un exemple de configuration de TLS avec des certificats auto-signés à des fins de test.

Créer une autorité de certification avec Step CLI

Step est un gestionnaire de certificats qui peut rapidement vous rendre opérationnel lors de la création et de la gestion de votre propre autorité de certification privée.

  1. Installez Step CLI et créez un certificat et une clé d’autorité de certification racine.

    step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key

  2. Créez un certificat d’autorité de certification intermédiaire et une clé signés par l’autorité de certification racine.

    step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

Créer un certificat de serveur

Utilisez Step CLI pour créer un certificat de serveur à partir de l’autorité de certification intermédiaire signée.

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

Ici, mqtts-endpoint et localhost sont les Subject Alternative Names (SAN) pour le front-end de l’agent MQTT dans Kubernetes et les clients locaux, respectivement. Pour vous connecter via Internet, ajoutez un --san avec une adresse IP externe. Les indicateurs --no-password --insecure sont utilisés pour le test pour ignorer les invites de mot de passe et désactiver la protection par mot de passe pour la clé privée, car elles sont stockées dans un secret Kubernetes. Pour la production, utilisez un mot de passe et stockez la clé privée dans un emplacement sécurisé comme Azure Key Vault.

Exigences relatives à l’algorithme de clé de certificat

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 de serveur utilise le même algorithme de clé que les autorités de certification.

Importer une chaîne de certificats de serveur en tant que secret Kubernetes

  1. Créez une chaîne de certificats de serveur complète, où l’ordre des certificats importe : le certificat de serveur est le premier du fichier, le certificat intermédiaire est le second.

    cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt

  2. Créez un secret Kubernetes avec la chaîne de certificats de serveur et la clé de serveur en utilisant kubectl.

    kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key

Activer la gestion manuelle des certificats TLS pour un port

Voici un exemple de ressource BrokerListener qui active TLS sur le port 8884 avec la gestion manuelle des certificats.

  1. Dans le portail Azure, accédez à votre instance Opérations IoT.

  2. Sous Ressources Opérations Azure IoT, sélectionnez Agent MQTT.

  3. Sélectionnez ou créez un écouteur. Vous ne pouvez créer qu’un seul écouteur par type de service. Si vous avez déjà un écouteur du même type de service, vous pouvez ajouter d’autres ports à l’écouteur existant.

  4. Vous pouvez ajouter des paramètres TLS à l’écouteur en sélectionnant le protocole TLS sur un port existant ou en ajoutant un nouveau port.

    Capture d’écran de l’utilisation du portail Azure pour créer l’Agent MQTT pour l’écouteur de l’équilibreur de charge avec certificats TLS manuels.

    Entrez les paramètres suivants :

    Setting Description
    Port Numéro de port sur lequel BrokerListener écoute les connexions MQTT. Obligatoire.
    Authentification Les informations de référence sur les ressources d’authentification.
    Autorisation Les informations de référence sur les ressources d’autorisation.
    TLS Cliquez sur le bouton Ajouter.
    Nom du secret Secret Kubernetes contenant un certificat client X.509.

  5. Sélectionnez Enregistrer pour enregistrer les paramètres TLS.

Se connecter au répartiteur avec TLS

Pour tester la connexion TLS avec le client mosquitto, publiez un message et passez le certificat d’autorité de certification racine dans le paramètre --cafile.

mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt

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

Conseil

Pour utiliser localhost, le port doit être disponible sur l’ordinateur hôte. Par exemple : kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Avec certaines distributions Kubernetes comme K3d, vous pouvez ajouter un port transféré avec k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Remarque

Pour vous connecter au répartiteur, vous devez distribuer la racine de confiance aux clients, ce qui est également connu sous le nom de pack d’approbation. Dans ce cas, la racine de confiance est l’autorité de certification racine auto-signée créée avec l'outil CLI step. La distribution de la racine de confiance est requise pour que le client puisse vérifier la chaîne de certificats de serveur. Si vos clients MQTT sont des charges de travail sur le cluster Kubernetes, vous devez également créer un ConfigMap avec l’autorité de certification racine et le monter dans votre pod.

N’oubliez pas de spécifier le nom d’utilisateur, le mot de passe, etc. si l’authentification de l’agent MQTT est activée.

Utiliser une adresse IP externe pour le certificat de serveur

Pour vous connecter à TLS via Internet, le certificat de serveur de l’agent MQTT doit avoir son nom d’hôte externe en tant que SAN. En production, il s’agit généralement d’un nom DNS ou d’une adresse IP connue. Toutefois, pendant le développement/test, vous ne savez peut-être pas quel nom d’hôte ou adresse IP externe est affecté avant le déploiement. Pour résoudre ce problème, déployez l’écouteur sans le certificat de serveur en premier, puis créez le certificat de serveur et le secret avec l’adresse IP externe, puis importez le secret dans l’écouteur.

Si vous essayez de déployer l’exemple d’écouteur TLS manual-tls-listener mais que le secret Kubernetes référencé server-cert-secret n’existe pas, le service associé est créé, mais les pods ne démarrent pas. Le service est créé, car l’opérateur doit réserver l’adresse IP externe pour l’écouteur.

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

Toutefois, ce comportement est attendu et il est possible de le laisser comme cela pendant que nous importons le certificat de serveur. Les journaux du gestionnaire d’intégrité mentionnent que l’agent MQTT attend le certificat de serveur.

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.

Remarque

En règle générale, dans un système distribué, les journaux des pods ne sont pas déterministes et doivent être utilisés avec précaution. La bonne façon d’obtenir des informations comme celle-ci consiste à utiliser des événements Kubernetes et l’état des ressources personnalisées, qui se trouve dans le backlog. Considérez l’étape précédente comme solution de contournement temporaire.

Même si les pods frontaux ne sont pas en cours, l’adresse IP externe est déjà disponible.

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

À partir de là, suivez les mêmes étapes que précédemment pour créer un certificat de serveur avec cette adresse IP externe dans --san et créer le secret Kubernetes de la même façon. Une fois le secret créé, il est automatiquement importé dans l’écouteur.

Contenu connexe