Configurar a autorização do agente do MQTT

Importante

Esta página inclui instruções para gerenciar componentes do serviço Operações do Azure IoT usando manifestos de implantação do Kubernetes, que estão em versão prévia. Esse recurso é fornecido com várias limitações, e não deve ser usado para cargas de trabalho de produção.

Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

As políticas de autorização determinam quais ações os clientes podem executar no agente, como conectar, publicar ou assinar tópicos. Configure o agente MQTT para usar uma ou várias políticas de autorização com o recurso BrokerAuthorization. Cada recurso BrokerAuthorization contém uma lista de regras que especificam as entidades de segurança e os recursos para as políticas de autorização.

Vincular BrokerAuthorization a BrokerListener

Para vincular um recurso BrokerListener a um recurso BrokerAuthorization, especifique o campo authorizationRef na configuração ports do recurso BrokerListener. Semelhante a BrokerAuthentication, o recurso BrokerAuthorization pode ser vinculado a várias portas BrokerListener. As políticas de autorização se aplicam a todas as portas de ouvinte vinculadas. Há uma diferença importante em comparação com BrokerAuthentication:

Importante

Para que a configuração BrokerAuthorization se aplique a uma porta de ouvinte, pelo menos um recurso BrokerAuthentication também deve estar vinculado a essa porta de ouvinte.

Para saber mais sobre BrokerListener, consulte o recurso BrokerListener.

Regras de autorização

Para configurar a autorização, crie um recurso BrokerAuthorization no cluster do Kubernetes. As seções a seguir fornecem exemplos de como configurar a autorização para clientes que usam nomes de usuário, atributos, certificados X.509 e SATs (tokens de conta de serviço do Kubernetes). Para uma lista das configurações disponíveis, confira a Referência de API de Autorização do Broker.

O exemplo a seguir mostra como criar um recurso BrokerAuthorization usando nomes de usuário e atributos.

Portal

1. No portal do Azure, navegue até a instância de Operações de IoT.

2. Em Componentes, selecione Agente MQTT.

3. Selecione a guia Autorização.

4. Escolha uma política de autenticação existente ou crie uma nova selecionando Criar política de autorização.

   

Azure CLI

Use o comando az iot ops broker authz apply para criar ou alterar uma política de autorização.

az iot ops broker authz apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Neste exemplo, suponha um arquivo de configuração nomeado my-authz-policy.json com o seguinte conteúdo armazenado no diretório base do usuário:

{
  "authorizationPolicies": {
    "cache": "Enabled",
    "rules": [
      {
        "brokerResources": [
          {
            "clientIds": [],
            "method": "Connect",
            "topics": []
          },
          {
            "clientIds": [],
            "method": "Publish",
            "topics": [
              "odd-numbered-orders"
            ]
          },
          {
            "clientIds": [],
            "method": "Subscribe",
            "topics": [
              "orders"
            ]
          }
        ],
        "principals": {
          "attributes": [
            {
              "group": "authz-sat"
            }
          ],
          "clientIds": [],
          "usernames": []
        }
      }
    ]
  }
}

Um comando de exemplo para criar uma nova política de autorização nomeada my-authz-policy é:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/my-authz-policy.json

Bíceps

Para editar uma política de autorização, crie um arquivo .bicep com o conteúdo a seguir. Atualize as configurações conforme necessário e substitua os valores de espaço reservado, como <AIO_INSTANCE_NAME> por seus próprios.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            clientIds: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/sensor/{principal.clientId}'
                '/sensor/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
        }
      ]
    }
  }
}

Implantar o arquivo Bicep usando a CLI do Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (versão prévia)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          clientIds:
            - "temperature-sensor"
            - "humidity-sensor"
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/sensor/{principal.clientId}"
              - "/sensor/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Para criar esse recurso BrokerAuthorization, aplique o manifesto YAML ao cluster do Kubernetes.

Essa autorização do agente permite que clientes com as IDs do cliente temperature-sensor ou humidity-sensor, ou clientes com os atributos organization, com os valores contoso e city, e com o valor seattle, para:

• Conectar-se ao agente.
• Publicar mensagens em tópicos com escopo de ID de cliente e organização. Por exemplo:
  • temperature-sensor pode publicar em /sensor/temperature-sensor e /sensor/contoso.
  • humidity-sensor pode publicar em /sensor/humidity-sensor e /sensor/contoso.
  • some-other-username pode publicar em /sensor/contoso.
• Assine os tópicos /commands/ com escopo com sua organização. Por exemplo:
  • temperature-sensor pode assinar /commands/contoso.
  • some-other-username pode assinar /commands/contoso.

