Partilhar via

Configurar a autenticação do agente MQTT

  • Artigo

Importante

Azure IoT Operations Preview – habilitado pelo Azure Arc está atualmente em visualização. Não deve utilizar este software de pré-visualização em ambientes de produção.

Você precisará implantar uma nova instalação do Azure IoT Operations quando uma versão disponível ao público estiver disponível. Você não poderá atualizar uma instalação de visualização.

Para obter os termos legais que se aplicam aos recursos do Azure que estão em versão beta, em visualização ou ainda não lançados em disponibilidade geral, consulte os Termos de Uso Suplementares para Visualizações do Microsoft Azure.

O broker MQTT suporta vários métodos de autenticação para clientes, e você pode configurar cada ouvinte para ter seu próprio sistema de autenticação com recursos BrokerAuthentication . Para obter uma lista das configurações disponíveis, consulte a referência da API de autenticação do broker.

As regras a seguir se aplicam à relação entre BrokerListener e BrokerAuthentication:

  • Cada BrokerListener pode ter várias portas. Cada porta pode ser vinculada a um recurso BrokerAuthentication .
  • Cada BrokerAuthentication pode suportar vários métodos de autenticação ao mesmo tempo.

Para vincular um BrokerListener a um recurso BrokerAuthentication , especifique o authenticationRef ports campo na configuração do recurso BrokerListener. Para saber mais, consulte Recurso BrokerListener.

Recurso BrokerAuthentication padrão

O Azure IoT Operations Preview implanta um recurso BrokerAuthentication padrão chamado default vinculado ao ouvinte padrão no azure-iot-operations namespace. Ele está configurado para usar apenas Tokens de Conta de Serviço (SATs) do Kubernetes para autenticação.

Importante

O método de autenticação de token de conta de serviço (SAT) no recurso BrokerAuthentication padrão é necessário para que os componentes nas Operações IoT do Azure funcionem corretamente. Evite atualizar ou excluir o recurso BrokerAuthentication padrão.

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

  2. Em Recursos de Operações do Azure IoT, selecione MQTT Broker.

  3. Selecione a guia Autenticação .

  4. Na lista de políticas de autenticação, selecione o nome da política padrão .

    Captura de tela usando o portal do Azure para exibir a política de autenticação do agente MQTT padrão.

Para adicionar novos métodos de autenticação, selecione Adicionar método.

Fluxo de autenticação

A ordem dos métodos de autenticação na matriz determina como o broker MQTT autentica os clientes. O broker MQTT tenta autenticar as credenciais do cliente usando o primeiro método especificado e itera através do array até encontrar uma correspondência ou chegar ao final.

Para cada método, o broker MQTT primeiro verifica se as credenciais do cliente são relevantes para esse método. Por exemplo, a autenticação SAT requer um nome de usuário começando com K8S-SAT, e a autenticação X.509 requer um certificado de cliente. Se as credenciais do cliente forem relevantes, o corretor MQTT verificará se elas são válidas. Para obter mais informações, consulte a seção Configurar método de autenticação.

Para autenticação personalizada, o agente MQTT trata a falha na comunicação com o servidor de autenticação personalizada como credenciais não relevantes. Esse comportamento permite que o broker MQTT volte para outros métodos se o servidor personalizado estiver inacessível.

O fluxo de autenticação termina quando:

  • Uma destas condições é verdadeira:
    • As credenciais do cliente são relevantes e válidas para um dos métodos.
    • As credenciais do cliente não são relevantes para nenhum dos métodos.
    • As credenciais do cliente são relevantes, mas inválidas para qualquer um dos métodos.
  • O broker MQTT concede ou nega acesso ao cliente com base no resultado do fluxo de autenticação.

Com vários métodos de autenticação, o broker MQTT tem um mecanismo de fallback. Por exemplo:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...
    - method: X509
      x509Settings:
        # ...

