Compartir a través de

Configuración de la autenticación del corredor MQTT

  • Artículo

Importante

En esta página se incluyen instrucciones para administrar componentes de Operaciones de IoT de Azure mediante manifiestos de implementación de Kubernetes, que se encuentra en versión preliminar. Esta característica se proporciona con varias limitacionesy no se debe usar para cargas de trabajo 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.

Un corredor MQTT admite varios métodos de autenticación para los clientes. Puede configurar cada puerto de agente de escucha para tener sus propias opciones de autenticación con un recurso BrokerAuthentication. Para obtener una lista de la configuración disponible, consulte la referencia de API Autenticación de Broker.

Las reglas siguientes se aplican a la relación entre los recursos BrokerListener y BrokerAuthentication:

  • Cada BrokerListener puede tener varios puertos. Puede vincular cada puerto a un recurso BrokerAuthentication.
  • Cada recurso BrokerAuthentication puede admitir varios métodos de autenticación a la vez.
  • Los puertos que no vinculan un recurso de BrokerAuthentication tienen deshabilitada la autenticación.

Para vincular un puerto BrokerListener a un recurso de BrokerAuthentication, especifique el campo authenticationRef en la configuración ports del recurso BrokerListener. Para más información, consulte Recurso BrokerListener.

Recurso BrokerAuthentication predeterminado

Operaciones de IoT de Azure implementa un recurso predeterminado BrokerAuthentication denominado default vinculado con el agente de escucha predeterminado en el espacio de nombres azure-iot-operations. Solo usa Tokens de cuenta de Servicio de Kubernetes (SAT) para la autenticación.

Importante

El método de autenticación SAT en el recurso BrokerAuthentication predeterminado es necesario para que los componentes de Operaciones de IoT funcionen correctamente. Evite actualizar o eliminar el recurso predeterminado BrokerAuthentication.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione la pestaña Autenticación.

  4. En la lista de directivas de autenticación, seleccione el nombre de directiva predeterminado.

    Captura de pantalla que muestra el uso de Azure Portal para ver la directiva de autenticación predeterminada del corredor MQTT.

Para agregar nuevos métodos de autenticación, seleccione Agregar método.

Flujo de autenticación

El orden de los métodos de autenticación especificados determina cómo el corredor MQTT autentica a los clientes. El corredor MQTT intenta autenticar las credenciales del cliente mediante el primer método especificado y recorre en iteración los métodos especificados hasta que encuentre una coincidencia o llegue al final.

Para cada método, el corredor MQTT comprueba primero si las credenciales del cliente son pertinentes para ese método. Por ejemplo, la autenticación SAT requiere un nombre de usuario que empiece por K8S-SAT y la autenticación X.509 requiere un certificado de cliente. Si las credenciales del cliente son pertinentes, el corredor MQTT comprueba si son válidas. Para más información, consulte Configuración del método de autenticación.

Para la autenticación personalizada, el corredor MQTT trata el error para comunicarse con el servidor de autenticación personalizado como que las credenciales no son pertinentes. Este comportamiento permite que el corredor MQTT vuelva a otros métodos si el servidor de autenticación personalizado no es accesible.

El flujo de autenticación finaliza cuando:

  • Se cumple una de estas condiciones:
    • Las credenciales del cliente son pertinentes y válidas para uno de los métodos.
    • Las credenciales del cliente no son pertinentes para ninguno de los métodos.
    • Las credenciales del cliente son pertinentes, pero no son válidas para ninguno de los métodos.
  • El corredor MQTT concede o deniega el acceso al cliente en función del resultado del flujo de autenticación.

Por ejemplo:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

En el ejemplo anterior se especifica custom y SAT. Cuando un cliente se conecta, el corredor MQTT intenta autenticar al cliente mediante los métodos especificados en el orden custom y luego SAT.

  1. El corredor MQTT comprueba si las credenciales del cliente son válidas para la autenticación personalizada. Dado que la autenticación personalizada se basa en un servidor externo para determinar la validez de las credenciales, el corredor considera todas las credenciales pertinentes para la autenticación personalizada y las reenvía al servidor de autenticación personalizado.
  2. Si el servidor de autenticación personalizado responde con un resultadoPass o Fail, finaliza el flujo de autenticación. Si el servidor de autenticación personalizado no está disponible, el corredor MQTT recurre al resto de métodos especificados, donde SAT es el siguiente.
  3. El corredor MQTT intenta autenticar las credenciales como credenciales SAT.

