Compartir a través de

Configuración de la autorización en versión preliminar de Azure IoT MQ

  • Artículo

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.

Las directivas de autorización determinan qué acciones pueden realizar los clientes en el agente, como conectarse, publicar o suscribirse a temas. Configure Azure IoT MQ Preview para usar una o varias directivas de autorización con el recurso BrokerAuthorization.

Puede establecer una BrokerAuthorization para cada cliente de escucha. Cada recurso BrokerAuthorization contiene una lista de reglas que especifican las entidades de seguridad y los recursos de las directivas de autorización.

Importante

Para que la configuración deBrokerAuthorization se aplique a un cliente de escucha, al menos una BrokerAuthentication debe estar vinculada también a ese agente de escucha.

Configuración de BrokerAuthorization para clientes de escucha

La especificación de un recurso de BrokerAuthorization tiene los siguientes campos:

Nombre del campo Obligatorio Descripción
listenerRef Sí Nombres de los recursos de BrokerListener que aplican esta directiva de autorización. Este campo es obligatorio y debe coincidir con un recurso de BrokerListener existente en el mismo espacio de nombres.
authorizationPolicies Sí Este campo define la configuración de las directivas de autorización, como enableCache y reglas.
enableCache No Si se habilita el almacenamiento en caché para las directivas de autorización. Si se establece en true, el agente almacena en caché los resultados de autorización de cada combinación de cliente y tema para mejorar el rendimiento y reducir la latencia. Si se establece en false, el agente evalúa las directivas de autorización para cada solicitud de cliente y tema, para garantizar la coherencia y la precisión. Este campo es opcional y el valor predeterminado es false.
reglas No Lista de reglas que especifican las entidades de seguridad y los recursos para las directivas de autorización. Cada regla tiene estos subcampos: entidades de seguridad y brokerResources.
principals Sí Este subcampo define las identidades que representan a los clientes, como nombres de usuario, identificadores de cliente y atributos.
Nombres No Lista de nombres de usuario que coinciden con los clientes. Los nombres de usuario distinguen mayúsculas de minúsculas y deben coincidir con los nombres de usuario proporcionados por los clientes durante la autenticación.
Identificadores de cliente No Lista de identificadores de cliente que coinciden con los clientes. Los identificadores de cliente distinguen mayúsculas de minúsculas y deben coincidir con los identificadores de cliente proporcionados por los clientes durante la conexión.
atributos No Lista de pares clave-valor que coinciden con los atributos de los clientes. Los atributos distinguen mayúsculas de minúsculas y deben coincidir con los atributos proporcionados por los clientes durante la autenticación.
brokerResources Sí Este subcampo define los objetos que representan las acciones o temas, como el método y los temas.
method Sí Tipo de acción que los clientes pueden realizar en el agente. Este subcampo es necesario y puede ser uno de estos valores: Connect: este valor indica que los clientes pueden conectarse al agente. Publicar: este valor indica que los clientes pueden publicar mensajes en temas del agente. Suscripción: este valor indica que los clientes pueden suscribirse a temas del agente.
topics No Lista de temas o patrones de tema que coinciden con los temas a los que los clientes pueden publicar o suscribirse. Este subcampo es necesario si el método es Subscribe o Publish.

En el ejemplo siguiente se muestra cómo crear un recurso de BrokerAuthorization que define las directivas de autorización para un agente de escucha denominado my-listener.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "my-listener" # change to match your listener name as needed
  authorizationPolicies:
    enableCache: true
    rules:
      - principals:
          usernames:
            - temperature-sensor
            - humidity-sensor
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.username}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Esta autorización de agente permite a los clientes con nombres de usuario temperature-sensor o humidity-sensor, o clientes con atributos organization con valor contoso y city con valor seattle, para:

  • Conectarse al agente.
  • Publique mensajes en temas de telemetría con su nombre de usuario y organización. Por ejemplo:
    • temperature-sensor puede publicar en /telemetry/temperature-sensor y /telemetry/contoso.
    • humidity-sensor puede publicar en /telemetry/humidity-sensor y /telemetry/contoso.
    • some-other-username puede publicar en /telemetry/contoso.
  • Suscríbase a temas de comandos en el ámbito de su organización. Por ejemplo:
    • temperature-sensor puede suscribirse a /commands/contoso.
    • some-other-username puede suscribirse a /commands/contoso.