O exemplo anterior especifica custom e SAT. Quando um cliente se conecta, o broker MQTT tenta autenticar o cliente usando os métodos especificados na ordem dada personalizada e SAT.

  1. O broker MQTT verifica se as credenciais do cliente são válidas para autenticação personalizada. Como a autenticação personalizada depende de um servidor externo para determinar a validade das credenciais, o agente considera todas as credenciais relevantes para a autenticação personalizada e as encaminha para o servidor de autenticação personalizada.
  2. Se o servidor de autenticação personalizado responder com Pass ou Fail resultar, o fluxo de autenticação será encerrado. No entanto, se o servidor de autenticação personalizado não estiver disponível, o broker MQTT retornará aos métodos especificados restantes, com o SAT sendo o próximo.
  3. O broker MQTT tenta autenticar as credenciais como credenciais SAT. Se o nome de usuário MQTT começar com K8S-SAT, o broker MQTT avaliará a senha MQTT como um SAT.

Se o servidor de autenticação personalizada não estiver disponível e todos os métodos subsequentes determinarem que as credenciais fornecidas não são relevantes, o agente negará a conexão do cliente.

Configurar método de autenticação

Você pode adicionar métodos de autenticação como X.509, SAT ou personalizados às políticas de autenticação.

Para adicionar um método de autenticação a uma política:

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

  2. Em Recursos de Operações do Azure IoT, selecione MQTT Broker.

  3. Selecione a guia Autenticação .

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

  5. Adicione um novo método selecionando Adicionar método.

  6. Escolha o tipo de método na lista suspensa e selecione Adicionar detalhes para configurar o método.

    Captura de tela usando o portal do Azure para adicionar um método de política de autenticação do agente MQTT.

Para saber mais sobre cada uma das opções de autenticação, consulte as próximas seções para cada método.

Para obter mais informações sobre como habilitar configurações seguras configurando um Cofre de Chaves do Azure e habilitando identidades de carga de trabalho, consulte Habilitar configurações seguras na implantação do Azure IoT Operations Preview.

X.509

Um certificado de autoridade de certificação raiz confiável é necessário para validar o certificado do cliente. Os certificados de cliente devem estar enraizados nesta CA para que o broker MQTT os autentique. As chaves EC e RSA são suportadas, mas todos os certificados na cadeia devem usar o mesmo algoritmo de chave. Se você estiver importando seus próprios certificados de CA, certifique-se de que o certificado de cliente use o mesmo algoritmo de chave que as CAs. Para importar um certificado raiz que possa ser usado para validar certificados de cliente, importe o certificado PEM como ConfigMap sob a chave client_ca.pem. Por exemplo:

kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations

Para verificar se o certificado da autoridade de certificação raiz foi importado corretamente, execute kubectl describe configmap. O resultado mostra a mesma codificação base64 do arquivo de certificado PEM.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
<Certificate>
-----END CERTIFICATE-----


BinaryData
====

Depois que o certificado de CA raiz do cliente confiável e o mapeamento de certificado para atributo forem importados, habilite a autenticação de cliente X.509 adicionando-a como um dos métodos de autenticação como parte de um recurso BrokerAuthentication vinculado a um ouvinte habilitado para TLS.

Atributos de certificado para autorização

Os atributos X.509 podem ser especificados no recurso BrokerAuthentication e são usados para autorizar clientes com base em suas propriedades de certificado. Os atributos são definidos no authorizationAttributes campo.

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

  2. Em Recursos de Operações do Azure IoT, selecione MQTT Broker.

  3. Selecione a guia Autenticação .

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

  5. Adicione um novo método selecionando Adicionar método.

  6. Escolha o tipo de método X.509 na lista suspensa e selecione Adicionar detalhes para configurar o método.

    Captura de tela usando o portal do Azure para definir o método de autenticação X.509 do agente MQTT.

Neste exemplo, cada cliente que tem um certificado emitido pela autoridade de certificação CN = Contoso Root CA Cert, OU = Engineering, C = US raiz ou uma autoridade de certificação CN = Contoso Intermediate CA intermediária recebe os atributos listados. Além disso, o ventilador inteligente recebe atributos específicos para ele.

A correspondência para atributos sempre começa a partir do certificado de cliente folha e, em seguida, vai ao longo da cadeia. A atribuição de atributo para após a primeira correspondência. No exemplo anterior, mesmo smart-fan que tenha o certificado CN = Contoso Intermediate CAintermediário, ele não obtém os atributos associados.

As regras de autorização podem ser aplicadas a clientes usando certificados X.509 com esses atributos. Para saber mais, consulte Autorizar clientes que usam a autenticação X.509.

Conecte o cliente mosquitto ao corretor MQTT com certificado de cliente X.509

