Compartir por

Configurar TLS con administración automática de certificados para asegurar la comunicación MQTT en el corredor MQTT

  • Artigo

Importante

Versión preliminar de operaciones de Azure IoT: habilitada 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.

Deberá implementar una nueva instalación de Azure IoT Operations cuando esté disponible una versión general. No podrá actualizar una instalación de versión preliminar.

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 con administración manual o automática de certificados.

Compruebe la instalación de cert-manager

Con la administración automática de certificados, se usa cert-manager para administrar el certificado de servidor TLS. De forma predeterminada, el administrador de certificados se instala junto con la versión preliminar de operaciones de Azure IoT en el espacio de nombres azure-iot-operations. Compruebe la instalación antes de continuar.

  1. Use kubectl para comprobar si los pods coinciden con las etiquetas de la aplicación cert-manager.

    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 ve que los pods se muestran como listos y en ejecución, cert-manager está instalado y listo para usarse.

Sugerencia

Para comprobar aún más la instalación, consulte la documentación de cert-manager para comprobar la instalación. Recuerde usar el espacio de nombres azure-iot-operations.

Creación de un emisor para el certificado de servidor TLS

El recurso emisor cert-manager define cómo se emiten automáticamente los certificados. Cert-manager admite varios tipos de emisores de forma nativa. También admite un tipo de emisor externo para ampliar la funcionalidad más allá de los emisores admitidos de forma nativa. El broker MQTT puede utilizarse con cualquier tipo de emisor de cert-manager.

Importante

Durante la implementación inicial, las Operaciones de IoT de Azure se instala con un emisor predeterminado para los certificados de servidor TLS. Puede usar este emisor para desarrollo y pruebas. Para más información, consulte Entidad de certificación raíz predeterminada y emisor con Operaciones de loT de Azure. Los pasos siguientes solo son necesarios si desea usar otro emisor.

El enfoque para crear el emisor es diferente en función del escenario. En las secciones siguientes se enumeran ejemplos para ayudarle a empezar.

El emisor de CA es útil para el desarrollo y las pruebas. Debe configurarse con un certificado y una clave privada almacenadas en un secreto de Kubernetes.

Configuración del certificado raíz como un secreto de Kubernetes

Si ya tiene un certificado de CA, cree un secreto de Kubernetes con los archivos PEM del certificado de CA y la clave privada. Ejecute el siguiente comando y haya configurado el certificado raíz como un secreto de Kubernetes y puede omitir la sección siguiente.

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

Si no tiene un certificado CA, cert-manager puede generar un certificado CA raíz para usted. El uso de cert-manager para generar un certificado de CA raíz se conoce como arranque de un emisor CA con un certificado autofirmado.

  1. Empiece por crear 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. Cree el certificado CA con firma propia con el siguiente comando:

    kubectl apply -f ca.yaml

Cert-manager crea un certificado CA utilizando sus valores predeterminados. Las propiedades de este certificado pueden cambiarse modificando la especificación del certificado. Consulte Documentación de cert-manager para obtener una lista de opciones válidas.

Distribuir el certificado raíz

El ejemplo anterior almacena el certificado CA en un secreto de Kubernetes llamado test-ca. El certificado en formato PEM se puede recuperar del secreto y almacenar en un archivo ca.crt con el siguiente comando:

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

Todos los clientes deben distribuir y confiar en este certificado. Por ejemplo, use la marca --cafile para un cliente de mosquitto.

Crear emisor basado en certificado CA

Cert-manager necesita un emisor basado en el certificado CA generado o importado en el paso anterior. Cree el siguiente archivo como 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

Cree el emisor con el siguiente comando:

kubectl apply -f issuer-ca.yaml

El comando anterior crea un emisor para emitir los certificados de servidor TLS. Anote el nombre y el tipo del emisor. En el ejemplo, nombre my-issuer y tipo Issuer. Estos valores se establecen en el recurso BrokerListener más adelante.

Habilitar TLS para un puerto

