Partage via

Configurer TLS avec la gestion manuelle des certificats pour sécuriser la communication MQTT dans Azure IoT MQ (préversion)

  • Article

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.

Vous pouvez configurer TLS pour sécuriser la communication MQTT entre le répartiteur MQTT et le client à l’aide d’une ressource BrokerListener. Vous pouvez configurer TLS avec la gestion manuelle ou automatique des certificats.

Pour configurer manuellement Azure IoT MQ (préversion) 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 du broker d'Azure IoT MQ 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.pem

  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 TLS pour un écouteur

Modifiez le paramètre tls dans une ressource BrokerListener pour spécifier une configuration TLS manuelle référençant le secret Kubernetes. Notez le nom du secret utilisé pour le certificat de serveur TLS (server-cert-secret dans l’exemple précédent).

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: manual-tls-listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  authenticationEnabled: false # If true, BrokerAuthentication must be configured
  authorizationEnabled: false
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  port: 8885 # Avoid port conflict with default listener at 8883
  tls:
    manual:
      secretName: server-cert-secret

Une fois la ressource BrokerListener créée, l’opérateur crée automatiquement un service Kubernetes et déploie l’écouteur. Vous pouvez vérifier l’état du service en exécutant kubectl get svc.

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 MQ est activée.

Utiliser une adresse IP externe pour le certificat de serveur

Pour vous connecter à TLS via Internet, le certificat de serveur Azure IoT MQ 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.43.93.6      172.18.0.2    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 Azure IoT MQ 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.43.93.6      172.18.0.2    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