Um cliente como mosquitto precisa de três arquivos para poder se conectar ao corretor MQTT com autenticação de cliente TLS e X.509. Por exemplo:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem

No exemplo:

  • O --cert parâmetro especifica o arquivo PEM do certificado do cliente.
  • O --key parâmetro especifica o arquivo PEM de chave privada do cliente.
  • O terceiro parâmetro --cafile é o mais complexo: o banco de dados de certificados confiáveis, usado para duas finalidades:
    • Quando o cliente mosquitto se conecta ao broker MQTT por TLS, ele valida o certificado do servidor. Ele procura certificados raiz no banco de dados para criar uma cadeia confiável para o certificado do servidor. Por isso, o certificado raiz do servidor precisa ser copiado para esse arquivo.
    • Quando o broker MQTT solicita um certificado de cliente do cliente mosquitto, ele também requer uma cadeia de certificados válida para enviar ao servidor. O --cert parâmetro diz ao mosquitto qual certificado enviar, mas não é suficiente. O broker MQTT não pode verificar esse certificado sozinho porque ele também precisa do certificado intermediário. Mosquitto usa o arquivo de banco de dados para construir a cadeia de certificados necessária. Para suportar isso, o cafile deve conter os certificados intermediários e raiz.

Entenda o fluxo de autenticação do cliente X.509 do broker MQTT

Diagrama do fluxo de autenticação do cliente X.509.

A seguir estão as etapas para o fluxo de autenticação do cliente:

  1. Quando a autenticação de cliente X.509 está ativada, os clientes conectados devem apresentar seu certificado de cliente e quaisquer certificados intermediários para permitir que o corretor MQTT construa uma cadeia de certificados enraizada em um de seus certificados confiáveis configurados.
  2. O balanceador de carga direciona a comunicação para um dos agentes frontend.
  3. Depois que o agente de front-end recebe o certificado do cliente, ele tenta criar uma cadeia de certificados enraizada em um dos certificados configurados. O certificado é necessário para um handshake TLS. Se o agente frontend construiu com êxito uma cadeia e a cadeia apresentada for verificada, ele concluirá o handshake TLS. O cliente de conexão é capaz de enviar pacotes MQTT para o frontend através do canal TLS construído.
  4. O canal TLS está aberto, mas a autenticação ou autorização do cliente ainda não foi concluída.
  5. Em seguida, o cliente envia um pacote CONNECT para o broker MQTT.
  6. O pacote CONNECT é roteado para um frontend novamente.
  7. O frontend coleta todas as credenciais que o cliente apresentou até agora, como campos de nome de usuário e senha, dados de autenticação do pacote CONNECT e a cadeia de certificados do cliente apresentada durante o handshake TLS.
  8. O frontend envia essas credenciais para o serviço de autenticação. O serviço de autenticação verifica a cadeia de certificados mais uma vez e coleta os nomes de assunto de todos os certificados na cadeia.
  9. O serviço de autenticação usa suas regras de autorização configuradas para determinar quais atributos os clientes de conexão têm. Esses atributos determinam quais operações o cliente pode executar, incluindo o próprio pacote CONNECT.
  10. O serviço de autenticação retorna a decisão para o agente frontend.
  11. O agente frontend conhece os atributos do cliente e se ele tem permissão para se conectar. Em caso afirmativo, a conexão MQTT será concluída e o cliente poderá continuar a enviar e receber pacotes MQTT determinados por suas regras de autorização.

Tokens de conta de serviço Kubernetes

Os Tokens de Conta de Serviço (SATs) do Kubernetes são Tokens Web JSON associados às Contas de Serviço do Kubernetes. Os clientes apresentam SATs ao broker MQTT para se autenticarem.

O corretor MQTT usa tokens de conta de serviço vinculados que são detalhados na postagem O que os usuários do GKE precisam saber sobre a nova postagem de tokens de conta de serviço do Kubernetes. Aqui estão as características salientes do post:

Lançados no Kubernetes 1.13 e se tornando o formato padrão na versão 1.21, os tokens vinculados abordam todas as funcionalidades limitadas dos tokens herdados e muito mais:

  • Os tokens em si são mais difíceis de roubar e usar indevidamente; eles têm limite de tempo, de audiência e de objeto.
  • Eles adotam um formato padronizado: OpenID Connect (OIDC), com OIDC Discovery completo, tornando mais fácil para os provedores de serviços aceitá-los.
  • Eles são distribuídos para pods com mais segurança, usando um novo tipo de volume projetado Kubelet.

