Partilhar via

Proteja a comunicação do broker MQTT usando o BrokerListener

  • 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.

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

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

Gorjeta

Você só pode acessar a implantação padrão do broker MQTT usando o IP do cluster, TLS e um token de conta de serviço. Os clientes que se conectam 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 padrão BrokerListener chamado padrão é o tipo clusterIpde serviço .
  • Cada ouvinte suporta várias portas
  • As referências BrokerAuthentication e BrokerAuthorization são por porta
  • A configuração TLS é por porta
  • Os nomes de serviço devem ser exclusivos
  • As portas não podem entrar em conflito entre ouvintes diferentes

Para obter uma lista das configurações disponíveis, consulte a referência da API do Broker Listener .

BrokerListener padrão

Quando você implanta o azure-iot-operations Azure IoT Operations Preview, a implantação também cria um recurso BrokerListener nomeado default no namespace. Esse ouvinte está vinculado ao recurso padrão do Broker nomeado default que também é criado durante a implantação. O ouvinte padrão expõe o broker na porta 18883 com a autenticação TLS e SAT habilitada. O certificado TLS é gerenciado automaticamente pelo cert-manager. A autorização está desativada por padrão.

Para visualizar ou editar o ouvinte:

  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.

    Captura de tela usando o portal do Azure para exibir a configuração MQTT do Azure IoT Operations.

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

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

  4. Revise as configurações do ouvinte e faça as alterações necessárias.

Criar novos ouvintes de corretor

Este exemplo mostra como criar um novo recurso BrokerListener chamado loadbalancer-listener para um recurso Broker . 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 broker sem criptografia ou autenticação.
  • A segunda porta escuta na porta 18883 com TLS e autenticação habilitados. Somente clientes autenticados podem se conectar ao broker com criptografia TLS. TLS é definido como , o automaticque significa que o ouvinte usa cert-manager para obter e renovar seu certificado de servidor.

  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 MQTT para LoadBalancer>Create. Você só pode criar 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 o agente MQTT para ouvinte do balanceador de carga.

    Introduza as seguintes definições:

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

  4. Selecione Criar ouvinte.

Configurar TLS com gerenciamento automático de certificados

Para habilitar o TLS com 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 azure-iot-operations Azure IoT Operations Preview no namespace. Verifique a instalação antes de continuar.

  1. Use kubectl para verificar se os pods correspondem aos rótulos do aplicativo 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ê vir os pods mostrados como prontos e em execução, o cert-manager está instalado e pronto para uso.

Gorjeta

Para verificar melhor a instalação, verifique a documentação do cert-manager verificar a instalação. Lembre-se de usar o azure-iot-operations namespace.

Criar um emissor para o certificado do servidor TLS

O recurso Emissor cert-manager define como os certificados são emitidos automaticamente. O Cert-manager suporta vários tipos de Emissores nativamente. Ele também suporta um tipo de emissor externo para estender a funcionalidade além dos emissores suportados nativamente. O corretor MQTT pode ser usado com qualquer tipo de emissor cert-manager.

Importante

Durante a implantação inicial, as Operações IoT do Azure são instaladas com um Emissor padrão para certificados de servidor TLS. Você pode usar esse emissor para desenvolvimento e testes. Para obter mais informações, consulte CA raiz padrão e emissor com operações do Azure IoT. As etapas abaixo só são necessárias se você quiser usar um emissor diferente.

A abordagem para criar o emissor é diferente dependendo do seu cenário. As seções a seguir listam exemplos para ajudá-lo a começar.

O emissor da autoridade de certificação é útil para desenvolvimento e testes. Ele deve ser configurado com um certificado e uma chave privada armazenados em um segredo do Kubernetes.

Configurar o certificado raiz como um segredo do Kubernetes

Se você tiver um certificado de autoridade de certificação existente, crie um segredo do Kubernetes com o certificado da autoridade de certificação e os arquivos PEM de chave privada. Execute o seguinte comando e você configurou o certificado raiz como um segredo do Kubernetes e pode 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 autoridade de certificação raiz para você. Usar o cert-manager para gerar um certificado de autoridade de certificação raiz é conhecido como inicializar um emissor de autoridade de certificação com um certificado autoassinado.

  1. Comece por criar 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 autoridade de certificação autoassinado com o seguinte comando:

    kubectl apply -f ca.yaml

O Cert-manager cria um certificado de CA usando seus padrões. As propriedades deste certificado podem ser alteradas modificando a especificação do certificado. Consulte 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 da autoridade de certificação em um segredo do Kubernetes chamado test-ca. O certificado em formato PEM pode ser recuperado 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

Este certificado deve ser distribuído e confiável por todos os clientes. Por exemplo, use --cafile flag para um cliente mosquitto.

Criar emissor com base no certificado da autoridade de certificação