Si el servidor de autenticación personalizado no está disponible y todos los métodos posteriores determinaron que las credenciales proporcionadas no son pertinentes, el corredor deniega la conexión del cliente.

Configuración del método de autenticación

Puede agregar métodos de autenticación como X.509, SAT o personalizados a las directivas de autenticación.

Para agregar un método de autenticación a una directiva:

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione la pestaña Autenticación.

  4. Elija una directiva de autenticación existente o cree una nueva.

  5. Para agregar un nuevo método, seleccione Agregar método.

  6. Elija el tipo de método en la lista desplegable y seleccione Agregar detalles para configurar el método.

    Captura de pantalla que muestra el uso de Azure Portal para agregar un método de directiva de autenticación del corredor MQTT.

Para obtener más información sobre cada una de las opciones de autenticación, consulte las siguientes secciones para cada método.

Para más información sobre cómo habilitar la configuración segura mediante la configuración de la instancia de Azure Key Vault y la habilitación de identidades de carga de trabajo, consulte Habilitar la configuración segura en la implementación de Operaciones de IoT de Azure.

X.509

Sugerencia

Para obtener un ejemplo completo de cómo configurar la autenticación X.509, consulte Tutorial: TLS, autenticación de cliente X.509, autenticación de cliente X.509 y autorización de control de acceso basado en atributos (ABAC).

Con la autenticación X.509, el corredor MQTT usa un certificado de entidad de certificación (CA) de confianza para validar los certificados de cliente. Esta entidad de certificación de confianza puede ser una entidad de certificación raíz o intermedia. El agente comprueba la cadena de certificados de cliente con el certificado de entidad de certificación de confianza. Si la cadena es válida, el cliente se autentica.

Para usar la autenticación X.509 con un certificado de CA de confianza, se deben cumplir los siguientes requisitos:

  • Protocolo de seguridad de la capa de transporte (TLS): dado que X.509 se basa en certificados de cliente TLS, TLS debe estar habilitado para los puertos mediante la autenticación X.509.
  • Algoritmos de clave: Se admiten claves EC y RSA, pero todos los certificados de la cadena deben usar el mismo algoritmo de clave.
  • Formato: el certificado de CA debe estar en formato correo con privacidad mejorada (PEM).

Sugerencia

El formato PEM es un formato común para certificados y claves. Los archivos PEM son archivos ASCII codificados en Base64 con encabezados como -----BEGIN CERTIFICATE----- y -----BEGIN EC PRIVATE KEY-----.

Si tiene un certificado en otro formato, puede convertirlo a PEM mediante OpenSSL. Para obtener más información, vea Convertir un certificado en el formato adecuado.

Obtención de un certificado de entidad de certificación de confianza

En una configuración de producción, el certificado de entidad de certificación lo proporciona la infraestructura de clave pública (PKI) de una organización o una entidad de certificación pública.

Para las pruebas, cree un certificado de entidad de certificación autofirmado con OpenSSL. Por ejemplo, ejecute el siguiente comando para generar un certificado de entidad de certificación autofirmado con una clave RSA, un nombre distintivo CN=Contoso Root CA Cert, y una validez de 365 días:

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

El mismo comando con CLI de paso, que es una herramienta cómoda para administrar certificados, es:

step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
 --not-after 8760h

Estos comandos crean un certificado de CA ca.pem y una clave privada ca-key.pem en formato PEM. El certificado de CA ca.pem se puede importar al corredor MQTT para la autenticación X.509.

Importar un certificado de CA de confianza

Para empezar a trabajar con la autenticación X.509, importe el certificado de entidad de certificación de confianza en ConfigMap en el espacio de nombres azure-iot-operations. Para importar un certificado de entidad de certificación de confianza ca.pem en un objeto ConfigMap denominado client-ca, ejecute:

kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations

En este ejemplo, el certificado de entidad de certificación se importa en la clave ca.pem. El corredor MQTT confía en todos los certificados de CA en ConfigMap, por lo que puede usar cualquier cosa para el nombre de la clave.

Para comprobar que el certificado de CA raíz se ha importado correctamente, ejecute kubectl describe configmap. El resultado muestra la misma codificación en Base64 del archivo de certificado PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----


BinaryData
====

Configuración del método de autenticación X.509

