Compartir a través de

Protección de la comunicación de agente MQTT mediante BrokerListener

  • 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 recurso BrokerListener corresponde a un punto de conexión de red que expone el agente a los clientes a través de la red. Puede tener uno o varios recursos BrokerListener para cada agente, con varios puertos y control de acceso diferente en cada uno.

Cada puerto BrokerListener puede tener sus propias reglas de autenticación y autorización que definen quién puede conectarse en ese puerto del agente de escucha y qué acciones pueden realizar en el agente. Puede usar BrokerAuthentication y BrokerAuthorization recursos para especificar las directivas de control de acceso para cada puerto 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.

Sugerencia

La implementación predeterminada del agente MQTT es un servicio IP de clúster que requiere que los clientes se conecten con el protocolo de Seguridad de la capa de transporte (TLS) y se autentiquen con tokens de cuenta de servicio. Los clientes que se conectan desde fuera del clúster necesitan de configuración adicionales para poder conectarse.

Los agentes de escucha tienen las siguientes características:

Para obtener una lista de todas las opciones disponibles, consulte la Referencia de API de agente de escucha.

BrokerListener predeterminado

Al implementar Operaciones de IoT de Azure, la implementación crea un recurso de BrokerListener denominado predeterminado. Este cliente de escucha se usa para la comunicación interna cifrada entre los componentes de Operaciones de IoT. El cliente de escucha predeterminado forma parte del agente predeterminado.

Precaución

Para evitar interrumpir la comunicación interna de Operaciones de IoT, mantenga el agente de escucha predeterminado sin cambios y dedicado para su uso interno. Para la comunicación externa, crear un nuevo agente de escucha. Si necesita usar el servicio ClusterIp, agregue más puertos al agente de escucha predeterminado sin cambiar ninguna de las configuraciones existentes.

Para ver o editar el agente de escucha predeterminado, siga estos pasos.

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

  2. En Componentes, seleccione MQTT Broker.

    Captura de pantalla que muestra el uso de Azure Portal para ver la configuración de MQTT de Operaciones de IoT de Azure.

  3. En la lista cliente de escucha del corredor, seleccione el cliente de escucha predeterminado.

    Captura de pantalla que muestra el uso de Azure Portal para ver o editar el cliente de escucha predeterminado.

  4. Revise la configuración del agente de escucha, pero evite modificar cualquiera de las configuraciones existentes. En su lugar, cree un puerto y configúrelo según sea necesario.

Evitar modificar el agente de escucha de agente predeterminado

Para evitar la interrupción de la comunicación interna de Operaciones de IoT, mantenga el cliente de escucha predeterminado sin cambios y dedicado para su uso interno. Para la comunicación externa, crear un nuevo agente de escucha.

Dado que el cliente de escucha predeterminado usa el tipo de servicio ClusterIp y puede tener solo un agente de escucha por tipo de servicio, agregue más puertos al cliente de escucha predeterminado sin cambiar ninguna de las configuraciones existentes si necesita usar el servicio ClusterIp.

Crear nuevos clientes de escucha del corredor

Para crear un nuevo agente de escucha, especifique la siguiente configuración:

  • Nombre: nombre del agente de escucha. Este nombre también es el nombre del servicio Kubernetes a menos que se invalide.
  • Tipo de servicio: tipo del servicio Kubernetes. Consulte Tipo de servicio.
  • Puertos: lista de puertos en los que se va a escuchar. Vea Puertos.
  • Nombre del servicio (opcional): invalide el nombre del servicio de Kubernetes. Consulte Nombre del servicio.

Ejemplo: Creación de un nuevo agente de escucha con dos puertos