Usar um nome de usuário para autorização

Para usar o nome de usuário do MQTT para autorização, especifique-o como uma matriz em principals.usernames. Dependendo do método de autenticação, o nome de usuário pode não ser verificado:

• Kubernetes SAT: o nome de usuário não deve ser usado para autorização porque não é verificado para MQTTv5 com autenticação aprimorada.
• X.509: o nome de usuário corresponde ao CN (nome comum) de um certificado e pode ser usado para regras de autorização.
• Personalizado: o nome de usuário só deve ser usado para regras de autorização se a autenticação personalizada validar o nome de usuário.

Para evitar problemas de segurança, use o nome de usuário do MQTT para autorização do agente somente quando ele puder ser verificado.

Limitar ainda mais o acesso com base na ID do cliente

Como o campo principals é um OR lógico, você pode restringir ainda mais o acesso com base nas IDs do cliente adicionando o campo clientIds ao campo brokerResources. Por exemplo, para permitir que clientes com IDs de cliente que começam com o número do seu prédio se conectem e publiquem em tópicos referentes ao seu prédio, use a seguinte configuração:

Portal

Nas regras de autorização do agente para a sua política de autorização, use a seguinte configuração:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/sensor"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "building22"
        },
        {
          "building": "building23"
        }
      ]
    }
  }
]

Azure CLI

Use o comando az iot ops broker authz apply para criar ou alterar uma política de autorização.

az iot ops broker authz apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Nas regras de autorização do agente para sua política de autorização, crie um arquivo de configuração nomeado client-id-policy.json com a seguinte configuração armazenada no diretório base do usuário:

{
  "authorizationPolicies": {
    "cache": "Enabled",
    "rules": [
      {
        "brokerResources": [
          {
            "clientIds": [
              "{principal.attributes.building}*"
            ],
            "method": "Connect",
            "topics": []
          },
          {
            "clientIds": [],
            "method": "Publish",
            "topics": [
              "sensors/{principal.attributes.building}/{principal.clientId}/sensor"
            ]
          }
        ],
        "principals": {
          "attributes": [
            {
              "building": "building22"
            },
            {
              "building": "building23"
            }
          ]
        }
      }
    ]
  }
}

Um comando de exemplo para criar uma nova política de autorização nomeada client-id-authz-policy é:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/client-id-authz-policy.json

Bíceps

Para editar uma política de autorização, crie um arquivo .bicep com o conteúdo a seguir. Atualize as configurações conforme necessário e substitua os valores de espaço reservado, como <AIO_INSTANCE_NAME> por seus próprios.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            attributes: [
              {
                building: 'building22'
              }
              {
                building: 'building23'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
              clientIds: [
                '{principal.attributes.building}*' // client IDs must start with building22
              ]
            }
            {
              method: 'Publish'
              topics: [
                'sensors/{principal.attributes.building}/{principal.clientId}/sensor'
              ]
            }
          ]
        }
      ]
    }
  }
}

Implantar o arquivo Bicep usando a CLI do Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (versão prévia)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
    - principals:
        attributes:
          - building: "building22"
          - building: "building23"
      brokerResources:
      - method: Connect
        clientIds:
          - "{principal.attributes.building}*" # client IDs must start with building22
      - method: Publish
        topics:
          - "sensors/{principal.attributes.building}/{principal.clientId}/sensor"

Aqui, se o clientIds não fosse definido no método Connect, um cliente com qualquer ID de cliente poderia se conectar, desde que tivesse o atributo building definido como building22 ou building23. Quando você adiciona o campo clientIds, somente clientes com IDs de cliente que começam com building22 ou building23 podem se conectar. Essa designação garante que o cliente tenha o atributo correto e que a ID do cliente corresponda ao padrão esperado.

Autorizar clientes que usam a autenticação X.509

Você pode autorizar clientes que usam certificados X.509 para autenticação para acessar recursos com base em propriedades X.509 presentes em seu certificado ou seus certificados emissores na cadeia.

Usar atributos

Para criar regras com base em propriedades do certificado de um cliente, sua AC raiz ou AC intermediária, defina os atributos X.509 no recurso BrokerAuthorization. Para obter mais informações, consulte Atributos de certificado.

Com o nome comum da entidade de certificado do cliente como nome de usuário

Para criar políticas de autorização com base apenas no CN do titular do certificado do cliente, crie regras com base na CN.

Por exemplo, se um cliente tiver um certificado com o assunto CN = smart-lock, seu nome de usuário será smart-lock. A partir daí, crie políticas de autorização normalmente.

