Configuración de TLS con administración automática de certificados para proteger la comunicación MQTT en la 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.
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
kubectlpara 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) 4d20hSi 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. La versión preliminar de Azure IoT MQ se puede usar con cualquier tipo de emisor de administrador de certificados.
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: 256Cree 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 se pueden cambiar modificando la especificación de 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.
Puede usar Azure Key Vault para administrar secretos de 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.
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: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
name: my-new-tls-listener
namespace: azure-iot-operations
spec:
brokerRef: broker
authenticationEnabled: false # If set to true, a BrokerAuthentication resource must be configured
authorizationEnabled: false
serviceType: loadBalancer # Optional; defaults to 'clusterIP'
serviceName: my-new-tls-listener # Avoid conflicts with default service name 'aio-mq-dmqtt-frontend'
port: 8884 # Avoid conflicts with default port 8883
tls:
automatic:
issuerRef:
name: my-issuer
kind: Issuer
Una vez configurado el recurso BrokerListener, IoT MQ 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, IoT MQ permite personalizar determinadas propiedades especificando en el recurso BrokerListener, en tls.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
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-listenerpor 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. Por ejemplo, nombre de usuario y contraseña.
Entidad de certificación raíz predeterminada y emisor con la versión preliminar de operaciones de Azure IoT
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.
El certificado CA está autofirmado y no es de confianza para ningún cliente ajeno a las Operaciones de IoT de Azure. El asunto del certificado de entidad de certificación es
CN = Azure IoT Operations Quickstart Root CA - Not for Productiony expira en 30 días a partir del momento de la instalación.El certificado de entidad de certificación raíz se almacena en un secreto de Kubernetes denominado
aio-ca-key-pair-test-only.La parte pública del certificado de entidad de certificación raíz se almacena en un objeto ConfigMap denominado
aio-ca-trust-bundle-test-only. Puede recuperar el certificado CA del ConfigMap e inspeccionarlo con kubectl y openssl.$ kubectl get configmap aio-ca-trust-bundle-test-only -n azure-iot-operations -o json | jq -r '.data["ca.crt"]' | openssl x509 -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 74:d8:b6:fe:63:5a:7d:24:bd:c2:c0:25:c2:d2:c7:94:66:af:36:89 Signature Algorithm: ecdsa-with-SHA256 Issuer: CN = Azure IoT Operations Quickstart Root CA - Not for Production Validity Not Before: Nov 2 00:34:31 2023 GMT Not After : Dec 2 00:34:31 2023 GMT Subject: CN = Azure IoT Operations Quickstart Root CA - Not for Production Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:51:43:93:2c:dd:6b:7e:10:18:a2:0f:ca:2e:7b: bb:ba:5c:78:81:7b:06:99:b5:a8:11:4f:bb:aa:0d: e0:06:4f:55:be:f9:5f:9e:fa:14:75:bb:c9:01:61: 0f:20:95:cd:9b:69:7c:70:98:f8:fa:a0:4c:90:da: 5b:1a:d7:e7:6b ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: Certificate Sign X509v3 Subject Key Identifier: B6:DD:8A:42:77:05:38:7A:51:B4:8D:8E:3F:2A:D1:79:32:E9:43:B9 Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:21:cd:61:d7:21:86:fd:f8:c3:6d:33:36:53:e3: a6:06:3c:a6:80:14:13:55:16:f1:19:a8:85:4b:e9:5d:61:eb: 02:20:3e:85:8a:16:d1:0f:0b:0d:5e:cd:2d:bc:39:4b:5e:57: 38:0b:ae:12:98:a9:8f:12:ea:95:45:71:bd:7c:de:9dDe manera predeterminada, ya hay un emisor de CA configurado en el
azure-iot-operationsespacio de nombres denominadoaio-ca-issuer. Se usa como emisor de CA común para todos los certificados de servidor TLS para operaciones de IoT. IoT MQ usa un emisor creado a partir del mismo certificado de entidad de certificación para emitir certificados de servidor TLS para el agente de escucha TLS predeterminado en el puerto 8883. Puede inspeccionar el emisor con el siguiente comando:$ kubectl get issuer aio-ca-issuer -n azure-iot-operations -o yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: annotations: meta.helm.sh/release-name: azure-iot-operations meta.helm.sh/release-namespace: azure-iot-operations creationTimestamp: "2023-11-01T23:10:24Z" generation: 1 labels: app.kubernetes.io/managed-by: Helm name: aio-ca-issuer namespace: azure-iot-operations resourceVersion: "2036" uid: c55974c0-e0c3-4d35-8c07-d5a0d3f79162 spec: ca: secretName: aio-ca-key-pair-test-only status: conditions: - lastTransitionTime: "2023-11-01T23:10:59Z" message: Signing CA verified observedGeneration: 1 reason: KeyPairVerified status: "True" type: Ready
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
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de