O broker verifica os tokens usando a API de revisão de token do Kubernetes. Habilite o recurso Kubernetes TokenRequestProjection para especificar audiences (padrão desde 1.21). Se esse recurso não estiver habilitado, os SATs não poderão ser usados.

Criar uma conta de serviço

Para criar SATs, primeiro crie uma conta de serviço. O comando a seguir cria uma conta de serviço chamada mqtt-client.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Adicionar atributos para autorização

A autenticação de clientes via SAT pode, opcionalmente, ter seus SATs anotados com atributos a serem usados com políticas de autorização personalizadas. Para saber mais, consulte Autorizar clientes que usam tokens de conta de serviço do Kubernetes.

Ativar autenticação de Token de Conta de Serviço (SAT)

Modifique a authenticationMethods configuração em um recurso BrokerAuthentication para especificar ServiceAccountToken como um método de autenticação válido. O audiences especifica a lista de audiências válidas para tokens. Escolha valores exclusivos que identifiquem o serviço de broker MQTT. Você deve especificar pelo menos uma audiência, e todas as SATs devem corresponder a uma das audiências especificadas.

  1. No portal do Azure, navegue até sua instância de Operações IoT.
  2. Em Recursos de Operações do Azure IoT, selecione MQTT Broker.
  3. Selecione a guia Autenticação .
  4. Escolha uma política de autenticação existente ou crie uma nova.
  5. Adicione um novo método selecionando Adicionar método.
  6. Escolha o tipo de método Kubernetes SAT na lista suspensa e selecione Adicionar detalhes para configurar o método.

Captura de tela usando o portal do Azure para definir o método de autenticação SAT do agente MQTT.

Testar autenticação SAT

A autenticação SAT deve ser usada a partir de um cliente no mesmo cluster que o broker MQTT. Apenas os campos de autenticação avançada são permitidos. Defina o método de autenticação e K8S-SAT os dados de autenticação para o token.

O comando a seguir especifica um pod que tem o cliente mosquitto e monta o SAT criado nas etapas anteriores no pod.

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
spec:
  serviceAccountName: mqtt-client
  containers:
  - image: efrecon/mqtt-client
    name: mqtt-client
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: mqtt-client-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: mqtt-client-token
    projected:
      sources:
      - serviceAccountToken:
          path: mqtt-client-token
          audience: my-audience
          expirationSeconds: 86400

Aqui, o serviceAccountName campo na configuração do pod deve corresponder à conta de serviço associada ao token que está sendo usado. Além disso, o serviceAccountToken.audience campo na configuração do pod deve ser um dos configurados audiences no recurso BrokerAuthentication .

Uma vez que o pod é criado, inicie um shell no pod:

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

Dentro do shell do pod, execute o seguinte comando para publicar uma mensagem para o broker:

mosquitto_pub --host aio-broker --port 18883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)

O resultado deve ser algo semelhante ao seguinte:

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

O cliente mosquitto usa o token de conta de serviço montado em /var/run/secrets/tokens/broker-sat para autenticar com o broker. O token é válido por 24 horas. O cliente também usa o certificado de CA raiz padrão montado em /var/run/certs/ca.crt para verificar a cadeia de certificados TLS do broker.

Atualizar tokens de conta de serviço

Os tokens de conta de serviço são válidos por tempo limitado e configurados com expirationSeconds. No entanto, o Kubernetes atualiza automaticamente o token antes que ele expire. O token é atualizado em segundo plano e o cliente não precisa fazer nada além de buscá-lo novamente.

Por exemplo, se o cliente for um pod que usa o token montado como um volume, como no exemplo de autenticação SAT de teste, o token mais recente estará disponível no mesmo caminho /var/run/secrets/tokens/mqtt-client-token. Ao fazer uma nova conexão, o cliente pode buscar o token mais recente e usá-lo para autenticar. O cliente também deve ter um mecanismo para lidar com erros não autorizados MQTT, buscando o token mais recente e tentando novamente a conexão.

Autenticação personalizada

Estenda a autenticação do cliente além dos métodos de autenticação fornecidos com autenticação personalizada. É conectável , uma vez que o serviço pode ser qualquer coisa, desde que adera à API.