Modifique la configuración tls en un recurso BrokerListener para especificar un puerto TLS y un emisor para los front-end. A continuación se muestra un ejemplo de un recurso BrokerListener que habilita TLS en el puerto 8884 con administración automática de certificados.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: my-new-tls-listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  serviceType: loadBalancer
  serviceName: my-new-tls-listener # Avoid conflicts with default service name 'aio-broker'
  ports:
  - port: 8884 # Avoid conflicts with default port 18883
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: my-issuer
          kind: Issuer

Una vez configurado el recurso BrokerListener, el broker MQTT crea automáticamente un nuevo servicio con el puerto especificado y TLS habilitado.

Opcional: Configurar parámetros de certificado de servidor

Los únicos parámetros necesarios son issuerRef.name y issuerRef.kind. Todas las propiedades de los certificados de servidor TLS generados se eligen automáticamente. Sin embargo, el broker MQTT permite personalizar ciertas propiedades especificándolas en el recurso BrokerListener, bajotls.automatic.issuerRef. A continuación se muestra un ejemplo de todas las propiedades admitidas:

# cert-manager issuer for TLS server certificate. Required.
issuerRef:
  # Name of issuer. Required.
  name: my-issuer
  # 'Issuer' or 'ClusterIssuer'. Required.
  kind: Issuer
  # Issuer group. Optional; defaults to 'cert-manager.io'.
  # External issuers may use other groups.
  group: cert-manager.io
# Namespace of certificate. Optional; omit to use default namespace.
namespace: az
# Where to store the generated TLS server certificate. Any existing
# data at the provided secret will be overwritten.
# Optional; defaults to 'my-issuer-{port}'.
secret: my-issuer-8884
# Parameters for the server certificate's private key.
# Optional; defaults to rotationPolicy: Always, algorithm: ECDSA, size: 256.
privateKey:
  rotationPolicy: Always
  algorithm: ECDSA
  size: 256
# Total lifetime of the TLS server certificate. Optional; defaults to '720h' (30 days).
duration: 720h
# When to begin renewing the certificate. Optional; defaults to '240h' (10 days).
renewBefore: 240h
# Any additional SANs to add to the server certificate. Omit if not required.
san:
  dns:
  - iotmq.example.com
  # To connect to the broker from a different namespace, add the following DNS name:
  - aio-broker.azure-iot-operations.svc.cluster.local
  ip:
  - 192.168.1.1

Comprobación de la implementación

Use kubectl para comprobar que el servicio asociado al recurso BrokerListener se está ejecutando. En el ejemplo anterior, el nombre del servicio es my-new-tls-listener y el espacio de nombres es azure-iot-operations. El comando siguiente comprueba el estado del servicio:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
my-new-tls-listener    LoadBalancer   10.43.241.171   XXX.XX.X.X    8884:32457/TCP   33s

Conexión al agente con TLS

Una vez configurado el certificado de servidor, TLS está habilitado. Para probar con mosquitto:

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

El argumento--cafile habilita TLS en el cliente mosquitto y especifica que el cliente debe confiar en todos los certificados de servidor emitidos por el archivo especificado. Debe especificar un archivo que contenga el emisor del certificado de servidor TLS configurado.

Reemplace por $HOST el host adecuado:

  • Si se conecta desde dentro del mismo clúster, reemplace por el nombre de servicio especificado (my-new-tls-listener por ejemplo) o el servicio CLUSTER-IP.
  • Si se conecta desde fuera del clúster, el servicio EXTERNAL-IP.

Recuerde especificar métodos de autenticación si es necesario.

Entidad de certificación raíz predeterminada y emisor

Para ayudarle a empezar, las operaciones de Azure IoT se implementan con una CA raíz predeterminada de "inicio rápido" y un emisor para los certificados de servidor TLS. Puede usar este emisor para desarrollo y pruebas. Para obtener más información, consulte Entidad de certificación raíz predeterminada y emisor para certificados TLS de servidor.

Para la producción, debe configurar un emisor de CA con un certificado de una CA de confianza, como se describe en las secciones anteriores.

Contenido relacionado