En este ejemplo se muestra cómo crear un nuevo cliente de escucha con el tipo de servicio de LoadBalancer. El recurso BrokerListener define dos puertos que aceptan conexiones MQTT de clientes.

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

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione cliente de escucha de corredor MQTT para LoadBalancer>Crear.

    Escriba la siguiente configuración:

    Configuración Descripción
    Nombre Nombre del recurso BrokerListener.
    Nombre del servicio Nombre del servicio Kubernetes. Déjelo vacío para usar el nombre del cliente de escucha como nombre del servicio.
    Tipo de servicio. LoadBalancer ya seleccionado.

  4. En Puertos, escriba la siguiente configuración para el primer puerto:

    Configuración Descripción
    Port Escriba 1883.
    Autenticación Elige Ninguno.
    Authorization Elige Ninguno.
    Protocolo Elija MQTT.
    TLS No agregue.

  5. Seleccione Agregar entrada de puerto para agregar un segundo puerto y escriba la siguiente configuración:

    Configuración Descripción
    Port Escriba 8883.
    Autenticación Elija valor predeterminado.
    Authorization Elige Ninguno.
    Protocolo Elija MQTT.
    TLS Seleccione Agregar.

  6. En el panel configuración de TLS , escriba los valores siguientes:

    Configuración Descripción
    Modo de TLS Elija Automático.
    Nombre del emisor Escriba azure-iot-operations-aio-certificate-issuer.
    Tipo de emisor Elija ClusterIssuer.

    Deje otra configuración como predeterminada y seleccione Aplicar.

  7. Seleccione Crear cliente de escucha.

    Captura de pantalla que muestra el uso de Azure Portal para crear un corredor MQTT para el cliente de escucha del equilibrador de carga.

Tipo de servicio.

Cada recurso de BrokerListener se asigna a un servicio de Kubernetes . El tipo de servicio determina cómo se expone el agente a la red. Los tipos de servicio admitidos son:

  • ClusterIp: expone el agente en una dirección IP interna del clúster. Los clientes pueden conectarse al agente desde el clúster. Este tipo de servicio predeterminado es para el cliente de escucha predeterminado.
  • NodePort: expone el agente en la dirección IP de cada nodo en un puerto estático. Los clientes pueden conectarse al agente desde fuera del clúster. Este tipo de servicio es útil para el desarrollo y las pruebas.
  • LoadBalancer: expone el agente externamente. Al servicio se le asigna una dirección IP externa que los clientes pueden usar para conectarse al agente. Este tipo de servicio es el más común para las implementaciones de producción.

Solo un agente de escucha por tipo de servicio

Solo se permite un agente de escucha por tipo de servicio. Si necesita más conectividad del mismo tipo de servicio, agregue más puertos al agente de escucha existente de ese tipo de servicio.

Nombre del servicio

El nombre del servicio es el nombre del servicio de Kubernetes asociado al agente. Si no se especifica, el nombre del agente de escucha se usa como nombre del servicio. El nombre del servicio debe ser único dentro del espacio de nombres.

Sugerencia

Para evitar la sobrecarga de administración, se recomienda dejar el nombre del servicio vacío. El nombre del agente de escucha es único y puede usarlo para identificar el servicio. Use el nombre del servicio como invalidación solo cuando no pueda asignar un nombre al servicio después del agente de escucha.

Puertos

Cada agente de escucha puede tener varios puertos y cada puerto puede tener su propia configuración para la autenticación, autorización, protocolo y TLS.

Para usar su propia configuración de autenticación o autorización para un puerto, debe crear los recursos correspondientes antes de usarlos con un agente de escucha. Para obtener más información, consulte Configuración de la autenticación de agente MQTT y Configuración de la autorización del corredor MQTT.

Para usar TLS, consulte las secciones Configuración de TLS con administración automática de certificados o Configuración de TLS con administración manual de certificados.

Usar el mismo puerto entre clientes de escucha

No se admite el uso del mismo número de puerto en diferentes agentes de escucha. Cada número de puerto debe ser único dentro del corredor MQTT de Operaciones de IoT.

Por ejemplo, si tiene un agente de escucha mediante el puerto 1883, no puede crear otro agente de escucha con el puerto 1883. Del mismo modo, el agente de escucha predeterminado usa el puerto 18883, por lo que no puede crear otro agente de escucha con el puerto 18883.