Autorizar clientes que usam tokens de conta de serviço do Kubernetes

Os atributos de autorização para SATs são definidos como parte das anotações da conta de serviço. Por exemplo, para adicionar um atributo de autorização nomeado group com o valor authz-sat, execute o comando:

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

As anotações de atributo devem começar com aio-broker-auth/ para distingui-las de outras anotações.

Como o aplicativo tem um atributo de autorização chamado authz-sat, não é necessário fornecer um valor clientId ou username. O recurso BrokerAuthorization correspondente usa esse atributo como entidade de segurança, por exemplo:

Portal

Nas regras de autorização do agente para a sua política de autorização, use a seguinte configuração:

[
  {
    "brokerResources": [
      {
        "clientIds": [],
        "method": "Connect",
        "topics": []
      },
      {
        "clientIds": [],
        "method": "Publish",
        "topics": [
          "odd-numbered-orders"
        ]
      },
      {
        "clientIds": [],
        "method": "Subscribe",
        "topics": [
          "orders"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "group": "authz-sat"
        }
      ]
    }
  }
]

Azure CLI

Use o comando az iot ops broker authz apply para criar ou alterar uma política de autorização.

az iot ops broker authz apply --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker <BrokerName> --name <AuthenticationResourceName> --config-file <ConfigFilePathAndName>

Neste exemplo, suponha um arquivo de configuração nomeado my-authz-policy.json com o seguinte conteúdo armazenado no diretório base do usuário:

{
  "authorizationPolicies": {
    "cache": "Enabled",
    "rules": [
      {
        "brokerResources": [
          {
            "clientIds": [],
            "method": "Connect",
            "topics": []
          },
          {
            "clientIds": [],
            "method": "Publish",
            "topics": [
              "odd-numbered-orders"
            ]
          },
          {
            "clientIds": [],
            "method": "Subscribe",
            "topics": [
              "orders"
            ]
          }
        ],
        "principals": {
          "attributes": [
            {
              "group": "authz-sat"
            }
          ],
          "clientIds": [],
          "usernames": []
        }
      }
    ]
  }
}

Um comando de exemplo para criar uma nova política de autorização nomeada my-authz-policy é:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/my-authz-policy.json

Bíceps

Para editar uma política de autorização, crie um arquivo .bicep com o conteúdo a seguir. Atualize as configurações conforme necessário e substitua os valores de espaço reservado, como <AIO_INSTANCE_NAME> por seus próprios.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      rules: [
        {
          principals: {
            attributes: [
              {
                group: 'authz-sat'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                'odd-numbered-orders'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                'orders'
              ]
            }
          ]
        }
      ]
    }
  }
}

Implantar o arquivo Bicep usando a CLI do Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes (versão prévia)

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  authorizationPolicies:
    cache: Enabled
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Para saber mais com um exemplo, consulte Configurar a Política de Autorização com o Cliente Dapr.

Armazenamento de estado

O agente MQTT fornece um repositório de estado que os clientes podem usar para armazenar o estado. Você também pode configurar o repositório de estado para estar altamente disponível.

Para configurar a autorização para clientes que usam o repositório de estado, forneça as seguintes permissões:

• Permissão para publicar no armazenamento de valores-chave do sistema do tópico $services/statestore/_any_/command/invoke/request
• Permissão para assinar o tópico de resposta (definido durante a publicação inicial como um parâmetro) <response_topic>/#

Chaves do repositório de estado

O repositório de estado é acessado pelo agente MQTT no tópico statestore/v1/FA9AE35F-2F64-47CD-9BFF-08E2B32A0FE8/command/invoke. Como os clientes têm acesso ao tópico, você pode especificar chaves e níveis de acesso na seção stateStoreResources da configuração brokerResources do agente MQTT.

O formato de seção stateStoreResources consiste em nível de acesso, um indicador de padrão e o padrão.

Portal

Inclua a seção stateStoreResources nas regras da política de autorização.

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

Azure CLI

Inclua a seção stateStoreResources nas regras da política de autorização.

"stateStoreResources": [
  {
    "method": "", // Values: read, write, readwrite 
    "keyType": "", //Values: string, pattern, binary. Default is pattern
    "keys": [
      // List of patterns to match
    ]
  },
]

Bíceps

No Bicep, inclua a seção stateStoreResources em sua política de autorização.

