Compartilhar via

Proteger a comunicação pelo agente MQTT usando o BrokerListener

  • Artigo

Importante

A Versão Prévia das Operações da Internet das Coisas do Azure – habilitadas pelo Azure Arc – está atualmente em versão prévia. Você não deve usar esse software em versão prévia em ambientes de produção.

Você precisará implantar uma nova instalação de Operações do Azure IoT quando uma versão com disponibilidade geral estiver disponível. Você não poderá atualizar uma instalação de versão prévia.

Para os 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, confira os Termos de Uso Complementares para Versões Prévias do Microsoft Azure.

Para personalizar o acesso à rede e à segurança, use o recurso de BrokerListener. Um ouvinte corresponde a um ponto de extremidade de rede que expõe o agente à rede. Você pode ter um ou mais recursos de BrokerListener para cada recurso de Broker e, portanto, várias portas com controle de acesso diferente em cada uma.

Cada ouvinte pode ter regras próprias de autenticação e autorização que definem quem pode se conectar ao ouvinte e quais ações podem ser executadas no agente. Você pode usar os recursos BrokerAuthentication e BrokerAuthorization para especificar as políticas de controle de acesso para cada ouvinte. Essa flexibilidade permite ajustar as permissões e funções de seus clientes MQTT, com base em suas necessidades e casos de uso.

Dica

Você só pode acessar a implantação padrão do agente MQTT usando o IP do cluster, o TLS e um token de conta de serviço. Os clientes se conectando de fora do cluster precisam de configuração extra antes de poderem se conectar.

Os ouvintes têm as seguintes características:

  • Você pode ter até três ouvintes. Um ouvinte por tipo de serviço de loadBalancer, clusterIpou nodePort. O BrokerListener padrão chamadopadrão é o tipo de serviço clusterIp.
  • Cada ouvinte dá suporte a várias portas
  • As referências BrokerAuthentication e BrokerAuthorization são por porta
  • A configuração do TLS é por porta
  • Os nomes de serviço devem ser exclusivos.
  • As portas não podem entrar em conflito com ouvintes diferentes

Para uma lista das configurações disponíveis, confira a Referência de API de Ouvinte do Broker.

BrokerListener padrão

Quando você implanta as Operações do Azure IoT (versão prévia), a implantação também cria um recurso de BrokerListener chamado default no namespace azure-iot-operations. Esse ouvinte está vinculado ao recurso de Agente padrão chamado default que também é criado durante a implantação. O ouvinte padrão expõe o agente na porta 18883 com autenticação por TLS e SAT habilitadas. O certificado TLS é gerenciado automaticamente pelo gerenciador de certificados. A autorização é desabilitada por padrão.

Para exibir ou editar o ouvinte:

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

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

    Captura de tela usando o portal do Azure para exibir a configuração MQTT das Operações do Azure IoT.

  3. Na lista de ouvintes do agente, selecione o ouvinte padrão.

    Captura de tela usando o portal do Azure para exibir ou editar o ouvinte do agente padrão.

  4. Examine as configurações do ouvinte e faça as alterações conforme necessário.

Criar ouvintes do agente

Este exemplo mostra como criar um recurso BrokerListener chamado loadbalancer-listener para um recurso de Agente. O recurso BrokerListener define duas portas que aceitam conexões MQTT de clientes.

  • A primeira porta escuta na porta 1883 sem TLS e autenticação desativada. Os clientes podem se conectar ao agente sem criptografia ou autenticação.
  • A segunda porta escuta na porta 18883 com TLS e autenticação habilitada. Somente clientes autenticados podem se conectar ao agente com criptografia TLS. O TLS é definido como automatic, o que significa que o ouvinte usa o gerenciador de certificados para obter e renovar seu certificado de servidor.

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

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

  3. Selecione Ouvinte do agente MQTT para LoadBalancer>Criar. Você pode criar apenas um ouvinte por tipo de serviço. Se você já tiver um ouvinte do mesmo tipo de serviço, poderá adicionar mais portas ao ouvinte existente.

    Captura de tela usando o portal do Azure para criar um agente MQTT para o ouvinte do balanceador de carga.

    Digite as seguintes configurações:

    Configuração Descrição
    Nome Nome do recurso BrokerListener.
    Nome do serviço O nome do serviço Kubernetes associado ao BrokerListener.
    Tipo de serviço Tipo de serviço de agente, como LoadBalancer, NodePort ou ClusterIP.
    Porta Número da porta no qual o BrokerListener escuta conexões MQTT.
    Autenticação A referência de recurso de autenticação.
    Autorização A referência de recurso da autorização.
    TLS Indica se o TLS está habilitado para comunicação segura. Pode ser definido como automático ou manual.

  4. Selecione Criar ouvinte.