Una vez importado el certificado de CA de confianza, habilite la autenticación de cliente X.509 agregándola como método de autenticación en un recurso de BrokerAuthentication. Asegúrese de que este recurso esté vinculado a un puerto de agente de escucha habilitado para TLS.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione la pestaña Autenticación.

  4. Elija una directiva de autenticación existente o cree una nueva.

  5. Para agregar un nuevo método, seleccione Agregar método.

  6. Elija el tipo de método X.509 en la lista desplegable. A continuación, seleccione Agregar detalles para configurar el método.

  7. En el panel Detalles de autenticación X.509, especifique el nombre ConfigMap del certificado de CA de confianza con formato JSON.

    {
    "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
}

    Reemplace <TRUSTED_CA_CONFIGMAP> por el nombre de ConfigMap que contiene el certificado de entidad de certificación de confianza. Por ejemplo, use "trustedClientCaCert": "client-ca".

    Captura de pantalla que muestra el uso de Azure Portal para establecer el método de autenticación X.509 del corredor MQTT.

  8. Opcionalmente, agregue atributos de autorización para los clientes utilizando certificados X.509. Para más información, consulte atributos de certificado para la autorización.

  9. Seleccione Aplicar para guardar los cambios.

Opcional: Atributos de certificado para la autorización

Los atributos X.509 se pueden especificar en el recurso BrokerAuthentication para autorizar a los clientes en función de las propiedades del certificado. Los atributos se definen en el campo authorizationAttributes.

Por ejemplo:

En Azure Portal, al configurar el método de autenticación X.509, agregue los atributos de autorización en el panel Detalles de autenticación X.509 en formato JSON.

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "authorizationAttributes": {
    "root": {
      "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
      "attributes": {
        "organization": "contoso"
      }
    },
    "intermediate": {
      "subject": "CN = Contoso Intermediate CA",
      "attributes": {
        "city": "seattle",
        "foo": "bar"
      }
    },
    "smartfan": {
      "subject": "CN = smart-fan",
      "attributes": {
        "building": "17"
      }
    }
  }
}

En este ejemplo, cada cliente que tiene un certificado emitido por la entidad de certificación raíz con nombre distintivo CN = Contoso Root CA Cert, OU = Engineering, C = US o la entidad de certificación intermedia con nombre distintivo CN = Contoso Intermediate CA recibe los atributos enumerados. Además, el certificado de cliente de smart-fan recibe atributos específicos de él.

La coincidencia de atributos siempre comienza desde el certificado de cliente hoja y, a continuación, pasa por la cadena. La asignación de atributos se detiene después de la primera coincidencia. En el ejemplo anterior, incluso si smart-fan tiene el certificado intermedio CN = Contoso Intermediate CA, no obtiene los atributos asociados.

Puede aplicar reglas de autorización a los clientes mediante certificados X.509 con estos atributos. Para obtener más información, consulte Autorización de clientes que usan la autenticación X.509.

Habilitación de la autenticación X.509 para un puerto de escucha

Después de importar el certificado de CA de confianza y configurar el recurso de BrokerAuthentication, vincule a un puerto de agente de escucha habilitado para TLS. Este paso es importante porque la autenticación X.509 se basa en TLS para la validación de certificados de cliente.

Para obtener un puerto de escucha habilitado para TLS, consulte Habilitación de la administración manual de certificados TLS para un puerto y Habilitación de la administración automática de certificados TLS para un puerto.

Nota:

Habilitar TLS en un puerto de agente de escucha del corredor significa que el este usa un certificado de servidor para el cifrado TLS. Cuando los clientes se conectan a este puerto, deben confiar en el certificado de servidor al tener el certificado de entidad de certificación que lo firmó en su almacén de confianza. Este proceso se conoce como distribución de confianza o agrupación de confianza. Es importante comprender la diferencia entre la validación del servidor y la validación de cliente:

  • Validación de cliente: El agente MQTT (servidor) comprueba el certificado de cliente con el certificado de entidad de certificación de confianza especificado en el campo trustedClientCaCert para la autenticación de cliente X.509.
  • Validación del servidor: los clientes (como Mosquitto o MQTTX) comprueban el certificado de servidor del corredor MQTT en oposición al certificado de CA de confianza en su almacén de confianza. Para los clientes de Mosquitto, use el parámetro --cafile para especificar el archivo de certificado de CA. Para MQTTX, agregue el certificado de entidad de certificación al almacén de confianza en la configuración.