Compatibilidad con WebSockets

El corredor MQTT de Operaciones de IoT admite MQTT a través de WebSockets. Para habilitar WebSockets, establezca el protocolo en WebSockets para el puerto.

Configuración de TLS con administración automática de certificados

Para habilitar TLS con administración automática de certificados, especifique la configuración de TLS en un puerto de escucha.

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 manera predeterminada, cert-manager ya está instalado junto con Operaciones de IoT en el espacio de nombres cert-manager. Compruebe la instalación antes de continuar.

  1. Use kubectl para comprobar los pods que coinciden con las etiquetas de la aplicación cert-manager.

    kubectl get pods --namespace cert-manager -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

  2. 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 instalación. Recuerde usar el espacio de nombres cert-manager.

Creación de un emisor para el certificado de servidor de TLS

El recurso del 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 externo de issuer para ampliar la funcionalidad más allá de los emisores admitidos de forma nativa. Puede usar un corredor MQTT con cualquier tipo de emisor de cert-manager.

Importante

Durante la implementación inicial, Operaciones de IoT se instala con un emisor predeterminado para los certificados de servidor de TLS. Puede usar este emisor para desarrollo y pruebas. Para más información, consulte Entidad de certificación (CA) raíz predeterminada y emisor con Operaciones de loT de Azure. Los pasos siguientes solo son necesarios si desea usar un emisor diferente.

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 tiene un certificado de entidad de certificación existente, cree un secreto de Kubernetes con el certificado de entidad de certificación y los archivos PEM de clave privada de entidad de certificación. Ejecute el siguiente comando para importar el certificado de entidad de certificación como un secreto de Kubernetes y 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 entidad de certificación se conoce como arranque de un emisor CA con un certificado autofirmado.

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

  2. Cree el certificado CA con firma propia con el siguiente comando:

    kubectl apply -f ca.yaml

Cert-manager crea un certificado de entidad de certificación mediante sus valores predeterminados. Puede cambiar las propiedades de este certificado modificando la especificación del certificado. Para obtener una lista de opciones válidas, consulte documentación de cert-manager.

Distribuir el certificado raíz

El ejemplo anterior almacena el certificado CA en un secreto de Kubernetes llamado test-ca. Puede recuperar el certificado en formato PEM del secreto y almacenarlo en el 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 certificados de servidor TLS. Anote el nombre y el tipo del emisor. En el ejemplo, el nombre es my-issuer y el tipo es Issuer. Estos valores se establecen en el recurso BrokerListener más adelante.

Habilitar la administración automática de certificados TLS para un puerto

El ejemplo siguiente es un recurso de BrokerListener que habilita TLS en el puerto 8884 con administración automática de certificados.

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

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione o cree un cliente de escucha. Solo puede crear un agente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente.

  4. Puede agregar la configuración de TLS al cliente de escucha seleccionando TLS en un puerto existente o agregando un puerto nuevo.

    Captura de pantalla que muestra el uso de Azure Portal para crear un corredor MQTT para un cliente de escucha del equilibrador de carga con certificados de TLS automáticos.

    Escriba la siguiente configuración:

    Configuración Descripción
    Nombre Nombre del recurso BrokerListener. Escriba aio-broker-loadbalancer-tls.
    Port Número de puerto en el que BrokerListener escucha las conexiones MQTT. Escriba 8884.
    Autenticación La referencia de recursos de autenticación.
    Authorization La referencia del recurso de autorización.
    TLS Selecciona el botón Agregar.
    Nombre del emisor Nombre del emisor del administrador de certificados. Necesario.
    Tipo de emisor Tipo de emisor de cert-manager. Necesario.
    Grupo de emisores Grupo del emisor de cert-manager. Necesario.
    Algoritmo de clave privada Algoritmo para la clave privada.
    Directiva de rotación de claves privadas Directiva para rotar la clave privada.
    Nombres DNS Nombres alternativos del firmante DNS para el certificado.
    Direcciones IP Direcciones IP de los nombres alternativos del firmante para el certificado.
    Nombre secreto Secreto de Kubernetes que contiene un certificado de cliente X.509.
    Duration Duración total del certificado de servidor de TLS tiene como valor predeterminado 90 días.
    Renovar antes Cuándo empezar a renovar el certificado.

  5. Seleccione Aplicar para guardar la configuración de TLS.