Configurar o TLS com o gerenciamento automático de certificados

Para habilitar o TLS com o gerenciamento automático de certificados, especifique as configurações do TLS em uma porta de ouvinte.

Verificar a instalação do cert-manager

Com o gerenciamento automático de certificados, você usa o cert-manager para gerenciar o certificado do servidor TLS. Por padrão, o cert-manager já é instalado junto com o recurso Operações do Azure IoT Versão Prévia no namespace de azure-iot-operations. Verifique a instalação antes de prosseguir.

  1. Use kubectl para verificar os pods que correspondem aos rótulos de aplicativo do cert-manager.

    kubectl get pods --namespace azure-iot-operations -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. Se você estiver vendo os pods aparecerem como prontos e em execução, isso significa que o cert-manager está instalado e pronto para uso.

Dica

Para verificar ainda mais a instalação, confira a documentação do cert-manager para verificar a instalação. Lembre-se de usar o namespace de azure-iot-operations.

Criar um Emissor para o certificado do servidor TLS

O recurso emissor do cert-manager define como os certificados são emitidos automaticamente. O cert-manager dá suporte nativamente a vários tipos de emissores. Dá suporte também a um tipo de emissor externo para estender a funcionalidade para além dos emissores com suporte nativo. O Agente MQTT pode ser usado com qualquer tipo de emissor do gerente de certificados.

Importante

Durante a implantação inicial, o recurso Operações do Azure IoT é instalado com um Emissor padrão para certificados de servidor TLS. Você pode usar esse emissor para desenvolvimento e testes. Para obter mais informações, confira AC raiz padrão e emissor com o recurso Operações do Azure IoT. As etapas a seguir só serão necessárias se você quiser usar um emissor diferente.

A abordagem para criar o emissor é diferente dependendo da sua conjuntura. As seções a seguir listam exemplos que ajudarão você a começar.

O emissor de AC é útil para desenvolvimento e testes. Precisa ser configurado com um certificado e uma chave privada armazenada em um segredo do Kubernetes.

Configurar o certificado raiz como um segredo do Kubernetes

Se você já tiver um certificado de AC existente, crie um segredo do Kubernetes com o certificado de AC e arquivos PEM da chave privada. Execute o comando a seguir e você terá configurado o certificado raiz como um segredo do Kubernetes e poderá ignorar a próxima seção.

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

Se você não tiver um certificado de autoridade de certificação, o cert-manager poderá gerar um certificado de AC raiz para você. O processo de usar o cert-manager para gerar um certificado de AC raiz é conhecido como bootstrapping (começar do zero) um emissor de AC com um certificado autoassinado.

  1. Comece criando 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. Crie o certificado de AC autoassinado com o seguinte comando:

    kubectl apply -f ca.yaml

O cert-manager cria um certificado de AC usando os respectivos padrões. As propriedades desse certificado podem ser alteradas modificando a especificação do certificado. Confira a documentação do cert-manager para obter uma lista de opções válidas.

Distribuir o certificado raiz

O exemplo anterior armazena o certificado de AC em um segredo do Kubernetes chamado test-ca. O certificado no formato PEM pode ser recuperado a partir do segredo e armazenado em um arquivo ca.crt com o seguinte comando:

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

Esse certificado precisa ser distribuído e ser considerado confiável por todos os clientes. Por exemplo, use o sinalizador --cafile para um cliente do Mosquitto.

Criar um emissor baseado no certificado de AC

O cert-manager precisa de um emissor baseado no certificado de AC gerado ou importado na etapa anterior. Crie o seguinte arquivo 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

Crie o emissor com o seguinte comando:

kubectl apply -f issuer-ca.yaml

O comando anterior cria um emissor para emitir os certificados do servidor TLS. Anote o nome e o tipo do emissor. No exemplo, o nome é my-issuer e o tipo é Issuer. Esses valores serão configurados no recurso BrokerListener mais tarde.

Habilitar o gerenciamento automático de certificado TLS para uma porta

