Configurar TLS com gerenciamento automático de certificados para proteger a comunicação MQTT no Azure IoT MQ Preview

Artigo
11/15/2023

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.

Você pode configurar o TLS para proteger a comunicação MQTT entre o broker MQTT e o cliente usando um recurso BrokerListener. Você pode configurar o TLS com gerenciamento manual ou automático de certificados.

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.

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

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 Azure IoT MQ Preview pode ser usado com qualquer tipo de emissor do 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.

Desenvolvimento ou teste
Produção

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.

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

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.

Você pode usar o Azure Key Vault para gerenciar segredos para 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.

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.

Para produção, verifique a documentação do cert-manager para ver qual emissor funciona melhor para você. Por exemplo, com o Emissor do Vault:

Implante o cofre em um ambiente de escolha, como o Kubernetes. Inicialize e deslacre o cofre de acordo.
Crie e configure o mecanismo de segredos PKI importando seu certificado de autoridade de certificação.

Configure o vault com função e política para emitir certificados de servidor.

Segue-se um exemplo de função. Observação ExtKeyUsageServerAuth faz o certificado do servidor funcionar:

vault write pki/roles/my-issuer \
  allow_any_name=true \
  client_flag=false \
  ext_key_usage=ExtKeyUsageServerAuth \
  no_store=true \
  max_ttl=240h

Exemplo de política para a função:

path "pki/sign/my-issuer" {
  capabilities = ["create", "update"]
}

Configure a autenticação entre o cert-manager e o vault usando um método de escolha, como o SAT.
Configure o emissor do Vault cert-manager.

Habilitar TLS para uma porta

Modifique a tls configuração em um recurso BrokerListener para especificar uma porta TLS e um Emissor para os frontends. A seguir está um exemplo de um recurso BrokerListener que habilita o TLS na porta 8884 com gerenciamento automático de certificados.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: my-new-tls-listener
  namespace: azure-iot-operations
spec:
  brokerRef: broker
  authenticationEnabled: false # If set to true, a BrokerAuthentication resource must be configured
  authorizationEnabled: false
  serviceType: loadBalancer # Optional; defaults to 'clusterIP'
  serviceName: my-new-tls-listener # Avoid conflicts with default service name 'aio-mq-dmqtt-frontend'
  port: 8884 # Avoid conflicts with default port 8883
  tls:
    automatic:
      issuerRef:
        name: my-issuer
        kind: Issuer

Depois que o recurso BrokerListener é configurado, o IoT MQ cria automaticamente um novo serviço com a porta especificada e o TLS habilitados.

Opcional: Configurar parâmetros de certificado do servidor

Os únicos parâmetros necessários são issuerRef.name e issuerRef.kind. Todas as propriedades dos certificados de servidor TLS gerados são escolhidas automaticamente. No entanto, o IoT MQ permite que determinadas propriedades sejam personalizadas especificando-as no recurso BrokerListener, em tls.automatic.issuerRef. Segue-se um exemplo de todas as propriedades suportadas:

# cert-manager issuer for TLS server certificate. Required.
issuerRef:
  # Name of issuer. Required.
  name: my-issuer
  # 'Issuer' or 'ClusterIssuer'. Required.
  kind: Issuer
  # Issuer group. Optional; defaults to 'cert-manager.io'.
  # External issuers may use other groups.
  group: cert-manager.io
# Namespace of certificate. Optional; omit to use default namespace.
namespace: az
# Where to store the generated TLS server certificate. Any existing
# data at the provided secret will be overwritten.
# Optional; defaults to 'my-issuer-{port}'.
secret: my-issuer-8884
# Parameters for the server certificate's private key.
# Optional; defaults to rotationPolicy: Always, algorithm: ECDSA, size: 256.
privateKey:
  rotationPolicy: Always
  algorithm: ECDSA
  size: 256
# Total lifetime of the TLS server certificate. Optional; defaults to '720h' (30 days).
duration: 720h
# When to begin renewing the certificate. Optional; defaults to '240h' (10 days).
renewBefore: 240h
# Any additional SANs to add to the server certificate. Omit if not required.
san:
  dns:
  - iotmq.example.com
  ip:
  - 192.168.1.1

Verificar a implementação

Use kubectl para verificar se o serviço associado ao recurso BrokerListener está em execução. No exemplo acima, o nome do serviço é my-new-tls-listener e o namespace é azure-iot-operations. O comando a seguir verifica o status do serviço:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
my-new-tls-listener    LoadBalancer   10.43.241.171   XXX.XX.X.X    8884:32457/TCP   33s

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. Por exemplo, nome de usuário e senha.

CA raiz padrão e emissor com o Azure IoT Operations Preview

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.

