Configuración de la autenticación en versión preliminar de Azure IoT MQ
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.
Azure IoT MQ admite varios métodos de autenticación de clientes, y puede configurar cada cliente de escucha para que tenga su propio sistema de autenticación con recursos BrokerAuthentication.
Recurso BrokerAuthentication predeterminado
Operaciones de IoT de Azure implementa un recurso BrokerAuthentication predeterminado denominado authn vinculado con el cliente de escucha predeterminado denominado listener en el espacio de nombres azure-iot-operations. Se configura para usar solamente tokens de cuenta de servicio (SAT) de Kubernetes para la autenticación. Para inspeccionarlo, ejecute:
kubectl get brokerauthentication authn -n azure-iot-operations -o yaml
La salida muestra el recurso BrokerAuthentication predeterminado (para mayor brevedad, los metadatos se han quitado):
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- sat:
audiences: ["aio-mq"]
Para cambiar la configuración, modifique el valor authenticationMethods de este recurso BrokerAuthentication o cree un nuevo recurso BrokerAuthentication con otro nombre. A continuación, impleméntelo mediante kubectl apply.
Relación entre BrokerListener y BrokerAuthentication
BrokerListener y BrokerAuthentication son recursos independientes, pero están vinculados mediante listenerRef. Se aplican las reglas siguientes:
- Un recurso BrokerListener solo se puede vincular a un recurso BrokerAuthentication.
- Un recurso BrokerAuthentication se puede vincular a varios recursos BrokerListener.
- Cada recurso BrokerAuthentication puede admitir varios métodos de autenticación a la vez.
Flujo de autenticación
El orden de los métodos de autenticación de la matriz determina cómo Azure IoT MQ autentica a los clientes. Azure IoT MQ intenta autenticar las credenciales del cliente mediante el primer método especificado y recorre en iteración la matriz hasta que encuentra una coincidencia o llega al final.
Para cada método, Azure IoT MQ 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 $sat y la autenticación X.509 requiere un certificado de cliente. Si las credenciales del cliente son pertinentes, Azure IoT MQ comprueba si son válidas. Para más información, consulte Configuración del método de autenticación.
En el caso de la autenticación personalizada, el error para comunicarse con el servidor de autenticación personalizado se trata en Azure IoT MQ como que las credenciales no son pertinentes. Este comportamiento permite que Azure IoT MQ recurra a otros métodos si el servidor 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.
- Azure IoT MQ concede o deniega el acceso al cliente en función del resultado del flujo de autenticación.
Gracias a los diversos métodos de autenticación, Azure IoT MQ tiene un mecanismo de reserva. Por ejemplo:
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- custom:
# ...
- sat:
# ...
- usernamePassword:
# ...
En el ejemplo anterior se especifica la autenticación con nombre de usuario y contraseña, con SAT y personalizada. Cuando un cliente se conecta, Azure IoT MQ intenta autenticarlo mediante los métodos especificados en el orden especificado personalizada > SAT > nombre de usuario y contraseña.
Azure IoT MQ 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 agente considera todas las credenciales pertinentes para la autenticación personalizada y las reenvía al servidor de autenticación personalizada.
Si el servidor de autenticación personalizada responde con
PassoFail, finaliza el flujo de autenticación. Sin embargo, si el servidor de autenticación personalizada no está disponible, Azure IoT MQ recurre al resto de métodos especificados, donde SAT es el siguiente.Azure IoT MQ intenta autenticar las credenciales como credenciales SAT. Si el nombre de usuario de MQTT comienza con
$sat, Azure IoT MQ evalúa la contraseña MQTT como SAT. De lo contrario, el agente recurre al nombre de usuario y contraseña y comprueba si el nombre de usuario y la contraseña de MQTT proporcionados son válidos.
Si el servidor de autenticación personalizada no está disponible y todos los métodos posteriores determinaron que las credenciales proporcionadas no son pertinentes, el agente deniega la conexión del cliente.
Deshabilitación de la autenticación
Para realizar pruebas, deshabilite la autenticación; para ello, modifíquela en el recurso BrokerListener.
spec:
authenticationEnabled: false
Configuración del método de autenticación
Para más información sobre cada una de las opciones de autenticación, consulte las secciones siguientes:
Nombre de usuario y contraseña
Cada cliente tiene las siguientes propiedades necesarias:
- Nombre de usuario
- Contraseña (codificada en PBKDF2)
- Atributos de autorización
Por ejemplo, comience con un atributo clients.toml con identidades y contraseñas codificadas en PBKDF2.
# Credential #1
# username: client1
# password: password
[client1]
password = "$pbkdf2-sha512$i=100000,l=64$HqJwOCHweNk1pLryiu3RsA$KVSvxKYcibIG5S5n55RvxKRTdAAfCUtBJoy5IuFzdSZyzkwvUcU+FPawEWFPn+06JyZsndfRTfpiEh+2eSJLkg"
[client1.attributes]
floor = "floor1"
site = "site1"
# Credential #2
# username: client2
# password: password2
[client2]
password = "$pbkdf2-sha512$i=100000,l=64$+H7jXzcEbq2kkyvpxtxePQ$jTzW6fSesiuNRLMIkDDAzBEILk7iyyDZ3rjlEwQap4UJP4TaCR+EXQXNukO7qNJWlPPP8leNnJDCBgX/255Ezw"
[client2.attributes]
floor = "floor2"
site = "site1"
Para codificar la contraseña mediante PBKDF2, use la extensión de la CLI de operaciones de Azure IoT que incluye el comando az iot ops mq get-password-hash. Genera un hash de contraseña PBKDF2 a partir de una frase de contraseña mediante el algoritmo SHA-512 y una sal aleatoria de 128 bits.
az iot ops mq get-password-hash --phrase TestPassword
La salida muestra el hash de contraseña PBKDF2 que se va a copiar:
{
"hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}
A continuación, guarde el archivo como passwords.toml e impórtelo en un secreto de Kubernetes con esa clave.
kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations
Incluya una referencia al secreto en el recurso personalizado BrokerAuthentication.
spec:
authenticationMethods:
- usernamePassword:
secretName: passwords-db
Puede que los cambios tarden unos minutos en surtir efecto.
Puede usar Azure Key Vault para administrar secretos de Azure IoT MQ en lugar de secretos de Kubernetes. Para más información, consulte Administración de secretos mediante Azure Key Vault o secretos de Kubernetes.
Certificado de cliente X.509
Requisitos previos
- Azure IoT MQ configurado con TLS habilitado.
- Step-CLI
- Certificados de cliente y la cadena de certificados emisora en archivos PEM. Si no tiene ninguno, use Step CLI para generar algunos.
- Familiaridad con la criptografía de clave pública y términos como CA raíz, clave privada y certificados intermedios.
Se admiten claves EC y RSA, pero todos los certificados de la cadena deben usar el mismo algoritmo de clave. Si va a importar sus propios certificados de CA, asegúrese de que el certificado de cliente use el mismo algoritmo de clave que las entidades de certificación.
Importar certificado de CA raíz de cliente de confianza
Se requiere un certificado de CA raíz de confianza para validar el certificado de cliente. Para importar un certificado raíz que se pueda usar para validar los certificados de cliente, primero importe el certificado PEM como ConfigMap en la clave client_ca.pem. Los certificados de cliente deben tener como raíz esta CA para que Azure IoT MQ los autentique.
kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations
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
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----
BinaryData
====
Importación de la asignación de certificado a atributo
Para usar directivas de autorización para los clientes que emplean propiedades de los certificados X.509, cree un archivo TOML de asignación de certificado a atributo e impórtelo como un secreto de Kubernetes en la clave x509Attributes.toml. Este archivo asigna el nombre del firmante del certificado de cliente a los atributos que se pueden usar en las directivas de autorización. Es necesario incluso si no usa directivas de autorización.
kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations
Para más información sobre la sintaxis del archivo de atributos, consulte Autorización de clientes que usan la autenticación X.509.
Al igual que con la autenticación de nombre de usuario y contraseña, puede usar Azure Key Vault para administrar este secreto en lugar de los secretos de Kubernetes. Para más información, consulte Administración de secretos mediante Azure Key Vault o secretos de Kubernetes.
Habilitación de la autenticación de clientes X.509
Por último, una vez importados el certificado de CA raíz del cliente de confianza y la asignación de certificado a atributo, habilite la autenticación de cliente X.509 agregando x509 como uno de los métodos de autenticación como parte de un recurso BrokerAuthentication vinculado a un cliente de escucha habilitado para TLS. Por ejemplo:
spec:
authenticationMethods:
- x509:
trustedClientCaCert: client-ca
attributes:
secretName: x509-attributes
Conexión del cliente mosquitto a Azure IoT MQ con un certificado de cliente X.509
Un cliente como mosquitto necesita tres archivos para poder conectarse a Azure IoT MQ con la autenticación de cliente TLS y X.509. Por ejemplo:
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem
En el ejemplo:
- El parámetro
--certespecifica el archivo PEM del certificado de cliente. - El parámetro
--keyespecifica el archivo PEM de la clave privada de cliente. - El tercer parámetro
--cafilees el más complejo: la base de datos de certificados de confianza, que se usa con dos propósitos:- Cuando el cliente mosquitto se conecta a Azure IoT MQ a través de TLS, valida el certificado de servidor. Busca certificados raíz en la base de datos para crear una cadena de confianza con el certificado del servidor. Debido a esto, el certificado raíz del servidor debe copiarse en este archivo.
- Cuando Azure IoT MQ solicita un certificado de cliente desde el cliente mosquitto, también requiere una cadena de certificados válida para enviar al servidor. El parámetro
--certindica a mosquitto qué certificado enviar, pero no es suficiente. Azure IoT MQ no puede comprobar este certificado por sí solo porque también necesita el certificado intermedio. Mosquitto usa el archivo de base de datos para compilar la cadena de certificados necesaria. Para admitir esto,cafiledebe contener los certificados intermedio y raíz.
Descripción del flujo de autenticación de cliente X.509 de Azure IoT MQ
Estos son los pasos del flujo de autenticación de cliente:
- 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 Azure IoT MQ cree una cadena de certificados raíz a uno de sus certificados de confianza configurados.
- El equilibrador de carga dirige la comunicación a uno de los agentes de front-end.
- Una vez que el agente de front-end recibe el certificado de cliente, intenta crear una cadena de certificados que tiene como raíz uno de los certificados configurados. El certificado es necesario para el protocolo de enlace TLS. Si el agente 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 compilado.
- El canal TLS está abierto, pero la autenticación o autorización de cliente aún no ha finalizado.
- El cliente envía entonces un paquete CONNECT a Azure IoT MQ.
- El paquete CONNECT se enruta de nuevo a un front-end.
- El front-end recopila todas las credenciales que el cliente presentó hasta ahora, como los campos de nombre de usuario y contraseña, los datos de autenticación del paquete CONNECT y la cadena de certificados de cliente presentada durante el protocolo de enlace TLS.
- 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.
- 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 CONNECT.
- El servicio de autenticación devuelve la decisión al agente de front-end.
- El agente de front-end conoce los atributos de cliente y si se le permite conectarse. Si es así, la conexión MQTT finaliza y el cliente puede seguir enviando y recibiendo paquetes MQTT determinados por sus reglas de autorización.
Tokens de cuenta de servicio de Kubernetes
Los tokens de cuenta de servicio de Kubernetes (SAT) son tokens JSON Web Token asociados a cuentas de servicio de Kubernetes. Los clientes presentan SAT a MQTT broker de Azure IoT MQ para autenticarse a sí mismos.
Azure IoT MQ usa tokens de cuenta de servicio enlazados que se detallan en la publicación ¿Qué necesitan los usuarios de GKE para conocer los nuevos tokens de cuenta de servicio de Kubernetes? Estas son las características destacadas de la publicación:
Lanzados en Kubernetes 1.13 y convertidos 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 en sí son más difíciles de robar y utilizar indebidamente; están vinculados al tiempo, al público y al objeto.
- Adoptan un formato estandarizado: OpenID Connect (OIDC), con detección completa de OIDC, lo que facilita que los proveedores de servicios los acepten.
- Se distribuyen a pods de forma más segura mediante un nuevo tipo de volumen proyectado de Kubelet.
El agente 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 se pueden usar SAT.
Crear una cuenta de servicio
Para crear SAT, cree primero 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
Adición de atributos de autorización
La autenticación de cliente mediante SAT puede hacer que sus SAT se anoten con atributos que se usarán con directivas de autorización personalizadas. Para más información, consulte Autorización de clientes que usan tokens de cuenta de servicio de Kubernetes.
Habilitación de la autenticación de tokens de cuenta de servicio (SAT)
Modifique el valor authenticationMethods de un recurso BrokerAuthentication para especificar sat como método de autenticación válido. El valor audiences especifica la lista de públicos válidos para tokens. Elija valores únicos que identifiquen el servicio de agente de Azure IoT MQ. Debe especificar al menos un público y todos los SAT deben coincidir con uno de los públicos especificados.
spec:
authenticationMethods:
- sat:
audiences: ["aio-mq", "my-audience"]
Aplique los cambios con kubectl apply. Puede que los cambios tarden unos minutos en surtir efecto.
Prueba de la autenticación SAT
La autenticación SAT debe usarse desde un cliente del mismo clúster que Azure IoT MQ. El siguiente comando especifica un pod que tiene el cliente mosquitto y monta el SAT creado en los pasos anteriores en el pod.
apiVersion: v1
kind: Pod
metadata:
name: mqtt-client
namespace: azure-iot-operations
spec:
serviceAccountName: mqtt-client
containers:
- image: efrecon/mqtt-client
name: mqtt-client
command: ["sleep", "infinity"]
volumeMounts:
- name: mqtt-client-token
mountPath: /var/run/secrets/tokens
volumes:
- name: mqtt-client-token
projected:
sources:
- serviceAccountToken:
path: mqtt-client-token
audience: my-audience
expirationSeconds: 86400
Aquí, el campo serviceAccountName de la configuración del pod debe coincidir con la cuenta de servicio asociada al token que se está usando. Además, el campo serviceAccountToken.audience de la configuración del pod debe ser uno de los valores audiences configurados en el recurso BrokerAuthentication.
Una vez creado el pod, inicie un shell en él:
kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh
El token se monta en la ruta de acceso especificada en el valor /var/run/secrets/tokens de configuración del ejemplo anterior. Recupere el token y úselo para autenticarse.
token=$(cat /var/run/secrets/tokens/mqtt-client-token)
mosquitto_pub -h aio-mq-dmqtt-frontend -V mqttv5 -t hello -m world -u '$sat' -P "$token"
El nombre de usuario MQTT debe establecerse en $sat. La contraseña MQTT debe establecerse en el propio SAT.
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/mqtt-client-token. 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 a Azure IoT MQ y está habilitada la autenticación personalizada, Azure IoT MQ delega la comprobación de las credenciales de cliente en un servidor de autenticación personalizada con una solicitud HTTP junto con todas las credenciales que presenta el cliente. El servidor de autenticación personalizada responde con la aprobación o la denegación del cliente con los atributos de autorización de este.
Creación de un servicio de autenticación personalizada
El servidor de autenticación personalizada se implementa por separado de Azure IoT MQ.
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 Azure IoT MQ y el servidor de autenticación personalizada sigue la especificación de API de la autenticación personalizada. La especificación openAPI está disponible en GitHub.
Se requiere HTTPS con cifrado TLS
Azure IoT MQ envía solicitudes que contienen credenciales de cliente confidenciales al servidor de autenticación personalizado. Para proteger estas credenciales, la comunicación entre Azure IoT MQ y el servidor de autenticación personalizada debe cifrarse con TLS.
El servidor de autenticación personalizada debe presentar un certificado de servidor y Azure IoT MQ debe tener un certificado de CA raíz de confianza para validarlo. Opcionalmente, el servidor de autenticación personalizada podría requerir que Azure IoT MQ presente un certificado de cliente para autenticarse.
Habilitación de la autenticación personalizada para un cliente de escucha
Modifique el valor authenticationMethods de un recurso BrokerAuthentication para especificar custom como método de autenticación válido. A continuación, especifique los parámetros necesarios para comunicarse con un servidor de autenticación personalizada.
En este ejemplo se muestran todos los parámetros posibles. Los parámetros exactos necesarios dependen de los requisitos personalizados de cada servidor.
spec:
authenticationMethods:
- custom:
# Endpoint for custom authentication requests. Required.
endpoint: https://auth-server-template
# Trusted CA certificate for validating custom authentication server certificate.
# Required unless the server certificate is publicly-rooted.
caCert: custom-auth-ca
# Authentication between Azure IoT MQ with the custom authentication server.
# The broker may present X.509 credentials or no credentials to the server.
auth:
x509:
secretName: custom-auth-client-cert
namespace: azure-iot-operations
# Optional additional HTTP headers that the broker will send to the
# custom authentication server.
headers:
header_key: header_value