Después de habilitar la autenticación X.509, asegúrese de que los clientes confíen en el certificado de servidor del corredor al tener el certificado de CA del lado servidor en su almacén de confianza. No confunda la confianza en el certificado de CA del lado servidor con el certificado de CA del lado cliente usado para la autenticación de cliente que se especifica en el campo trustedClientCaCert.

Para obtener un ejemplo completo, consulte Tutorial: Autenticación de cliente TLS, X.509 y autorización de control de acceso basado en atributos (ABAC).

Conecte el cliente Mosquitto al corredor MQTT con un certificado de cliente X.509

Un cliente como Mosquitto necesita dos archivos para poder conectarse al corredor MQTT con la autenticación de cliente TLS y X.509:

  • El parámetro --cert especifica el archivo PEM del certificado de cliente. Este archivo también debe incluir cualquier certificado intermedio para ayudar al agente MQTT a crear la cadena de certificados completa.
  • El parámetro --key especifica el archivo PEM de la clave privada de cliente.

En los casos en los que el corredor MQTT usa un certificado de CA autofirmado para emitir su certificado de servidor TLS, se necesita el parámetro --cafile. Este archivo contiene el certificado de CA (también conocido como agrupación de confianza) que el cliente Mosquitto usa para validar el certificado de servidor del corredor al conectarse a través de TLS. Si el emisor del certificado de servidor del corredor MQTT forma parte del almacén raíz del sistema (como CA públicas conocidas), se puede omitir el parámetro --cafile.

Por ejemplo:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem

Descripción del flujo de autenticación de cliente X.509 del corredor MQTT

Diagrama que muestra el flujo de autenticación de cliente X.509.

Siga estos pasos para la autenticación de cliente:

  1. Cuando se activa la autenticación de cliente X.509, los clientes que se conectan deben presentar su certificado de cliente y los certificados intermedios para permitir que el corredor MQTT cree una cadena de certificados con la raíz en uno de sus certificados de confianza configurados.
  2. El equilibrador de carga dirige la comunicación a uno de los agentes de front-end.
  3. Una vez que el corredor de front-end recibe el certificado de cliente, intenta crear una cadena de certificados que tiene como raíz uno de los certificados configurados. Si el corredor de front-end ha creado correctamente una cadena y se comprueba la cadena presentada, finaliza el protocolo de enlace TLS. El cliente de conexión puede enviar paquetes MQTT al front-end mediante el canal TLS.
  4. El canal TLS está abierto, pero la autenticación o autorización de cliente aún no ha finalizado.
  5. Después, el cliente envía un paquete CONECTAR al corredor MQTT.
  6. El paquete CONNECT se enruta de nuevo a un front-end.
  7. El front-end recopila todas las credenciales que el cliente presentó hasta ahora, como los datos de autenticación del paquete CONNECT y la cadena de certificados de cliente presentadas durante el protocolo de enlace TLS.
  8. El front-end envía estas credenciales al servicio de autenticación. El servicio de autenticación comprueba de nuevo la cadena de certificados y recopila los nombres de firmante de todos los certificados de la cadena.
  9. El servicio de autenticación usa sus reglas de autorización configuradas para determinar qué atributos tienen los clientes que se conectan. Estos atributos determinan qué operaciones puede ejecutar el cliente, incluido el propio paquete CONECTAR.
  10. El servicio de autenticación devuelve la decisión al corredor de front-end.
  11. El agente de front-end conoce los atributos de cliente y si se le permite conectarse. Si es así, la conexión MQTT se completa y el cliente puede seguir enviando y recibiendo paquetes MQTT según lo determinado por sus reglas de autorización.

Tokens de cuenta de servicio de Kubernetes

Las SAT de Kubernetes son tokens web JSON asociados a cuentas de servicio de Kubernetes. Los clientes presentan SAT al corredor MQTT para autenticarse a sí mismos.

El corredor MQTT usa tokens de cuenta de servicio enlazados que se detallan en la publicación ¿Qué necesitan conocer los usuarios de GKE sobre los nuevos tokens de cuenta de servicio de Kubernetes?. Estas son las características principales de la publicación:

Los tokens enlazados se iniciaron en Kubernetes 1.13 y se convirtieron en el formato predeterminado en la versión 1.21. Los tokens enlazados abordan toda la funcionalidad limitada de los tokens heredados y mucho más:

  • Los tokens son difíciles de robar y mal utilizar. Están enlazados a tiempo, enlazados a audiencia y enlazados a objetos.
  • Adoptan un formato estandarizado. OpenID Connect (OIDC), con OIDC Discovery completo, facilita la aceptación de los proveedores de servicios.
  • Se distribuyen a pods de forma más segura mediante un nuevo tipo de volumen proyectado de Kubelet.

El corredor comprueba los tokens mediante la API de revisión de tokens de Kubernetes. Habilite la característica TokenRequestProjection de Kubernetes para especificar audiences (valor predeterminado desde la versión 1.21). Si esta característica no está habilitada, no puede usar los SAT.

Crear una cuenta de servicio

Para crear SAT, primero crear una cuenta de servicio. Con el siguiente comando se crea una cuenta de servicio llamada mqtt-client:

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Opcional: Agregar atributos para la autorización

Los clientes que se autentican a través de SAT pueden tener sus cuentas de servicio anotadas con atributos que se usarán con directivas de autorización. Para distinguir estas anotaciones de otras, comienzan por aio-broker-auth/ prefijo.

Puede anotar una cuenta de servicio mediante kubectl annotate:

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

O bien, puede agregar las anotaciones al archivo de manifiesto de la cuenta de servicio:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <SERVICE_ACCOUNT_NAME>
  namespace: azure-iot-operations
  annotations:
    aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
    aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>

Para más información, consulte Autorización de clientes que usan tokens de cuenta de servicio de Kubernetes.

Habilite la autenticación SAT

Modifique el valor authenticationMethods de un recurso BrokerAuthentication para especificar ServiceAccountToken como método de autenticación válido. El parámetro audiences especifica la lista de audiencias válidas para tokens. Elija valores únicos que identifiquen el servicio de corredor MQTT. Debe especificar al menos un público y todos los SAT deben coincidir con uno de los públicos especificados.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.
  2. En Componentes, seleccione MQTT Broker.
  3. Seleccione la pestaña Autenticación.
  4. Elija una directiva de autenticación existente o cree una nueva.
  5. Para agregar un nuevo método, seleccione Agregar método.
  6. Elija el tipo de método Kubernetes SAT en la lista desplegable. A continuación, seleccione Agregar detalles para configurar el método.

Captura de pantalla que muestra la utilización de Azure Portal para establecer el método de autenticación SAT del corredor MQTT.

Prueba de la autenticación SAT

La autenticación SAT usa los campos de autenticación mejorados de MQTT v5. Un cliente debe establecer el método de autenticación mejorado en K8S-SAT y los datos de autenticación mejorados en el token.

Por ejemplo, use Mosquitto (algunos campos están omitidos por brevedad):

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

Aquí, <TOKEN> es el token de la cuenta de servicio. Para obtener un token de prueba, ejecute:

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

Aquí, <SERVICE_ACCOUNT> es el nombre de la cuenta de servicio que creó y <AUDIENCE> es una de las audiencias configuradas en el recurso BrokerAuthentication.

Para obtener un ejemplo sobre cómo configurar un pod de Kubernetes para usar la autenticación SAT, consulte Conectar con el cliente de escucha por defecto dentro del clúster.

En la configuración del pod el campo serviceAccountNamedebe coincidir con la cuenta de servicio asociada al token que se está usando. El camposerviceAccountToken.audience debe ser uno de los audiences configurados en el recurso BrokerAuthentication.

Actualizar tokens de cuenta de servicio

Los tokens de cuenta de servicio son válidos durante un tiempo limitado y configurados con expirationSeconds. Sin embargo, Kubernetes actualiza automáticamente el token antes de que expire. El token se actualiza en segundo plano y el cliente no necesita hacer nada más que capturarlo de nuevo.

Por ejemplo, si el cliente es un pod que usa el token montado como un volumen, como en el ejemplo de autenticación SAT de prueba, el token más reciente está disponible en la misma ruta de acceso /var/run/secrets/tokens/broker-sat. Al realizar una nueva conexión, el cliente puede capturar el token más reciente y usarlo para autenticarse. El cliente también debe tener un mecanismo para controlar errores no autorizados de MQTT mediante la captura del token más reciente y el reintento de la conexión.

Autenticación personalizada

Amplíe la autenticación de cliente más allá de los métodos de autenticación proporcionados con la autenticación personalizada. Es conectable, ya que el servicio puede ser cualquier cosa siempre que se ajuste a la API.