O Cert-manager precisa de um emissor com base no certificado de autoridade de certificação 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, nome my-issuer e tipo Issuer. Esses valores são definidos no recurso BrokerListener posteriormente.

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

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

  1. No portal do Azure, vá para sua instância de Operações IoT.

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

  3. Selecione ou crie um ouvinte. Você só pode criar 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 o agente MQTT para ouvinte do balanceador de carga com certificados TLS automáticos.

    Introduza as seguintes definições:

    Definição Descrição
    Porta Número da porta na qual o BrokerListener escuta conexões MQTT. Obrigatório.
    Autenticação A referência do recurso de autenticação.
    Autorização A referência do recurso de autorização.
    TLS Selecione o botão Adicionar.
    Nome do emissor Nome do emissor do gestor de certificados. Obrigatório.
    Tipo de emitente Tipo de emissor do gestor de certificados. Obrigatório.
    Grupo de emitentes Grupo do emitente do gestor de certificados. Obrigatório.
    Algoritmo de chave privada Algoritmo para a chave privada.
    Política de rotação de chave privada Política de rotação da chave privada.
    Nomes DNS Nomes alternativos de entidade DNS para o certificado.
    Endereços IP Endereços IP da entidade nomes alternativos para o certificado.
    Nome do segredo Segredo do Kubernetes contendo um certificado de cliente X.509.
    Duração Tempo de vida total do certificado do servidor TLS O padrão é de 90 dias.
    Renovar antes Quando começar a renovar o certificado.

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

Conecte-se ao corretor com TLS

Depois que o certificado do servidor estiver configurado, o TLS será habilitado. Para testar com mosquitto:

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

O --cafile argumento habilita o TLS no cliente mosquitto e especifica que o cliente deve confiar em todos os certificados de servidor emitidos pelo arquivo fornecido. Você deve 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-listenerpor exemplo) ou pelo serviço CLUSTER-IP.
  • Se estiver se conectando de fora do cluster, o serviço EXTERNAL-IP.

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

CA raiz padrão e emissor

Para ajudá-lo a começar, o Azure IoT Operations é implantado com uma CA 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 CA raiz padrão e emissor para certificados de servidor TLS.

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

Configurar TLS com gerenciamento manual de certificados

Para configurar manualmente o broker 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 da Etapa

O Step é um gerenciador de certificados que pode rapidamente colocá-lo em funcionamento ao criar e gerenciar sua própria CA privada.

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

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

  2. Crie um certificado de autoridade de certificação intermediário e uma chave assinada pela autoridade de certificação 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 de etapa para criar um certificado de servidor a partir do assinado pela autoridade de certificação 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 estão os nomes alternativos de assunto (SANs) para o frontend do broker MQTT no Kubernetes e clientes locais, respectivamente. Para se conectar pela Internet, adicione um --san com um IP externo. Os --no-password --insecure sinalizadores são usados para testes para ignorar prompts de senha e desabilitar a proteção por 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 Cofre de Chaves do Azure.

Requisitos do algoritmo de chave de certificado

As chaves EC e RSA são suportadas, mas todos os certificados na cadeia devem usar o mesmo algoritmo de chave. Se você importar seus próprios certificados de autoridade de certificação, certifique-se de que o certificado do servidor use o mesmo algoritmo de chave que as autoridades de certificação.

Importar cadeia de certificados do servidor como um segredo do Kubernetes

  1. Crie uma cadeia de certificados de servidor completa, onde 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

A seguir está um exemplo de um recurso BrokerListener que habilita o TLS na porta 8884 com gerenciamento manual de certificados.

  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 ou crie um ouvinte. Você só pode criar 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 o agente MQTT para ouvinte do balanceador de carga com certificados TLS manuais.

    Introduza as seguintes definições:

    Definição Descrição
    Porta Número da porta na qual o BrokerListener escuta conexões MQTT. Obrigatório.
    Autenticação A referência do recurso de autenticação.
    Autorização A referência do recurso de autorização.
    TLS Selecione o botão Adicionar.
    Nome do segredo Segredo do Kubernetes contendo um certificado de cliente X.509.

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

Conecte-se ao corretor com TLS

Para testar a conexão TLS com o cliente mosquitto, publique uma mensagem e passe o certificado de autoridade de certificação 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

Gorjeta

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

Nota

Para se conectar ao broker, você precisa distribuir raiz de confiança para os clientes, também conhecida como trust bundle. Nesse caso, a raiz da confiança é a CA 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 seus clientes MQTT são cargas de trabalho no cluster Kubernetes, você também precisa criar um ConfigMap com a CA raiz e montá-lo em seu Pod.

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

Usar IP externo para o certificado do servidor

Para se conectar ao TLS pela Internet, o certificado do servidor do broker MQTT deve ter seu nome de host externo como SAN. Na produção, este é geralmente um nome DNS ou um endereço IP bem 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, em seguida, crie o certificado do servidor e o segredo com o IP externo e, finalmente, importe o segredo para o ouvinte.

Se você tentar implantar o ouvinte manual-tls-listener TLS de exemplo, mas o segredo server-cert-secret do Kubernetes referenciado não existir, o serviço associado será criado, mas os pods não serão iniciados. 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 corretor 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.

Nota

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

Mesmo que os pods de frontend 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 anteriores para criar um certificado de servidor com esse IP externo e --san criar o segredo do Kubernetes da mesma maneira. Uma vez que o segredo é criado, ele é automaticamente importado para o ouvinte.

Conteúdos relacionados