Configurar o TLS com o gerenciamento automático de certificados para proteger a comunicação por MQTT na versão prévia de MQ da Internet das Coisas do Azure
Importante
O recurso Pré-visualização de Operações do Azure IoT — habilitado 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.
Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter 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.
Você pode configurar o TLS para proteger a comunicação por MQTT entre o agente de 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 recurso Operações do Azure IoT Versão Prévia no namespace de azure-iot-operations. Verifique a instalação antes de prosseguir.
Use
kubectlpara 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) 4d20hSe 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 de 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. A Versão prévia de MQ da Internet das Coisas do Azure pode ser usada com qualquer tipo de emissor do cert-manager.
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.
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: 256Crie 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-se as especificações 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.
Você pode usar o Azure Key Vault para gerenciar segredos da MQ da Internet das Coisas em vez de segredos do Kubernetes. Para saber mais, confira Gerenciar segredos usando o Azure Key Vault ou segredos do Kubernetes.
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 TLS para uma porta
Modifique a configuração tls em um recurso BrokerListener para especificar uma porta TLS e um Emissor para os front-ends. Veja a seguir 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
Após o recurso BrokerListener ter sido configurado, a MQ da IOT cria automaticamente um novo serviço com a porta especificada e o TLS habilitado.
Opcional: configurar parâmetros de certificado de servidor
Os únicos parâmetros obrigatórios são issuerRef.name e issuerRef.kind. Todas as propriedades dos certificados de servidor TLS gerados são escolhidas automaticamente. No entanto, a MQ da IOT permite que determinadas propriedades sejam personalizadas ao especificá-las no recurso BrokerListener, em tls.automatic.issuerRef. Veja a seguir um exemplo de todas as propriedades com suporte:
# 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 implantação
Use o 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
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-listenerno exemplo) ou peloCLUSTER-IPdo serviço. - Se estiver se conectando de fora do cluster, pelo
EXTERNAL-IPdo serviço.
Lembre-se de especificar os métodos de autenticação, se necessário. Por exemplo, nome de usuário e senha.
AC raiz padrão e emissor com o recurso Operações do Azure IoT Versão Prévia
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.
O certificado de AC é autoassinado e não é considerado confiável por nenhum cliente fora do recurso Operações do Azure IoT. O titular do certificado de AC é
CN = Azure IoT Operations Quickstart Root CA - Not for Productione expira em 30 dias a contar do momento da instalação.O certificado de AC raiz é armazenado em um segredo do Kubernetes chamado
aio-ca-key-pair-test-only.A porção pública do certificado de AC raiz é armazenada em um ConfigMap chamado
aio-ca-trust-bundle-test-only. Você pode recuperar o certificado de AC a partir do ConfigMap e inspecioná-lo com o kubectl e o 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:9dPor padrão, já existe um emissor de AC configurado no namespace de
azure-iot-operationschamadoaio-ca-issuer. É usado como o emissor de AC comum para todos os certificados de servidor TLS para as Operações de IoT. A MQ da IOT usa um emissor criado a partir do mesmo certificado de AC 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 a produção, você precisa configurar um emissor de AC com um certificado de uma AC confiável, conforme descrito nas seções anteriores.
Conteúdo relacionado
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de