stateStoreResources: [
  {
    method: '' // Values: read, write, readwrite 
    keyType: '' //Values: string, pattern, binary. Default is pattern
    keys: [
      // List of patterns to match
    ]
  }
  {
    method: 'ReadWrite'
    keyType: 'Binary'
    keys: [
      'xxxxxxxxxxxxxxxxxxxx'
    ]
  }
]

Kubernetes

Em sua definição de recurso personalizada, inclua a seção stateStoreResources em sua política de autorização.

stateStoreResources:
  - method:  # Values: read, write, readwrite 
    keyType: # Values: string, pattern, binary. Default is pattern
    keys:
      - # List of patterns to match

O campo method especifica o nível de acesso:

• O acesso de leitura é especificado com read. O acesso de gravação é especificado com write. O acesso de leitura e gravação é especificado com readwrite.
• O nível de acesso é necessário.
• O nível de acesso de leitura implica as ações de get e keynotify.
• O nível de acesso de gravação implica as ações de set, del e vdel.

O campo keyType especifica o tipo de correspondência de chave:

• pattern: usado para correspondência de padrões no estilo glob.
• string: usado para fazer a correspondência exata, por exemplo, quando uma chave contém caracteres que podem ser correspondidos como um padrão (*, ?, [0-9]).
• binary: usado para corresponder a uma chave binária.

O campo keys especifica as chaves a serem correspondidas. Você pode especificar as chaves como padrões de estilo glob, substituições de token ou cadeias de caracteres exatas.