Una vez configurado el recurso de BrokerListener, el corredor MQTT crea automáticamente un nuevo servicio con el puerto especificado y TLS habilitada.

Opcional: Configurar parámetros de certificado de servidor

Los únicos parámetros necesarios son nombre de Issuer y tipo de Issuer. Todas las demás propiedades de los certificados de servidor TLS generados se eligen automáticamente. Sin embargo, el corredor MQTT permite personalizar determinadas propiedades siguiendo la misma sintaxis que los certificados de cert-manager. Por ejemplo, puede especificar el algoritmo de clave privada y la directiva de rotación. Estas opciones se encuentran en tls.certManagerCertificateSpec o en el panel Configuración de TLS en Azure Portal.

Para obtener una lista completa de estas opciones de configuración, consulte referencia de la API de agente de escucha de Broker CertManagerCertificateSpec.

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 aio-broker-loadbalancer-tls 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
aio-broker-loadbalancer-tls    LoadBalancer   10.X.X.X        172.X.X.X     8884:32457/TCP   33s

Conexión al agente con TLS

Una vez configurado el certificado de servidor, TLS está habilitada. 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 específico. 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 en el ejemplo) o el servicio CLUSTER-IP.
  • Si se conecta desde fuera del clúster, use 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, Operaciones de IoT se implementa con un certificado de entidad de certificación de "inicio rápido" predeterminado y un emisor para certificados de servidor de 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.

Configuración de TLS con administración manual de certificados

Para configurar manualmente un corredor MQTT para que use un certificado de TLS específico, especifíquelo en un recurso BrokerListener con una referencia a un secreto de Kubernetes e impleméntelo mediante kubectl. En este artículo se muestra un ejemplo que configura TLS con certificados autofirmados para las pruebas.

Creación de una entidad de certificación con la CLI de Step

Step es un administrador de certificados que puede ayudarle a ponerse en marcha rápidamente cuando vaya a crear y administrar su propia entidad de certificación privada.

  1. Instale la CLI de Step y cree una clave y un certificado de entidad de certificación raíz.

    step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key

  2. Cree un certificado y una clave de entidad de certificación intermedia firmados por la entidad de certificación raíz.

    step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

Crear un certificado de servidor

Use la CLI de Step para crear un certificado de servidor a partir del certificado y la clave de entidad de certificación intermedia.

step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure

Aquí, mqtts-endpoint y localhost son los nombres alternativos del firmante (SAN) para el front-end del corredor MQTT en Kubernetes y los clientes locales, respectivamente. Para conectarse a través de Internet, agregue un elemento --san con una dirección IP externa. Las marcas --no-password --insecure se usan para la realización de pruebas a fin de omitir las solicitudes de contraseña y deshabilitar la protección de contraseñas para la clave privada debido a que se almacena en un secreto de Kubernetes. En producción, use una contraseña y almacene la clave privada en una ubicación segura, como Azure Key Vault.

Requisitos del algoritmo de clave de certificado

Se admiten claves EC y RSA, pero todos los certificados de la cadena deben usar el mismo algoritmo de clave. Si importa sus propios certificados de CA, asegúrese de que el certificado de servidor use el mismo algoritmo de clave que las entidades de certificación.

Importación de cadena del certificado raíz como secreto de Kubernetes

  1. Cree una cadena de certificados de servidor completa, donde el orden de los certificados es importante. El certificado de servidor es el primero del archivo y el intermedio es el segundo.

    cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt

  2. Cree un secreto de Kubernetes con la cadena de certificados de servidor y la clave de servidor mediante kubectl.

    kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key