Quando um cliente se conecta ao agente MQTT e a autenticação personalizada é habilitada, o agente MQTT delega a verificação das credenciais do cliente a um servidor de autenticação personalizado com uma solicitação HTTP junto com todas as credenciais que o cliente apresenta. O servidor de autenticação personalizado responde com aprovação ou negação para o cliente com os atributos do cliente para autorização.

Criar serviço de autenticação personalizado

O servidor de autenticação personalizado é implementado e implantado separadamente do broker MQTT.

Um exemplo de servidor de autenticação personalizado e instruções estão disponíveis no GitHub. Use este exemplo como um modelo e ponto de partida para implementar sua própria lógica de autenticação personalizada.

API

A API entre o agente MQTT e o servidor de autenticação personalizado segue a especificação da API para autenticação personalizada. A especificação OpenAPI está disponível no GitHub.

HTTPS com criptografia TLS é necessário

O broker MQTT envia solicitações contendo credenciais de cliente confidenciais para o servidor de autenticação personalizado. Para proteger essas credenciais, a comunicação entre o agente MQTT e o servidor de autenticação personalizado deve ser criptografada com TLS.

O servidor de autenticação personalizada deve apresentar um certificado de servidor e o agente MQTT deve ter um certificado de CA raiz confiável para validar o certificado do servidor. Opcionalmente, o servidor de autenticação personalizado pode exigir que o agente MQTT apresente um certificado de cliente para autenticar-se.

Habilitar autenticação personalizada para um ouvinte

Modifique a authenticationMethods configuração em um recurso BrokerAuthentication para especificar Custom como um método de autenticação válido. Em seguida, especifique os parâmetros necessários para se comunicar com um servidor de autenticação personalizado.

Este exemplo mostra todos os parâmetros possíveis. Os parâmetros exatos necessários dependem dos requisitos de cada servidor personalizado.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Desativar autenticação

Para testes, você pode desabilitar a autenticação para uma porta de ouvinte do broker. A desativação da autenticação não é recomendada para ambientes de produção.

  1. No portal do Azure, navegue até sua instância de Operações IoT.
  2. Em Recursos de Operações do Azure IoT, selecione MQTT Broker.
  3. Selecione o ouvinte do broker que você deseja editar na lista.
  4. Na porta que você deseja desabilitar a autenticação, selecione Nenhuma na lista suspensa de autenticação.

Desconexão do cliente após a expiração das credenciais

O broker MQTT desconecta os clientes quando suas credenciais expiram. A desconexão após a expiração da credencial aplica-se a todos os clientes que se conectam aos frontends do broker MQTT, incluindo:

  • Os clientes autenticados com SATs se desconectam quando o SAT expira
  • Os clientes autenticados com X.509 se desconectam quando o certificado do cliente expira
  • Os clientes autenticados com autenticação personalizada se desconectam com base no tempo de expiração retornado do servidor de autenticação personalizado.

Ao desconectar, a conexão de rede do cliente é fechada. O cliente não receberá um pacote MQTT DISCONNECT, mas o broker registra uma mensagem informando que desconectou o cliente.

Os clientes MQTT v5 autenticados com SATs e autenticação personalizada podem se reautenticar com uma nova credencial antes que sua credencial inicial expire. Os clientes X.509 não podem autenticar novamente e devem restabelecer a conexão, uma vez que a autenticação é feita na camada TLS.

Os clientes podem se autenticar novamente enviando um pacote MQTT v5 AUTH.

Os clientes SAT enviam um cliente AUTH com os campos method: K8S-SAT, data: <token>. Os clientes de autenticação personalizada definem o método e o campo de dados conforme exigido pelo servidor de autenticação personalizado.

A reautenticação bem-sucedida atualiza a expiração da credencial do cliente com o tempo de expiração de sua nova credencial, e o broker responde com um pacote AUTH de sucesso. Falha na autenticação devido a problemas transitórios fazem com que o broker responda com um pacote AUTH ContinueAuthentication. Por exemplo, o servidor de autenticação personalizado está indisponível. O cliente pode tentar novamente mais tarde. Outras falhas de autenticação fazem com que o broker envie um pacote DISCONNECT e feche a conexão de rede do cliente.

Conteúdos relacionados