Compartir a través de

Protección de la comunicación en Azure IoT MQ Preview mediante BrokerListener

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

Para personalizar el acceso a la red y la seguridad, use el recurso BrokerListener. Un agente de escucha corresponde a un punto de conexión de red que expone el agente a la red. Puede tener uno o varios recursos de BrokerListener para cada recurso de agente y, por tanto, varios puertos con control de acceso diferente cada uno.

Cada agente de escucha puede tener sus propias reglas de autenticación y autorización que definen quién puede conectarse al agente de escucha y qué acciones pueden realizar en el agente. Puede usar recursos BrokerAuthentication y BrokerAuthorization para especificar las directivas de control de acceso para cada agente de escucha. Esta flexibilidad le permite ajustar los permisos y roles de los clientes MQTT, en función de sus necesidades y casos de uso.

El recurso BrokerListener tiene estos campos:

Nombre del campo Obligatorio Descripción
brokerRef Sí Nombre del recurso de agente al que pertenece este agente de escucha. Este campo es obligatorio y debe coincidir con un recurso de agente existente en el mismo espacio de nombres.
port Sí Número de puerto en el que escucha este agente de escucha. Este campo es obligatorio y debe ser un número de puerto TCP válido.
serviceType No Tipo del servicio Kubernetes creado para este agente de escucha. Este subcampo es opcional y el valor predeterminado es clusterIp. Debe ser loadBalancer, clusterIp o nodePort.
serviceName No Nombre del servicio Kubernetes creado para este agente de escucha. Kubernetes crea registros DNS para este serviceName, que los clientes deben usar para conectarse a Azure IoT MQ Preview. Este subcampo es opcional y el valor predeterminado es aio-mq-dmqtt-frontend. Importante: Si tiene varios agentes de escucha que comparten serviceType y serviceName, los agentes de escucha comparten el mismo servicio de Kubernetes. Para obtener más información, consulte Nombre del servicio y tipo de servicio.
authenticationEnabled No Marca booleana que indica si este agente de escucha requiere autenticación de clientes. Si se establece en true, este agente de escucha usa cualquier recurso BrokerAuthentication asociado a él para comprobar y autenticar a los clientes. Si se establece en false, este agente de escucha permite que cualquier cliente se conecte sin autenticación. Este campo es opcional y el valor predeterminado es false. Para más información sobre la autenticación, consulte Configuración de la autenticación en Azure IoT MQ Preview.
authorizationEnabled No Marca booleana que indica si este agente de escucha requiere autorización de clientes. Si se establece en true, este agente de escucha usa cualquier recurso BrokerAuthorization asociado a él para comprobar y autorizar a los clientes. Si se establece en false, este agente de escucha permite que cualquier cliente se conecte sin autorización. Este campo es opcional y el valor predeterminado es false. Para más información sobre la autorización, consulte Configuración de la autorización en Azure IoT MQ Preview.
tls No Configuración de TLS para el agente de escucha. El campo es opcional y se puede omitir para deshabilitar TLS para el agente de escucha. Para configurar TLS, establézcalo en uno de estos tipos:
* Si se establece en automatic, este agente de escucha usa cert-manager para obtener y renovar un certificado para el agente de escucha. Para usar este tipo, especifique un campo issuerRef para hacer referencia al emisor de cert-manager.
* Si se establece en manual, el agente de escucha usa un certificado proporcionado manualmente para el agente de escucha. Para usar este tipo, especifique un campo de secretName que haga referencia a un secreto de Kubernetes que contenga el certificado y la clave privada.
* Si se establece en keyVault, el agente de escucha usa un certificado de Azure Key Vault. Para usar este tipo, especifique un campo de keyVault que haga referencia a la instancia de Azure Key Vault y al secreto.
protocol No Protocolo que usa este agente de escucha. Este campo es opcional y el valor predeterminado es mqtt. Debe ser mqtt o websockets.

BrokerListener predeterminado