Para crear este recurso BrokerAuthorization, aplique el manifiesto YAML al clúster de Kubernetes.

Autorización de clientes que usan la autenticación X.509

Los clientes que usan certificados X.509 para la autenticación se pueden autorizar para acceder a los recursos basados en las propiedades X.509 presentes en su certificado o en sus certificados emisores en la cadena.

Con las propiedades de la cadena de certificados mediante atributos

Para crear reglas basadas en propiedades del certificado de un cliente, su CA raíz o CA intermedia, se requiere un archivo TOML de asignación de certificados a atributos. Por ejemplo:

[root]
subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"

[root.attributes]
organization = "contoso"

[intermediate]
subject = "CN = Contoso Intermediate CA"

[intermediate.attributes]
city = "seattle"
foo = "bar"

[smart-fan]
subject = "CN = smart-fan"

[smart-fan.attributes]
building = "17"

En este ejemplo, cada cliente que tiene un certificado emitido por la CA raíz CN = Contoso Root CA Cert, OU = Engineering, C = US o una CA intermedia CN = Contoso Intermediate CA recibe los atributos enumerados. Además, el ventilador inteligente 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.

Para aplicar la asignación, cree un archivo TOML de asignación de certificado a atributo como un secreto de Kubernetes y haga referencia a él en authenticationMethods.x509.attributes para el recurso BrokerAuthentication.

A continuación, las reglas de autorización se pueden aplicar a los clientes que usan certificados X.509 con estos atributos.

Con el nombre común del firmante del certificado de cliente como nombre de usuario

Para crear directivas de autorización basadas solo en el nombre común del firmante del certificado de cliente (CN), cree reglas basadas en el CN.

Por ejemplo, si un cliente tiene un certificado con asunto CN = smart-lock, su nombre de usuario es smart-lock. Desde allí, cree directivas de autorización como normales.

Autorización de clientes que usan tokens de cuenta de Kubernetes Service

Los atributos de autorización para las SAT se establecen como parte de las anotaciones de la cuenta de servicio. Por ejemplo, para agregar un atributo de autorización denominado group con el valor authz-sat, ejecute el comando:

kubectl annotate serviceaccount mqtt-client aio-mq-broker-auth/group=authz-sat

Las anotaciones de atributo deben comenzar con aio-mq-broker-auth/ para distinguirlas de otras anotaciones.

Dado que la aplicación tiene un atributo de autorización denominado authz-sat, no es necesario proporcionar un clientId ni username. El recurso BrokerAuthorization correspondiente usa este atributo como entidad de seguridad, por ejemplo:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "az-mqtt-non-tls-listener"
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Para obtener más información con un ejemplo, consulte Configurar directiva de autorización con dapr Client.

Almacén de estado distribuido

Azure IoT MQ Broker proporciona un almacén de estado distribuido (DSS) que los clientes pueden usar para almacenar el estado. El DSS también se puede configurar para que sea de alta disponibilidad.

Para configurar la autorización para los clientes que usan DSS, proporcione los permisos siguientes:

  • Permiso para publicar en el tema del almacén de valores de clave del sistema $services/statestore/_any_/command/invoke/request
  • Permiso para suscribirse al tema de respuesta (establecido durante la publicación inicial como parámetro) <response_topic>/#

Actualización de la autorización

Los recursos de autorización del agente se pueden actualizar en tiempo de ejecución sin reiniciar. Todos los clientes conectados en el momento de la actualización de la directiva se desconectan. También se admite el cambio del tipo de directiva.

kubectl edit brokerauthorization my-authz-policies

Deshabilitación de la autorización

Para deshabilitar la autorización, establezca authorizationEnabled: false en el recurso BrokerListener. Cuando la directiva se establece para permitir todos los clientes, todos los clientes autenticados pueden acceder a todas las operaciones.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: "my-listener"
  namespace: azure-iot-operations
spec:
  brokerRef: "my-broker"
  authenticationEnabled: false
  authorizationEnabled: false
  port: 1883

Publicación no autorizada en MQTT 3.1.1

Con MQTT 3.1.1, cuando se deniega una publicación, el cliente recibe el PUBACK sin ningún error porque la versión del protocolo no admite la devolución de código de error. MQTTv5 devuelve PUBACK con el código de motivo 135 (no autorizado) cuando se deniega la publicación.

Contenido relacionado