Configurar TLS con administración automática de certificados para asegurar la comunicación MQTT en el corredor MQTT
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.
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
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.
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
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: default
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 servicioCLUSTER-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.