O certificado da autoridade de certificação é autoassinado e não é confiável por nenhum cliente fora das Operações do Azure IoT. O assunto do certificado de autoridade de certificação é CN = Azure IoT Operations Quickstart Root CA - Not for Production e expira em 30 dias a partir do momento da instalação.
O certificado de autoridade de certificação raiz é armazenado em um segredo do Kubernetes chamado aio-ca-key-pair-test-only.

A parte pública do certificado de autoridade de certificação raiz é armazenada em um ConfigMap chamado aio-ca-trust-bundle-test-only. Você pode recuperar o certificado da autoridade de certificação do ConfigMap e inspecioná-lo com kubectl e openssl.

$ kubectl get configmap aio-ca-trust-bundle-test-only -n azure-iot-operations -o json | jq -r '.data["ca.crt"]' | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            74:d8:b6:fe:63:5a:7d:24:bd:c2:c0:25:c2:d2:c7:94:66:af:36:89
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = Azure IoT Operations Quickstart Root CA - Not for Production
        Validity
            Not Before: Nov  2 00:34:31 2023 GMT
            Not After : Dec  2 00:34:31 2023 GMT
        Subject: CN = Azure IoT Operations Quickstart Root CA - Not for Production
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:51:43:93:2c:dd:6b:7e:10:18:a2:0f:ca:2e:7b:
                    bb:ba:5c:78:81:7b:06:99:b5:a8:11:4f:bb:aa:0d:
                    e0:06:4f:55:be:f9:5f:9e:fa:14:75:bb:c9:01:61:
                    0f:20:95:cd:9b:69:7c:70:98:f8:fa:a0:4c:90:da:
                    5b:1a:d7:e7:6b
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: 
                Certificate Sign
            X509v3 Subject Key Identifier: 
                B6:DD:8A:42:77:05:38:7A:51:B4:8D:8E:3F:2A:D1:79:32:E9:43:B9
    Signature Algorithm: ecdsa-with-SHA256
        30:44:02:20:21:cd:61:d7:21:86:fd:f8:c3:6d:33:36:53:e3:
        a6:06:3c:a6:80:14:13:55:16:f1:19:a8:85:4b:e9:5d:61:eb:
        02:20:3e:85:8a:16:d1:0f:0b:0d:5e:cd:2d:bc:39:4b:5e:57:
        38:0b:ae:12:98:a9:8f:12:ea:95:45:71:bd:7c:de:9d

Por padrão, já há um emissor de CA configurado no azure-iot-operations namespace chamado aio-ca-issuer. Ele é usado como o emissor de CA comum para todos os certificados de servidor TLS para operações IoT. O IoT MQ usa um emissor criado a partir do mesmo certificado de CA para emitir certificados de servidor TLS para o ouvinte TLS padrão na porta 8883. Você pode inspecionar o emissor com o seguinte comando:

$ kubectl get issuer aio-ca-issuer -n azure-iot-operations -o yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  annotations:
    meta.helm.sh/release-name: azure-iot-operations
    meta.helm.sh/release-namespace: azure-iot-operations
  creationTimestamp: "2023-11-01T23:10:24Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: aio-ca-issuer
  namespace: azure-iot-operations
  resourceVersion: "2036"
  uid: c55974c0-e0c3-4d35-8c07-d5a0d3f79162
spec:
  ca:
    secretName: aio-ca-key-pair-test-only
status:
  conditions:
  - lastTransitionTime: "2023-11-01T23:10:59Z"
    message: Signing CA verified
    observedGeneration: 1
    reason: KeyPairVerified
    status: "True"
    type: Ready

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

Partilhar via

Configurar TLS com gerenciamento automático de certificados para proteger a comunicação MQTT no Azure IoT MQ Preview

Verificar a instalação do cert-manager

Criar um emissor para o certificado do servidor TLS

Configurar o certificado raiz como um segredo do Kubernetes

Distribuir o certificado raiz

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

Habilitar TLS para uma porta

Opcional: Configurar parâmetros de certificado do servidor

Verificar a implementação

Conecte-se ao corretor com TLS

CA raiz padrão e emissor com o Azure IoT Operations Preview

Recursos adicionais

Partilhar via

Configurar TLS com gerenciamento automático de certificados para proteger a comunicação MQTT no Azure IoT MQ Preview

Verificar a instalação do cert-manager

Criar um emissor para o certificado do servidor TLS

Configurar o certificado raiz como um segredo do Kubernetes

Distribuir o certificado raiz

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

Habilitar TLS para uma porta

Opcional: Configurar parâmetros de certificado do servidor

Verificar a implementação

Conecte-se ao corretor com TLS

CA raiz padrão e emissor com o Azure IoT Operations Preview

Conteúdos relacionados

Recursos adicionais