Veja a seguir um exemplo de um recurso BrokerListener que habilita o TLS na porta 8884 com gerenciamento automático de certificados.

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

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

  3. Selecionar ou criar um ouvinte. Você pode criar apenas um ouvinte por tipo de serviço. Se você já tiver um ouvinte do mesmo tipo de serviço, poderá adicionar mais portas ao ouvinte existente.

  4. Você pode adicionar configurações de TLS ao ouvinte selecionando o TLS em uma porta existente ou adicionando uma nova porta.

    Captura de tela usando o portal do Azure para criar um agente MQTT para o ouvinte do balanceador de carga com certificados TLS automáticos.

    Digite as seguintes configurações:

    Configuração Descrição
    Porta Número da porta no qual o BrokerListener escuta conexões MQTT. Obrigatória.
    Autenticação A referência de recurso de autenticação.
    Autorização A referência de recurso da autorização.
    TLS Selecione o botão Adicionar.
    Nome do emissor Nome do emissor do cert-manager. Obrigatória.
    Tipo de emissor Tipo de emissor do cert-manager. Obrigatória.
    Grupo emissor Grupo do emissor do cert-manager. Obrigatória.
    Algoritmo de chave privada Algoritmo para a chave privada.
    Política de rotação de chave privada Política para girar a chave privada.
    Nomes de DNS Nomes alternativos da entidade DNS para o certificado.
    Endereços IP Endereços IP dos nomes alternativos da entidade para o certificado.
    Nome secreto Segredo do Kubernetes que contém um certificado de cliente X.509.
    Duration O tempo de vida total do certificado do servidor TLS é padrão para 90 dias.
    Renovar antes de Quando começar a renovar o certificado.

  5. Clique em Salvar para salvar as configurações de TLS.

Conectar-se ao agente com TLS

Após o certificado do servidor ter sido configurado, o TLS será habilitado. Para testar com o Mosquitto:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

O argumento --cafile habilita o TLS no cliente do Mosquitto e especifica que o cliente deve confiar em todos os certificados de servidor emitidos pelo arquivo fornecido. Você precisa especificar um arquivo que contenha o emissor do certificado do servidor TLS configurado.

Substitua $HOST pelo host apropriado:

  • Se estiver se conectando de dentro do mesmo cluster, substitua pelo nome do serviço fornecido (my-new-tls-listener no exemplo) ou pelo CLUSTER-IP do serviço.
  • Se estiver se conectando de fora do cluster, pelo EXTERNAL-IP do serviço.

Lembre-se de especificar os métodos de autenticação, se necessário.

AC raiz padrão e emissor

Para ajudar você a começar, o recurso Operações do Azure IoT é implantado com uma AC raiz de "início rápido" padrão e um emissor para certificados de servidor TLS. Você pode usar esse emissor para desenvolvimento e testes. Para obter mais informações, consulte Autoridade de certificação raiz padrão e emissor para certificados de servidor TLS.

Para a produção, você precisa configurar um emissor de AC com um certificado de uma AC confiável, conforme descrito nas seções anteriores.

Configurar o TLS com o gerenciamento manual de certificados

Para configurar manualmente o agente MQTT para usar um certificado TLS específico, especifique-o em um recurso BrokerListener com uma referência a um segredo do Kubernetes. Em seguida, implante-o usando kubectl. Este artigo mostra um exemplo para configurar o TLS com certificados autoassinados para teste.

Criar autoridade de certificação com a CLI do Step

Step é um gerenciador de certificados que pode rapidamente colocar você em funcionamento ao criar e gerenciar sua própria AC privada.

  1. Instale a CLI do Step e crie um certificado e uma chave de autoridade de certificação raiz (AC).

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

  2. Crie um certificado de autoridade intermediária e uma chave assinada pela AC raiz.

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

Criar certificado de servidor

Use a CLI do Step para criar um certificado de servidor a partir da AC intermediária.

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

Aqui, mqtts-endpoint e localhost são os SANs (Nomes Alternativos da Entidade) para o front-end do agente MQTT no Kubernetes e clientes locais, respectivamente. Para se conectar pela Internet, adicione um --san com um IP externo. Os sinalizadores --no-password --insecure são usados para testes para ignorar prompts de senha e desabilitar a proteção de senha para a chave privada porque ela é armazenada em um segredo do Kubernetes. Para produção, use uma senha e armazene a chave privada em um local seguro como o Azure Key Vault.

Requisitos de algoritmo de chave de certificado