Al implementar versión preliminar de Operaciones de IoT de Azure, la implementación también crea un recurso de BrokerListener denominado listener en el espacio de nombres azure-iot-operations. Este agente de escucha está vinculado al recurso de agente predeterminado denominado broker que también se crea durante la implementación. El agente de escucha predeterminado expone el agente en el puerto 8883 con la autenticación TLS y SAT habilitada. El certificado TLS se administra automáticamente por medio de cert-manager. La autorización está deshabilitada de forma predeterminada.

Para inspeccionar el agente de escucha, ejecute:

kubectl get brokerlistener listener -n azure-iot-operations -o yaml

La salida debe ser así, con la mayoría de los metadatos quitados para mayor brevedad:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  authenticationEnabled: true
  authorizationEnabled: false
  port: 8883
  serviceName: aio-mq-dmqtt-frontend
  serviceType: clusterIp
  tls:
    automatic:
      issuerRef:
        group: cert-manager.io
        kind: Issuer
        name: mq-dmqtt-frontend

Para obtener más información sobre el recurso BrokerAuthentication predeterminado vinculado a este agente de escucha, consulte recurso Default BrokerAuthentication.

Crear nuevos BrokerListeners

En este ejemplo, se muestra cómo crear dos nuevos recursos de BrokerListener para un recurso de agente denominado my-broker. Cada BrokerListener recurso define un puerto y una configuración TLS para un agente de escucha que acepta conexiones MQTT de los clientes.

  • El primer recurso BrokerListener, denominado my-test-listener, define un agente de escucha en el puerto 1883 sin TLS ni autenticación desactivada. Los clientes pueden conectarse al agente sin cifrado ni autenticación.
  • El segundo recurso BrokerListener, denominado my-secure-listener, define un agente de escucha en el puerto 8883 con TLS y la autenticación habilitada. Solo los clientes autenticados pueden conectarse al agente con cifrado TLS. El campo tls se establece en automatic, lo que significa que el agente de escucha usa cert-manager para obtener y renovar su certificado de servidor.

Para crear estos recursos de BrokerListener, aplique este manifiesto de YAML al clúster de Kubernetes:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: my-test-listener
  namespace: azure-iot-operations
spec:
  authenticationEnabled: false
  authorizationEnabled: false
  brokerRef: broker
  port: 1883
---
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: my-secure-listener
  namespace: azure-iot-operations
spec:
  authenticationEnabled: true
  authorizationEnabled: false
  brokerRef: broker
  port: 8883
  tls:
    automatic:
      issuerRef:
        name: e2e-cert-issuer
        kind: Issuer
        group: cert-manager.io

Nombre y tipo de servicio

Si tiene varios recursos de BrokerListener con los mismos serviceType y serviceName, los recursos comparten el mismo servicio de Kubernetes. Esto significa que el servicio expone todos los puertos de todos los agentes de escucha. Por ejemplo, si tiene dos agentes de escucha con los mismos serviceType y serviceName, uno en el puerto 1883 y el otro en el puerto 8883, el servicio expone ambos puertos. Los clientes pueden conectarse al agente en cualquier puerto.

Hay dos reglas importantes que se deben seguir al compartir el nombre del servicio:

  1. Los agentes de escucha que comparten serviceType deben compartir el mismo serviceName.

  2. Los agentes de escucha con diferentes serviceType deben tener diferentes serviceName.

En concreto, el servicio del agente de escucha predeterminado en el puerto 8883 es clusterIp y se denomina aio-mq-dmqtt-frontend. En la tabla siguiente se resume lo que sucede al crear un nuevo agente de escucha en un puerto diferente:

Nuevo agente de escucha serviceType Nuevo agente de escucha serviceName Resultado
clusterIp aio-mq-dmqtt-frontend El nuevo agente de escucha se crea correctamente y el servicio expone ambos puertos.
clusterIp my-service El nuevo agente de escucha no se crea porque el tipo de servicio entra en conflicto con el agente de escucha predeterminado.
loadBalancer o nodePort aio-mq-dmqtt-frontend El nuevo agente de escucha no se crea porque el nombre de servicio entra en conflicto con el agente de escucha predeterminado.
loadBalancer o nodePort my-service El nuevo agente de escucha se crea correctamente y se crea un nuevo servicio.

Contenido relacionado