Habilitar la administración manual de certificados TLS para un puerto

En el ejemplo siguiente se muestra un recurso de BrokerListener que habilita TLS en el puerto 8884 con administración manual de certificados.

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

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione o cree un cliente de escucha. Solo puede crear un agente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente. Para seguir el ejemplo, especifique el nombre del servicio de escucha como mqtts-endpoint.

  4. Puede agregar la configuración de TLS al cliente de escucha seleccionando TLS en un puerto existente o agregando un puerto nuevo.

    Captura de pantalla que muestra el uso de Azure Portal para crear un corredor MQTT para el cliente de escucha del equilibrador de carga con certificados de TLS manuales.

    Escriba la siguiente configuración:

    Configuración Descripción
    Port Número de puerto en el que BrokerListener escucha las conexiones MQTT. Necesario.
    Autenticación La referencia de recursos de autenticación.
    Authorization La referencia del recurso de autorización.
    TLS Selecciona el botón Agregar.
    Nombre secreto Secreto de Kubernetes que contiene un certificado de cliente X.509.

  5. Seleccione Aplicar para guardar la configuración de TLS.

Conexión al agente con TLS

Para probar la conexión de TLS con el cliente de Mosquitto, publique un mensaje y pase el certificado de entidad de certificación en el parámetro --cafile.

mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt

Recuerde especificar elementos como el nombre de usuario y la contraseña si está habilitada la autenticación del corredor MQTT.

Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT

Sugerencia

Para usar localhost, el puerto debe estar disponible en la máquina host. Un ejemplo es kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Con algunas distribuciones de Kubernetes como K3d, puede agregar un puerto reenviado con k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Para conectarse al agente, debe distribuir la raíz de confianza, también conocida como agrupación de confianza, a todos los clientes. En este caso, la raíz de confianza es la CA raíz autofirmada creada por la CLI de Step. La distribución de la raíz de confianza es necesaria para que el cliente compruebe la cadena de certificados del servidor. Si los clientes MQTT son cargas de trabajo en el clúster de Kubernetes, también debe crear un ConfigMap con la entidad de certificación raíz y montarlo en el pod.

Uso de una dirección IP externa para el certificado de servidor

Para conectarse con TLS a través de Internet, el certificado de servidor del corredor MQTT debe tener su nombre de host externo o su dirección IP como SAN. En producción, esta información suele ser un nombre DNS o una dirección IP conocida. Durante el desarrollo o la prueba, es posible que no sepa qué nombre de host o dirección IP externa se asigna antes de la implementación. Para solucionar este problema, implemente primero el cliente de escucha sin el certificado de servidor, cree el certificado de servidor y el secreto con la dirección IP externa e importe el secreto al cliente de escucha.

Si intenta implementar el cliente de escucha TLS de ejemplo manual-tls-listener pero el secreto de Kubernetes al que se hace referencia server-cert-secret no existe, se crea el servicio asociado, pero los pods no se inician. El servicio se crea porque el operador necesita reservar la dirección IP externa para el cliente de escucha.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

Este comportamiento se espera mientras importamos el certificado de servidor. El administrador de mantenimiento registra que el corredor MQTT está esperando el certificado de servidor.

kubectl logs -l app=health-manager -n azure-iot-operations

...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.

Nota:

Por lo general, en un sistema distribuido, los registros de los pods no son deterministas y se deben usar con precaución. La forma correcta para mostrar información como esta es a través de eventos de Kubernetes y del estado de los recursos personalizados, que se encuentra en el trabajo pendiente. Considere el paso anterior como solución temporal.

Aunque los pods del front-end no estén en uso, la dirección IP externa ya está disponible.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

A partir de aquí, siga los mismos pasos que se mostraron anteriormente para crear un certificado de servidor con esta dirección IP externa en --san y crear el secreto de Kubernetes de la misma manera. Una vez creado el secreto, este se importa automáticamente en el cliente de escucha.

Contenido relacionado