Há suporte para chaves EC e RSA, mas todos os certificados na cadeia devem usar o mesmo algoritmo de chave. Se você importar seus próprios certificados de AC, verifique se o certificado do servidor usa o mesmo algoritmo de chave que as ACs.

Importar cadeia de certificados do servidor como um segredo do Kubernetes

  1. Crie uma cadeia de certificados de servidor completa, em que a ordem dos certificados é importante: o certificado do servidor é o primeiro no arquivo, o intermediário é o segundo.

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

  2. Crie um segredo do Kubernetes com a cadeia de certificados do servidor e a chave do servidor usando kubectl.

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

Habilitar o gerenciamento manual de certificados TLS para uma porta

Veja a seguir um exemplo de um recurso BrokerListener que habilita o TLS na porta 8884 com gerenciamento automático de certificados.

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

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

  3. Selecionar ou criar um ouvinte. Você pode criar apenas um ouvinte por tipo de serviço. Se você já tiver um ouvinte do mesmo tipo de serviço, poderá adicionar mais portas ao ouvinte existente.

  4. Você pode adicionar configurações de TLS ao ouvinte selecionando o TLS em uma porta existente ou adicionando uma nova porta.

    Captura de tela usando o portal do Azure para criar um agente MQTT para o ouvinte do balanceador de carga com certificados TLS manuais.

    Digite as seguintes configurações:

    Configuração Descrição
    Porta Número da porta no qual o BrokerListener escuta conexões MQTT. Obrigatória.
    Autenticação A referência de recurso de autenticação.
    Autorização A referência de recurso da autorização.
    TLS Selecione o botão Adicionar.
    Nome secreto Segredo do Kubernetes que contém um certificado de cliente X.509.

  5. Clique em Salvar para salvar as configurações de TLS.

Conectar-se ao agente com o TLS

Para testar a conexão TLS com o cliente mosquitto, publique uma mensagem e passe o certificado de AC raiz no parâmetro --cafile.

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

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

Dica

Para usar o localhost, a porta deve estar disponível no computador host. Por exemplo, kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Com algumas distribuições do Kubernetes, como k3d, você pode adicionar uma porta encaminhada com k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Observação

Para se conectar ao agente, você precisa distribuir a raiz de confiança para os clientes, também conhecida como pacote de confiança. Nesse caso, a raiz da confiança é a AC raiz autoassinada criada pela CLI da Etapa. A distribuição da raiz de confiança é necessária para que o cliente verifique a cadeia de certificados do servidor. Se os clientes MQTT forem cargas de trabalho no cluster do Kubernetes, você também precisará criar um ConfigMap com a AC raiz e montá-lo no pod.

Lembre-se de especificar nome de usuário, senha etc., se a autenticação do agente MQTT estiver habilitada.

Usar IP externo para o certificado do servidor

Para se conectar ao TLS pela Internet, o certificado de servidor do agente MQTT deve ter seu nome de host externo como SAN. Em produção, geralmente esse é um nome DNS ou um endereço IP conhecido. No entanto, durante o desenvolvimento/teste, talvez você não saiba qual nome de host ou IP externo é atribuído antes da implantação. Para resolver isso, implante o ouvinte sem o certificado do servidor primeiro, depois crie o certificado e o segredo do servidor com o IP externo e, por fim, importe o segredo para o ouvinte.

Se você tentar implantar o ouvinte TLS de exemplo manual-tls-listener, mas o segredo do Kubernetes referenciado server-cert-secret não existir, o serviço associado será criado, mas os pods não iniciarão. O serviço é criado porque o operador precisa reservar o IP externo para o ouvinte.

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

No entanto, esse comportamento é esperado e não há problema em deixá-lo assim enquanto importamos o certificado do servidor. Os logs do gerenciador de integridade mencionam que o agente MQTT está aguardando o certificado do 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.

Observação

Geralmente, em um sistema distribuído, os logs de pods não são determinísticos e devem ser usados com cuidado. A maneira correta de informações como essa serem exibidas é por meio de eventos do Kubernetes e do status do recurso personalizado, que está na lista de pendências. Considere a etapa anterior como uma solução alternativa temporária.

Mesmo que os pods de front-end não estejam ativos, o IP externo já está disponível.

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 daqui, siga as mesmas etapas que anteriormente para criar um certificado de servidor com esse IP externo em --san e criar o segredo do Kubernetes da mesma maneira. Depois que o segredo é criado, ele é importado automaticamente para o ouvinte.

Conteúdo relacionado