Configurar a autenticação do Azure IoT MQ Preview

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.

Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.

O Azure IoT MQ Preview dá suporte a 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 .

Recurso BrokerAuthentication padrão

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

kubectl get brokerauthentication authn -n azure-iot-operations -o yaml

A saída mostra o recurso BrokerAuthentication padrão, com metadados removidos para brevidade:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: authn
  namespace: azure-iot-operations
spec:
  listenerRef:
    - listener
  authenticationMethods:
    - sat:
        audiences: ["aio-mq"]

Para alterar a configuração, modifique a authenticationMethods configuração neste recurso BrokerAuthentication ou crie um novo recurso BrokerAuthentication com um nome diferente. Em seguida, implante-o usando kubectl applyo .

Relação entre BrokerListener e BrokerAuthentication

BrokerListener e BrokerAuthentication são recursos separados, mas estão vinculados usando listenerRefo . Aplicam-se as seguintes regras:

• Um BrokerListener pode ser vinculado a apenas um BrokerAuthentication
• Um BrokerAuthentication pode ser vinculado a vários BrokerListeners
• Cada BrokerAuthentication pode suportar vários métodos de autenticação ao mesmo tempo

Fluxo de autenticação

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

Para cada método, o Azure IoT MQ 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 $sat, e a autenticação X.509 requer um certificado de cliente. Se as credenciais do cliente forem relevantes, o Azure IoT MQ 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 Azure IoT MQ trata a falha na comunicação com o servidor de autenticação personalizada como credenciais não relevantes. Esse comportamento permite que o Azure IoT MQ recorra a 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 Azure IoT MQ concede ou nega acesso ao cliente com base no resultado do fluxo de autenticação.

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

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  listenerRef:
    - listener
  authenticationMethods:
    - custom:
        # ...
    - sat:
        # ...
    - usernamePassword:
        # ...

O exemplo anterior especifica a autenticação personalizada, SAT e username-password. Quando um cliente se conecta, o Azure IoT MQ tenta autenticar o cliente usando os métodos especificados na senha de nome de usuário SAT > personalizada > de ordem dada.

1. O Azure IoT MQ 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 Azure IoT MQ retornará aos métodos especificados restantes, com o SAT sendo o próximo.

3. O Azure IoT MQ tenta autenticar as credenciais como credenciais SAT. Se o nome de usuário MQTT começar com $sat, o Azure IoT MQ avaliará a senha MQTT como um SAT. Caso contrário, o broker recorre ao username-password e verifica se o nome de usuário e a senha MQTT fornecidos são válidos.

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.

Desativar autenticação

Para teste, desative a autenticação alterando-a no recurso BrokerListener.

spec:
  authenticationEnabled: false

Configurar método de autenticação

Para saber mais sobre cada uma das opções de autenticação, consulte as seguintes seções:

Nome de utilizador e palavra-passe

Cada cliente tem as seguintes propriedades necessárias:

• Username
• Senha (PBKDF2 codificada)
• Atributos para autorização

Por exemplo, comece com um clients.toml com identidades e senhas codificadas PBKDF2.

# Credential #1
# username: client1
# password: password
[client1]
password = "$pbkdf2-sha512$i=100000,l=64$HqJwOCHweNk1pLryiu3RsA$KVSvxKYcibIG5S5n55RvxKRTdAAfCUtBJoy5IuFzdSZyzkwvUcU+FPawEWFPn+06JyZsndfRTfpiEh+2eSJLkg"

[client1.attributes]
floor = "floor1"
site = "site1"

# Credential #2
# username: client2
# password: password2
[client2]
password = "$pbkdf2-sha512$i=100000,l=64$+H7jXzcEbq2kkyvpxtxePQ$jTzW6fSesiuNRLMIkDDAzBEILk7iyyDZ3rjlEwQap4UJP4TaCR+EXQXNukO7qNJWlPPP8leNnJDCBgX/255Ezw"

[client2.attributes]
floor = "floor2"
site = "site1"

Para codificar a senha usando PBKDF2, use a extensão da CLI de Operações do Azure IoT que inclui o az iot ops mq get-password-hash comando. Ele gera um hash de senha PBKDF2 a partir de uma frase de senha usando o algoritmo SHA-512 e um sal aleatório de 128 bits.

az iot ops mq get-password-hash --phrase TestPassword

A saída mostra o hash de senha PBKDF2 para copiar:

{
  "hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}

Em seguida, salve o arquivo como passwords.toml e importe-o para um segredo do Kubernetes sob essa chave.

kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations

Inclua uma referência ao segredo no recurso personalizado BrokerAuthentication

spec:
  authenticationMethods:
    - usernamePassword:
        secretName: passwords-db

Pode levar alguns minutos para que as alterações entrem em vigor.

Você pode usar o Azure Key Vault para gerenciar segredos para o Azure IoT MQ em vez de segredos do Kubernetes. Para saber mais, consulte Gerenciar segredos usando o Cofre da Chave do Azure ou segredos do Kubernetes.

Certificado de cliente X.509

Pré-requisitos

• Azure IoT MQ configurado com TLS habilitado.
• Step-CLI
• Certificados de cliente e a cadeia de certificados emissora em arquivos PEM. Se você não tiver nenhuma, use a CLI da etapa para gerar algumas.
• Familiaridade com criptografia de chave pública e termos como CA raiz, chave privada e certificados intermediários.

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.

Importar certificado de autoridade de certificação raiz de cliente confiável

Um certificado de autoridade de certificação raiz confiável é necessário para validar o certificado do cliente. Para importar um certificado raiz que possa ser usado para validar certificados de cliente, primeiro importe o certificado PEM como ConfigMap sob a chave client_ca.pem. Os certificados de cliente devem estar enraizados nesta CA para Azure IoT MQ para autenticá-los.

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-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----


BinaryData
====

Importar mapeamento de certificado para atributo

Para usar políticas de autorização para clientes que usam propriedades nos certificados X.509, crie um arquivo TOML de mapeamento de certificado para atributo e importe-o como um segredo do Kubernetes sob a chave x509Attributes.toml. Esse arquivo mapeia o nome do assunto do certificado do cliente para os atributos que podem ser usados nas políticas de autorização. É necessário mesmo que você não use políticas de autorização.

kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations

Para saber mais sobre a sintaxe do arquivo de atributos, consulte Autorizar clientes que usam a autenticação X.509.

Como com a autenticação de nome de usuário e senha, você pode usar o Cofre da Chave do Azure para gerenciar esse segredo em vez de segredos do Kubernetes. Para saber mais, consulte Gerenciar segredos usando o Cofre da Chave do Azure ou segredos do Kubernetes.

Ativar autenticação de cliente X.509

Finalmente, 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 x509 como um dos métodos de autenticação como parte de um recurso BrokerAuthentication vinculado a um ouvinte habilitado para TLS. Por exemplo:

spec:
  authenticationMethods:
    - x509:
        trustedClientCaCert: client-ca
        attributes:
          secretName: x509-attributes

Conectar o cliente mosquitto ao Azure IoT MQ Preview com certificado de cliente X.509

Um cliente como mosquitto precisa de três arquivos para poder se conectar ao Azure IoT MQ 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 Azure IoT MQ sobre 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 Azure IoT MQ 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 Azure IoT MQ 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.

Compreender o fluxo de autenticação de cliente do Azure IoT MQ Preview 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 Azure IoT MQ crie 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 Azure IoT MQ.
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 agente Azure IoT MQ MQTT para se autenticarem.

O Azure IoT MQ usa tokens de conta de serviço acoplados que são detalhados na postagem O que os usuários do GKE precisam saber sobre os novos 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 sat 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 agente do Azure IoT MQ. Você deve especificar pelo menos uma audiência, e todas as SATs devem corresponder a uma das audiências especificadas.

spec:
  authenticationMethods:
    - sat:
        audiences: ["aio-mq", "my-audience"]

Aplique as alterações com kubectl applyo . Pode levar alguns minutos para que as alterações entrem em vigor.

Testar autenticação SAT

A autenticação SAT deve ser usada de um cliente no mesmo cluster do Azure IoT MQ. 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 tenha sido criado, inicie um shell no pod:

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

O token é montado no caminho especificado na configuração /var/run/secrets/tokens no exemplo anterior. Recupere o token e use-o para autenticar.

token=$(cat /var/run/secrets/tokens/mqtt-client-token)

mosquitto_pub -h aio-mq-dmqtt-frontend -V mqttv5 -t hello -m world -u '$sat' -P "$token"

O nome de usuário MQTT deve ser definido como $sat. A senha MQTT deve ser definida para o próprio SAT.

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 Azure IoT MQ e a autenticação personalizada é habilitada, o Azure IoT MQ delega a verificação de credenciais de 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 Azure IoT MQ.

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 Azure IoT MQ 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 Azure IoT MQ envia solicitações contendo credenciais de cliente confidenciais para o servidor de autenticação personalizado. Para proteger essas credenciais, a comunicação entre o Azure IoT MQ e o servidor de autenticação personalizada deve ser criptografada com TLS.

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

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:
    - custom:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Trusted CA certificate for validating custom authentication server certificate.
        # Required unless the server certificate is publicly-rooted.
        caCert: custom-auth-ca
        # Authentication between Azure IoT MQ with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretName: 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

Conteúdos relacionados

• Sobre o recurso BrokerListener
• Configurar autorização para um BrokerListener
• Configurar TLS com gerenciamento manual de certificados
• Configurar TLS com gerenciamento automático de certificados