Compartir a través de

Configuración de TLS con administración man de certificados para proteger la comunicación MQTT en Azure IoT MQ Preview

  • Artículo

Importante

Operaciones de IoT de Azure, habilitado por Azure Arc, está actualmente en VERSIÓN PRELIMINAR. No se debería usar este software en versión preliminar en entornos de producción.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Puede configurar TLS para proteger la comunicación MQTT entre el agente MQTT y el cliente mediante un recurso BrokerListener. Puede configurar TLS mediante la administración manual o automática de certificados.

Para configurar manualmente Azure IoT MQ Preview a fin de usar un certificado TLS concreto, especifíquelo en un recurso BrokerListener con una referencia a un secreto de Kubernetes. A continuación, impleméntelo mediante kubectl. En este artículo se muestra un ejemplo de cómo configurar TLS con certificados autofirmados para la realización de pruebas.

Creación de una entidad de certificación con la CLI de Step

Step es un administrador de certificados que puede ayudarle a ponerse en marcha rápidamente cuando vaya a crear y administrar su propia entidad de certificación (CA) privada.

  1. Instale la CLI de Step y cree un certificado y una clave de entidad de certificación raíz.

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

  2. Cree un certificado y una clave de entidad de certificación intermedia firmados por la entidad de certificación raíz.

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

Creación de un certificado de servidor

Use la CLI de Step para crear un certificado de servidor a partir del firmado por la entidad de certificación intermedia.

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

Aquí, mqtts-endpoint y localhost son los nombres alternativos del firmante (SAN) para el front-end del agente en Kubernetes y los clientes locales de Azure IoT MQ, respectivamente. Para conectarse a través de Internet, agregue un elemento --san con una dirección IP externa. Las marcas --no-password --insecure se usan para la realización de pruebas a fin de omitir las solicitudes de contraseña y deshabilitar la protección de contraseñas para la clave privada debido a que se almacena en un secreto de Kubernetes. En producción, use una contraseña y almacene la clave privada en una ubicación segura, como Azure Key Vault.

Requisitos del algoritmo de clave de certificado

Se admiten claves EC y RSA, pero todos los certificados de la cadena deben usar el mismo algoritmo de clave. Si importa sus propios certificados de CA, asegúrese de que el certificado de servidor use el mismo algoritmo de clave que las entidades de certificación.

Importación de cadena del certificado raíz como secreto de Kubernetes

  1. Cree una cadena de certificados de servidor completa, donde el orden de los certificados es importante: el certificado de servidor es el primero del archivo, el intermedio es el segundo.

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

  2. Cree un secreto de Kubernetes con la cadena de certificados de servidor y la clave de servidor mediante kubectl.

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

Habilitar TLS para un cliente de escucha

Modifique el valor tls en un recurso BrokerListener para especificar la configuración de TLS manual que hace referencia al secreto de Kubernetes. Anote el nombre del secreto que se ha usado para el certificado de servidor TLS (server-cert-secret en el ejemplo anterior).

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

Una vez creado el recurso BrokerListener, el operador crea automáticamente un servicio de Kubernetes e implementa el cliente de escucha. Para comprobar el estado del servicio, ejecute kubectl get svc.

Conexión al agente con TLS

Para probar la conexión TLS con el cliente mosquitto, publique un mensaje y pase el certificado de CA raíz en el parámetro --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

Sugerencia

Para usar localhost, el puerto debe estar disponible en la máquina host. Por ejemplo, kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Con algunas distribuciones de Kubernetes como K3d, puede agregar un puerto reenviado con k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Nota:

Para conectarse al agente, debe distribuir la raíz de confianza a los clientes, también conocido como agrupación de confianza. En este caso, la raíz de confianza es la CA raíz autofirmado creada por la CLI del paso. La distribución de la raíz de confianza es necesaria para que el cliente compruebe la cadena de certificados del servidor. Si los clientes MQTT son cargas de trabajo en el clúster de Kubernetes, también debe crear un ConfigMap con la entidad de certificación raíz y montarlo en el pod.

Recuerde especificar el nombre de usuario, la contraseña, etc. si la autenticación MQ está habilitada.

Uso de una dirección IP externa para el certificado de servidor

Para conectarse con TLS a través de Internet, el certificado de servidor de Azure IoT MQ debe tener su nombre de host externo como SAN. En producción, este suele ser un nombre DNS o una dirección IP conocida. Sin embargo, durante la fase de desarrollo/pruebas, es posible que no sepa qué nombre de host o dirección IP externa se ha asignado antes de la implementación. Para resolverlo, implemente primero el cliente de escucha sin el certificado de servidor; a continuación, cree el certificado de servidor y el secreto con la dirección IP externa y, por último, importe el secreto en el cliente de escucha.

Si intenta implementar el cliente de escucha TLS de ejemplo manual-tls-listener pero el secreto de Kubernetes al que se hace referencia server-cert-secret no existe, se crea el servicio asociado, pero los pods no se inician. El servicio se crea porque el operador necesita reservar la dirección IP externa para el cliente de escucha.

$ 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

Sin embargo, se espera este comportamiento y no importa dejarlo así mientras importamos el certificado de servidor. Los registros del administrador de mantenimiento mencionan que Azure IoT MQ está esperando el certificado de servidor.

$ 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.

Nota:

Por lo general, en un sistema distribuido, los registros de los pods no son deterministas y se deben usar con precaución. La forma correcta para mostrar información como esta es a través de eventos de Kubernetes y del estado de los recursos personalizados, que se encuentra en el trabajo pendiente. Considere el paso anterior como solución temporal.

Aunque los pods del front-end no estén en uso, la dirección IP externa ya está 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

A partir de aquí, siga los mismos pasos que antes para crear un certificado de servidor con esta dirección IP externa en --san y cree el secreto de Kubernetes de la misma forma. Una vez creado el secreto, este se importa automáticamente en el cliente de escucha.

Contenido relacionado