Cuando un cliente se conecta al agente MQTT con la autenticación personalizada habilitada, el agente envía una solicitud HTTPS a un servidor de autenticación personalizado con las credenciales del cliente. A continuación, el servidor responde con aprobación o denegación, incluidos los atributos de autorización del cliente.

Creación de un servicio de autenticación personalizada

El servidor de autenticación personalizado se implementa por separado del corredor MQTT.

En GitHub, se puede encontrar un ejemplo de servidor de autenticación personalizada e instrucciones. Use este ejemplo como plantilla y punto de partida para implementar su propia lógica de autenticación personalizada.

API

La API entre el corredor MQTT y el servidor de autenticación personalizado sigue la especificación de API para la autenticación personalizada. La especificación openAPI está disponible en GitHub.

Se requiere HTTPS con cifrado TLS

El corredor MQTT envía solicitudes que contienen credenciales de cliente confidenciales al servidor de autenticación personalizado. Para proteger estas credenciales, la comunicación entre el corredor MQTT y el servidor de autenticación personalizado se debe cifrar con TLS.

El servidor de autenticación personalizado debe presentar un certificado de servidor y el corredor MQTT debe tener un certificado de CA raíz de confianza para validarlo. Opcionalmente, el servidor de autenticación personalizado podría exigir que el corredor MQTT presente un certificado de cliente para autenticarse.

Habilitación de la autenticación personalizada para un cliente de escucha

Modifique la configuración de Métodos de autenticación en un recurso BrokerAuthentication para especificar Personalizado como un método de autenticación válido. A continuación, especifique los parámetros necesarios para comunicarse con un servidor de autenticación personalizada.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione la pestaña Autenticación.

  4. Elija una directiva de autenticación existente o cree una nueva.

  5. Para agregar un nuevo método, seleccione Agregar método.

  6. Elija el tipo de método Personalizado en la lista desplegable. A continuación, seleccione Agregar detalles para configurar el método.

    Captura de pantalla en la que se muestra el uso de Azure Portal para establecer el método de autenticación personalizado del corredor MQTT.

Deshabilitación de la autenticación

Para realizar pruebas, puede desactivar la autenticación para un puerto de escucha de intermediario. No se recomienda deshabilitar la autenticación para entornos de producción.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.
  2. En Componentes, seleccione MQTT Broker.
  3. Seleccione el cliente de escucha del corredor que desea editar en la lista.
  4. En el puerto que desea deshabilitar la autenticación, seleccione Ninguno en la lista desplegable de autenticación.

Los clientes se desconectan después de que expiren las credenciales

El corredor MQTT desconecta los clientes cuando expiran sus credenciales. La desconexión después de la expiración de credenciales se aplica a todos los clientes que se conectan a los front-end del corredor MQTT, incluidos los siguientes:

  • Los clientes autenticados con SAT se desconectan cuando expira su SAT.
  • Los clientes autenticados con X.509 se desconectan cuando expira su certificado de cliente.
  • Los clientes autenticados con la autenticación personalizada se desconectan en función de la hora de expiración devuelta del servidor de autenticación personalizada.

Al desconectarse, se cierra la conexión de red del cliente. El cliente no recibe un paquete MQTT DISCONNECT, pero el agente registra un mensaje que desconecta el cliente.

Los clientes MQTT v5 autenticados con SAT y la autenticación personalizada se pueden volver a autenticar con una nueva credencial antes de que expire su credencial inicial. Los clientes X.509 no se pueden volver a autenticar y deben volver a establecer la conexión, ya que la autenticación se realiza en la capa TLS.

Los clientes pueden volver a autenticarse enviando un paquete MQTT v5 AUTH por motivo ReAuth.

Los clientes SAT envían un AUTH de cliente con los campos method: K8S-SAT y data: <token>. Los clientes de autenticación personalizada establecen el método y el campo de datos según sea necesario para el servidor de autenticación personalizada.

La reautenticación correcta actualiza la expiración de las credenciales del cliente con la hora de expiración de su nueva credencial. El corredor responde con un paquete AUTH Success. Error de autenticación debido a incidencias transitorias, como que el servidor de autenticación personalizado no está disponible, hace que el corredor responda con un paquete AUTH ContinueAuthentication. El cliente puede volver a intentarlo más tarde. Otros errores de autenticación provocan que el agente envíe un paquete DISCONNECT y cierre la conexión de red del cliente.

Contenido relacionado