• Exemplos de estilo glob:

  • colors/*: todas as chaves sob o prefixo "colors/"
  • number[0-9]: qualquer chave de "number0" a "number9"
  • char?: qualquer chave com o prefixo "char" e um sufixo de dígito único, como "charA"
  • *: acesso total a todas as chaves

• As chaves do repositório de estado também dão suporte à substituição de token quando o tipo de chave é pattern e as chaves são reservadas para esta finalidade. Exemplos de substituição de token:

  • clients/{principal.clientId}/*
  • usernames/{principal.username}/*
  • rooms/{principal.attributes.room}/*

Aqui está um exemplo de como você pode criar seus recursos do repositório de estado.

Portal

Nas regras de autorização do agente para sua política de autorização, adicione uma configuração semelhante:

[
  {
    "brokerResources": [
      {
        "clientIds": [
          "{principal.attributes.building}*"
        ],
        "method": "Connect"
      },
      {
        "method": "Publish",
        "topics": [
          "sensors/{principal.attributes.building}/{principal.clientId}/sensor/*"
        ]
      },
      {
        "method": "Subscribe",
        "topics": [
          "commands/{principal.attributes.organization}"
        ]
      }
    ],
    "principals": {
      "attributes": [
        {
          "building": "17",
          "organization": "contoso"
        }
      ],
      "usernames": [
        "temperature-sensor",
        "humidity-sensor"
      ]
    },
    "stateStoreResources": [
      {
        "method": "Read",
        "keyType": "Pattern",
        "keys": [
          "myreadkey",
          "myotherkey?",
          "mynumerickeysuffix[0-9]",
          "clients/{principal.clientId}/*"
        ]
      },
      {
        "method": "ReadWrite",
        "keyType": "Binary",
        "keys": [
          "xxxxxxxxxxxxxxxxxxxx"
        ]
      }
    ]
  }
]

Azure CLI

Neste exemplo, suponha um arquivo de configuração nomeado state-store-authz-policy.json no diretório base do usuário. Nas regras de autorização do agente para sua política de autorização, adicione uma configuração semelhante:

{
  "authorizationPolicies": {
    "cache": "Enabled",
    "rules": [
      {
        "brokerResources": [
          {
            "clientIds": [
              "{principal.attributes.building}*"
            ],
            "method": "Connect"
          },
          {
            "method": "Publish",
            "topics": [
              "sensors/{principal.attributes.building}/{principal.clientId}/sensor/*"
            ]
          },
          {
            "method": "Subscribe",
            "topics": [
              "commands/{principal.attributes.organization}"
            ]
          }
        ],
        "principals": {
          "attributes": [
            {
              "building": "17",
              "organization": "contoso"
            }
          ],
          "usernames": [
            "temperature-sensor",
            "humidity-sensor"
          ]
        },
        "stateStoreResources": [
          {
            "method": "Read",
            "keyType": "Pattern",
            "keys": [
              "myreadkey",
              "myotherkey?",
              "mynumerickeysuffix[0-9]",
              "clients/{principal.clientId}/*"
            ]
          },
          {
            "method": "ReadWrite",
            "keyType": "Binary",
            "keys": [
              "xxxxxxxxxxxxxxxxxxxx"
            ]
          }
        ]
      }
    ]
  }
}

Um comando de exemplo para criar uma nova política de autorização nomeada state-store-authz-policy é:

az iot ops broker authn apply --resource-group myResourceGroupName --instance myAioInstanceName --broker default --name my-authz-policy --config-file ~/state-store-authz-policy.json

Bíceps

Para editar uma política de autorização, crie um arquivo .bicep com o conteúdo a seguir. Atualize as configurações conforme necessário e substitua os valores de espaço reservado, como <AIO_INSTANCE_NAME> por seus próprios.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource brokerAuthorization 'Microsoft.IoTOperations/instances/brokers/authorizations@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authorizationPolicies: {
      cache: 'Enabled'
      rules: [
        {
          principals: {
            usernames: [
              'temperature-sensor'
              'humidity-sensor'
            ]
            attributes: [
              {
                city: 'seattle'
                organization: 'contoso'
              }
            ]
          }
          brokerResources: [
            {
              method: 'Connect'
            }
            {
              method: 'Publish'
              topics: [
                '/sensor/{principal.username}'
                '/sensor/{principal.attributes.organization}'
              ]
            }
            {
              method: 'Subscribe'
              topics: [
                '/commands/{principal.attributes.organization}'
              ]
            }
          ]
          stateStoreResources: [
            {
              method: 'Read'
              keyType: 'Pattern'
              keys: [
                'myreadkey'
                'myotherkey?'
                'mynumerickeysuffix[0-9]'
                'clients/{principal.clientId}/*'
              ]
            }
            {
              method: 'ReadWrite'
              keyType: 'Binary'
              keys: [
                'xxxxxxxxxxxxxxxxxxxx'
              ]
            }
          ]
        }
      ]
    }
  }
}

Implantar o arquivo Bicep usando a CLI do Azure:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Kubernetes

stateStoreResources:
  - method: Read # Read includes Get, Notify
    keyType: "pattern" # string, pattern, binary
    keys:
      - "myreadkey" # explicit read access on key: myreadkey
      - "myotherkey?" # single digit wildcard
      - "mynumerickeysuffix[0-9]" # single digit number range
      - "clients/{principal.clientId}/*" # use token substitution and a wildcard for per-client sandboxing
  - method: ReadWrite  # ReadWrite access includes Get, Notify, Set, Del
    keyType: "binary" # binary keys have exact match, no patterns
    keys:
      - "xxxxxxxxxxxxxxxxxxxx"  # base-64 encoded binary key.

Atualizar autorização

Você pode atualizar os recursos de autorização do agente em runtime sem reiniciar. Todos os clientes conectados no momento da atualização da política são desconectados. Também há suporte para alterar o tipo de política.

kubectl edit brokerauthorization my-authz-policies

Desabilitar autorização

Portal

1. No portal do Azure, navegue até a instância de Operações de IoT.
2. Em Componentes, selecione Agente MQTT.
3. Selecione o ouvinte do corretor que você deseja editar na lista.
4. Na porta em que você deseja desabilitar a autorização, selecione Nenhum na lista suspensa de autorização.

Azure CLI

Use o comando az iot ops broker listener port add para desabilitar a autorização de uma porta. Para desabilitar a autenticação, não inclua o --authz-ref parâmetro.

az iot ops broker listener port add --resource-group <ResourceGroupName> --instance <AioInstanceName> --broker default --listener <ListenerName> --port <ListenerServicePort>

O exemplo a seguir desabilita a autorização para a porta 8884 para o ouvinte chamado aio-broker-loadbalancer:

az iot ops broker listener port add --resource-group myResourceGroupName --instance myAioInstanceName --broker default --listener aio-broker-loadbalancer --authn-ref default --port 8884

Bíceps

Para desabilitar a autorização, omita authorizationRef na configuração ports do recurso BrokerListener.

Kubernetes (versão prévia)

Para desabilitar a autorização, omita authorizationRef na configuração ports do recurso BrokerListener.

Publicação não autorizada no MQTT 3.1.1

Com o MQTT 3.1.1, quando a publicação é negada, o cliente recebe PUBACK sem erros porque a versão do protocolo não dá suporte ao retorno do código de erro. MQTTv5 retorna PUBACK com o código de motivo 135 (não autorizado) quando a publicação é negada.

Conteúdo relacionado

• Recurso BrokerListener
• Configurar a autenticação para um BrokerListener
• Tutorial: autenticação de cliente TLS, X.509 e autorização do controle de ABAC (controle de acesso baseado em atributo)