Zabezpečení komunikace zprostředkovatele MQTT pomocí BrokerListener

Článek
01/23/2025

Důležité

Tato stránka obsahuje pokyny ke správě komponent operací Azure IoT pomocí manifestů nasazení Kubernetes, které jsou ve verzi Preview. Tato funkce je poskytována s několika omezeními a neměla by se používat pro produkční úlohy.

Právní podmínky, které platí pro funkce Azure, které jsou ve verzi beta, verzi Preview nebo které zatím nejsou veřejně dostupné, najdete v Dodatečných podmínkách použití pro Microsoft Azure verze Preview.

Prostředek BrokerListener odpovídá koncovému bodu sítě, který zprostředkovatele zpřístupňuje klientům přes síť. Pro každého zprostředkovatele můžete mít jeden nebo více prostředků BrokerListener s více porty a různým řízením přístupu.

Každý port BrokerListener může mít vlastní ověřovací a autorizační pravidla, která definují, kdo se může připojit na daném portu naslouchacího procesu a jaké akce můžou u zprostředkovatele provádět. Prostředky BrokerAuthentication a BrokerAuthorization můžete použít k určení zásad řízení přístupu pro každý port naslouchacího procesu. Tato flexibilita umožňuje jemně vyladit oprávnění a role pro klienty MQTT na základě jejich potřeb a případů použití.

Tip

Výchozí nasazení zprostředkovatele MQTT je služba IP clusteru, která vyžaduje, aby se klienti připojili pomocí protokolu TLS (Transport Layer Security) a ověřili se pomocí tokenů účtu služby. Klienti, kteří se připojují mimo cluster , potřebují před připojením další konfiguraci .

Naslouchací procesy zprostředkovatele mají následující charakteristiky:

Název: Název naslouchacího procesu. Tento název je také název služby Kubernetes, pokud ho nepřepíšete.
Typ služby: Můžete mít až tři naslouchací procesy, jeden na typ služby. Výchozí naslouchací proces je typ ClusterIpslužby .
Porty: Každý naslouchací proces podporuje více portů. Porty nemůžou kolidovat s různými naslouchacími procesy.
Odkazy na ověřování a autorizaci: BrokerAuthentication a BrokerAuthorization se konfigurují na port.
TLS: Ruční nebo automatická konfigurace protokolu TLS se použije na port.
Protokol: Pro každý port je možné povolit MQTT přes WebSockets .

Seznam všech dostupných nastavení najdete v referenčních informacích k rozhraní API naslouchacího procesu zprostředkovatele.

Výchozí brokerListener

Když nasadíte operace Azure IoT, nasazení vytvoří prostředek BrokerListener s názvem výchozí. Tento naslouchací proces se používá pro šifrovanou interní komunikaci mezi komponentami operací IoT. Výchozí naslouchací proces je součástí výchozího zprostředkovatele.

Zveřejňuje službu ClusterIp na portu 18883.
Vyžaduje, aby klienti používali ověřování účtu služby Kubernetes.
Má automaticky spravovaný certifikát TLS.
Nenakonfiguruje žádné zásady autorizace klientů.

Upozornění

Aby nedošlo k narušení interní komunikace operací IoT, ponechte výchozí naslouchací proces beze změny a vyhrazený pro interní použití. Pro externí komunikaci vytvořte nový naslouchací proces. Pokud potřebujete službu použít ClusterIp , přidejte do výchozího naslouchacího procesu další porty beze změny stávajícího nastavení.

Pokud chcete zobrazit nebo upravit výchozí naslouchací proces, postupujte takto.

Na webu Azure Portal přejděte do vaší instance ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
V seznamu naslouchacího procesu zprostředkovatele vyberte výchozí naslouchací proces.
Zkontrolujte nastavení naslouchacího procesu, ale vyhněte se úpravám některého z existujících nastavení. Místo toho vytvořte nový port a podle potřeby ho nakonfigurujte.

Při úpravě výchozího naslouchacího procesu pomocí bicep buďte opatrní. Stávající nastavení neměňte. Místo toho přidejte do výchozího naslouchacího procesu další porty. Následující příklad ukazuje, jak přidat nový port do výchozího naslouchacího procesu:

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    // Don't change the service name or service type
    serviceType: 'ClusterIp'
    serviceName: 'aio-broker'
    ports: [
      // Don't modify the default port 18883 settings
      {
        port: 18883
        authenticationRef: 'default'
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
            privateKey: {
              algorithm: 'Ec256'
              rotationPolicy: 'Always'
            }
          }
        }
      }
      // Add more ports here, like the following example
      {
        port: 1884
        protocol: 'Mqtt'
      }
    ]
  }
}

Nasazení souboru Bicep pomocí Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Pokud chcete zobrazit výchozí prostředek BrokerListener, použijte následující příkaz:

kubectl get brokerlistener default -n azure-iot-operations -o yaml

Výstup by měl vypadat podobně jako v tomto příkladu, přičemž většina metadat byla odebrána kvůli stručnosti:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: default
  namespace: azure-iot-operations
  ownerReferences:
  - apiVersion: mqttbroker.iotoperations.azure.com/v1
    kind: Broker
    name: default
spec:
  serviceType: ClusterIp
  serviceName: aio-broker
  ports:
  - port: 18883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: azure-iot-operations-aio-certificate-issuer
          kind: ClusterIssuer
          group: cert-manager.io
        privateKey:
          algorithm: Ec256
          rotationPolicy: Always

Pokud chcete do výchozího naslouchacího procesu přidat nový port 1883 bez tls a ověřování, použijte tento kubectl patch příkaz:

kubectl patch brokerlistener default -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/-", "value": {"port": 1883, "protocol": "Mqtt"}}]'

Vyhněte se úpravám výchozího naslouchacího procesu zprostředkovatele.

Pokud chcete zabránit narušení interní komunikace operací IoT, ponechte výchozí naslouchací proces beze změny a vyhrazený pro interní použití. Pro externí komunikaci vytvořte nový naslouchací proces.

Vzhledem k tomu, že výchozí naslouchací proces zprostředkovatele používá typ ClusterIpslužby a pro každý typ služby můžete mít pouze jeden naslouchací proces, přidejte do výchozího naslouchacího procesu další porty, aniž byste museli měnit stávající nastavení, pokud potřebujete službu použítClusterIp.

Vytvoření nových naslouchacích procesů zprostředkovatele

Pokud chcete vytvořit nový naslouchací proces, zadejte následující nastavení:

Název: Název naslouchacího procesu. Tento název je také název služby Kubernetes, pokud ho nepřepíšete.
Typ služby: Typ služby Kubernetes. Viz Typ služby.
Porty: Seznam portů, na které se mají naslouchat. Viz Porty.
Název služby (volitelné): Přepište název služby Kubernetes. Viz Název služby.

Příklad: Vytvoření nového naslouchacího procesu se dvěma porty

Tento příklad ukazuje, jak vytvořit nový naslouchací proces s typem LoadBalancer služby. Prostředek BrokerListener definuje dva porty, které přijímají připojení MQTT z klientů.

První port naslouchá na portu 1883 bez protokolu TLS a ověřování. Toto nastavení je vhodné jenom pro testování. Tuto konfiguraci nepoužívejte v produkčním prostředí.
Druhý port naslouchá na portu 8883 s povoleným protokolem TLS a ověřováním. Připojit se můžou jenom ověření klienti s tokenem účtu služby Kubernetes. Protokol TLS je nastavený na automatický režim, pomocí nástroje cert-manager ke správě certifikátu serveru od výchozího vystavitele. Toto nastavení je blíže produkční konfiguraci.

Na webu Azure Portal přejděte do vaší instance ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.

Vyberte naslouchací proces zprostředkovatele MQTT pro vytvoření loadbalanceru>.

Zadejte následující nastavení:

Nastavení	Description
Name	Název prostředku BrokerListener.
Service name	Název služby Kubernetes Ponechte prázdný název naslouchacího procesu jako název služby.
Typ služby	LoadBalancer už je vybraný.

V části Porty zadejte následující nastavení pro první port:

Nastavení Popis

Port Zadejte 1883.

Ověřování Zvolte Žádné.

Autorizace Zvolte Žádné.

Protokol Zvolte MQTT.

Protokol TLS Nepřidávejte.
Vyberte Přidat položku portu a přidejte druhý port a zadejte následující nastavení:

Nastavení Popis

Port Zadejte 8883.

Ověřování Zvolte výchozí.

Autorizace Zvolte Žádné.

Protokol Zvolte MQTT.

Protokol TLS Vyberte Přidat.
V podokně konfigurace protokolu TLS zadejte následující nastavení:

Nastavení Popis

Režim TLS Zvolte Automaticky.

Název vystavitele Zadejte azure-iot-operations-aio-certificate-issuer.

Druh vystavitele Zvolte ClusterIssuer.

U ostatních nastavení ponechte výchozí nastavení a vyberte Použít.
Vyberte Vytvořit naslouchací proces.

Nastavení	Popis
Port	Zadejte 1883.
Ověřování	Zvolte Žádné.
Autorizace	Zvolte Žádné.
Protokol	Zvolte MQTT.
Protokol TLS	Nepřidávejte.

Nastavení	Popis
Port	Zadejte 8883.
Ověřování	Zvolte výchozí.
Autorizace	Zvolte Žádné.
Protokol	Zvolte MQTT.
Protokol TLS	Vyberte Přidat.

Nastavení	Popis
Režim TLS	Zvolte Automaticky.
Název vystavitele	Zadejte `azure-iot-operations-aio-certificate-issuer`.
Druh vystavitele	Zvolte ClusterIssuer.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = '<LISTENER_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        port: 1883
        protocol: 'Mqtt'
      }
      {
        authenticationRef: 'default'
        port: 8883
        protocol: 'Mqtt'
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'azure-iot-operations-aio-certificate-issuer'
              kind: 'ClusterIssuer'
              group: 'cert-manager.io'
            }
          }
        }
      }
    ]
  }
}

Nasazení souboru Bicep pomocí Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: <LISTENER_NAME>
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: LoadBalancer
  ports:
  - port: 1883
    protocol: Mqtt
  - port: 8883
    authenticationRef: default
    protocol: Mqtt
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
            name: azure-iot-operations-aio-certificate-issuer
            kind: ClusterIssuer
            group: cert-manager.io

Typ služby

Každý prostředek BrokerListener se mapuje na službu Kubernetes. Typ služby určuje, jak je zprostředkovatel vystaven v síti. Mezi podporované typy služeb patří:

ClusterIp: Zveřejňuje zprostředkovatele na interní IP adrese clusteru. Klienti se můžou ke zprostředkovateli připojit z clusteru. Tento výchozí typ služby je určený pro výchozí naslouchací proces.
NodePort: Zpřístupňuje zprostředkovatele na IP adrese každého uzlu na statickém portu. Klienti se můžou připojit ke zprostředkovateli mimo cluster. Tento typ služby je užitečný pro vývoj a testování.
LoadBalancer: Zpřístupňuje zprostředkovatele externě. Služba má přiřazenou externí IP adresu, kterou můžou klienti použít pro připojení ke zprostředkovateli. Tento typ služby je nejběžnější pro produkční nasazení.

Pouze jeden naslouchací proces na typ služby

Je povolen pouze jeden naslouchací proces na jeden typ služby. Pokud potřebujete více připojení stejného typu služby, přidejte do existujícího naslouchacího procesu tohoto typu služby další porty.

Service name

Název služby je název služby Kubernetes přidružené ke zprostředkovateli. Pokud není zadaný, název naslouchacího procesu zprostředkovatele se použije jako název služby. Název služby musí být jedinečný v rámci oboru názvů.

Tip

Pokud chcete zabránit režijním nákladům na správu, doporučujeme ponechat název služby prázdný. Název naslouchacího procesu je jedinečný a můžete ho použít k identifikaci služby. Název služby použijte jako přepsání pouze v případech, kdy nemůžete službu pojmenovat po naslouchacím procesu.

Porty

Každý naslouchací proces může mít více portů a každý port může mít vlastní nastavení pro ověřování, autorizaci, protokol a TLS.

Pokud chcete pro port použít vlastní nastavení ověřování nebo autorizace, musíte před použitím s naslouchacím procesem vytvořit odpovídající prostředky. Další informace najdete v tématu Konfigurace ověřování zprostředkovatele MQTT a konfigurace autorizace zprostředkovatele MQTT.

Pokud chcete použít protokol TLS, přečtěte si část Konfigurace protokolu TLS s automatickou správou certifikátů nebo konfigurace protokolu TLS s ručně prováděných oddíly správy certifikátů.

Použití stejného portu mezi naslouchacími procesy

Použití stejného čísla portu napříč různými naslouchacími procesy se nepodporuje. Každé číslo portu musí být jedinečné v rámci zprostředkovatele IoT Operations MQTT.

Pokud máte například naslouchací proces pomocí portu 1883, nemůžete vytvořit další naslouchací proces s portem 1883. Podobně výchozí naslouchací proces používá port 18883, takže nemůžete vytvořit další naslouchací proces s portem 18883.

Podpora pro WebSockets

Zprostředkovatel IoT Operations MQTT podporuje MQTT přes WebSockets. Pokud chcete povolit protokol WebSockets, nastavte pro WebSockets port protokol.

Konfigurace protokolu TLS s automatickou správou certifikátů

Pokud chcete povolit protokol TLS s automatickou správou certifikátů, zadejte nastavení protokolu TLS na portu naslouchacího procesu.

Ověření instalace nástroje cert-manager

Pomocí automatické správy certifikátů můžete ke správě certifikátu serveru TLS použít nástroj cert-manager. Ve výchozím nastavení je nástroj cert-manager nainstalovaný společně s operacemi IoT v cert-manager oboru názvů. Než budete pokračovat, ověřte instalaci.

Pomocí kubectl zkontrolujte pody, které odpovídají popiskům aplikací nástroje cert-manager.

kubectl get pods --namespace cert-manager -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

Pokud se zobrazí pody, které jsou připravené a spuštěné, nainstaluje se cert-manager a je připravený k použití.

Tip

Pokud chcete instalaci dále ověřit, zkontrolujte v dokumentaci nástroje cert-manager a ověřte instalaci. Nezapomeňte použít cert-manager obor názvů.

Vytvoření vystavitele pro certifikát serveru TLS

Prostředek vystavitele cert-manageru definuje, jak se certifikáty vydávají automaticky. Cert-manager nativně podporuje několik typů vystavitelů. Podporuje také externí issuer typ pro rozšíření funkčnosti nad rámec nativně podporovaných vystavitelů. Zprostředkovatele MQTT můžete použít s jakýmkoli typem vystavitele cert-manageru.

Důležité

Během počátečního nasazení se operace IoT nainstalují s výchozím vystavitelem pro certifikáty serveru TLS. Tento vystavitel můžete použít pro vývoj a testování. Další informace najdete v tématu Výchozí kořenová certifikační autorita (CA) a vystavitel s využitím operací Azure IoT. Následující kroky se vyžadují jenom v případě, že chcete použít jiného vystavitele.

Přístup k vytvoření vystavitele se liší v závislosti na vašem scénáři. Následující části obsahují příklady, které vám pomůžou začít.

Vývoj nebo testování
Produkční

Vystavitel certifikační autority je užitečný pro vývoj a testování. Musí být nakonfigurovaný s certifikátem a privátním klíčem uloženým v tajném kódu Kubernetes.

Nastavení kořenového certifikátu jako tajného kódu Kubernetes

Pokud máte existující certifikát certifikační autority, vytvořte tajný klíč Kubernetes s certifikátem certifikační autority a soubory PEM privátního klíče certifikační autority. Spuštěním následujícího příkazu naimportujte certifikát certifikační autority jako tajný klíč Kubernetes a přeskočte další část.

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

Pokud certifikát certifikační autority nemáte, může certifikát certifikační autority vygenerovat správce certifikační autority za vás. Použití nástroje cert-manager k vygenerování certifikátu certifikační autority se označuje jako bootstrapping vystavitele certifikační autority s certifikátem podepsaným svým držitelem.

Začněte vytvořením 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

Vytvořte certifikát certifikační autority podepsaný svým držitelem pomocí následujícího příkazu:
```
kubectl apply -f ca.yaml
```

Cert-manager vytvoří certifikát certifikační autority pomocí výchozích hodnot. Vlastnosti tohoto certifikátu můžete změnit úpravou specifikace certifikátu. Seznam platných možností najdete v dokumentaci k nástroji cert-manager.

Distribuce kořenového certifikátu

Předchozí příklad ukládá certifikát certifikační autority do tajného kódu Kubernetes s názvem test-ca. Certifikát můžete načíst ve formátu PEM z tajného kódu a uložit ho do souboru ca.crt pomocí následujícího příkazu:

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

Tento certifikát musí být distribuovaný a důvěryhodný všemi klienty. Například použijte --cafile příznak pro klienta Mosquitto.

Vytvoření vystavitele na základě certifikátu certifikační autority

Cert-manager potřebuje vystavitele na základě certifikátu certifikační autority vygenerovaného nebo importovaného v předchozím kroku. Vytvořte následující soubor takto 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

Vytvořte vystavitele pomocí následujícího příkazu:

kubectl apply -f issuer-ca.yaml

Předchozí příkaz vytvoří vystavitele pro vystavování certifikátů serveru TLS. Poznamenejte si název a druh vystavitele. V příkladu je my-issuer název a druh je Issuer. Tyto hodnoty se později nastaví v prostředku BrokerListener.

V produkčním prostředí zkontrolujte dokumentaci k nástroji cert-manager a zjistěte, který vystavitel vám nejlépe vyhovuje. Například s vystavitelem trezoru:

Nasaďte službu HashiCorp Vault v libovolném prostředí, jako je Kubernetes. Inicializovat a zrušit trezor odpovídajícím způsobem.
Vytvořte a nakonfigurujte modul tajných kódů PKI importováním certifikátu certifikační autority.

Nakonfigurujte trezor s rolí a zásadou pro vystavování certifikátů serveru.

Příkladem je následující role. Všimněte si, že ExtKeyUsageServerAuth certifikát serveru funguje:

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

Příklad zásady pro roli:

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

Nastavte ověřování mezi cert-managerem a trezorem pomocí zvolené metody, jako je SAT.
Nakonfigurujte vystavitele trezoru cert-manageru.

Povolení automatické správy certifikátů TLS pro port

Následující příklad je prostředek BrokerListener, který umožňuje protokol TLS na portu 8884 s automatickou správou certifikátů.

Na webu Azure Portal přejděte do vaší instance ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte nebo vytvořte naslouchací proces. Pro každý typ služby můžete vytvořit pouze jeden naslouchací proces. Pokud už máte naslouchací proces stejného typu služby, můžete do existujícího naslouchacího procesu přidat další porty.

Nastavení protokolu TLS můžete do naslouchacího procesu přidat výběrem protokolu TLS na existujícím portu nebo přidáním nového portu.

Zadejte následující nastavení:

Nastavení	Description
Name	Název prostředku BrokerListener. Zadejte `aio-broker-loadbalancer-tls`.
Port	Číslo portu, na kterém BrokerListener naslouchá připojení MQTT. Zadejte 8884.
Ověřování	Referenční informace k prostředkům ověřování.
Autorizace	Referenční informace k prostředkům autorizace.
Protokol TLS	Vyberte tlačítko Přidat.
Název vystavitele	Název vystavitele cert-manageru Povinný:
Druh vystavitele	Druh vystavitele cert-manageru Povinný:
Skupina vystavitelů	Skupina vystavitele cert-manageru Povinný:
Algoritmus privátního klíče	Algoritmus pro privátní klíč
Zásady obměně privátních klíčů	Zásady pro obměně privátního klíče
Názvy DNS	Alternativní názvy subjektu DNS pro certifikát
Adresy IP	IP adresy alternativních názvů subjektu pro certifikát.
Název tajného klíče	Tajný klíč Kubernetes obsahující klientský certifikát X.509
Doba trvání	Celková životnost certifikátu serveru TLS je ve výchozím nastavení 90 dnů.
Prodloužit před	Kdy začít obnovovat certifikát.

Výběrem možnosti Použít uložíte nastavení protokolu TLS.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerName string = 'aio-broker-loadbalancer-tls'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8884
        tls: {
          mode: 'Automatic'
          certManagerCertificateSpec: {
            issuerRef: {
              name: 'my-issuer'
              kind: 'Issuer'
            }
          }
        }
      }
    ]
  }
}

Nasazení souboru Bicep pomocí Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

tls Upravte nastavení v prostředku BrokerListener tak, aby určil port TLS a Issuer front-endy.

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: aio-broker-loadbalancer-tls # Avoid conflicts with default service name 'aio-broker'
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer
  ports:
  - port: 8884 # Avoid conflicts with default port 18883
    tls:
      mode: Automatic
      certManagerCertificateSpec:
        issuerRef:
          name: my-issuer
          kind: Issuer

Po nakonfigurování prostředku BrokerListener zprostředkovatel MQTT automaticky vytvoří novou službu se zadaným portem a povoleným protokolem TLS.

Volitelné: Konfigurace parametrů certifikátu serveru

Jedinými požadovanými parametry jsou Issuer název a Issuer druh. Všechny ostatní vlastnosti vygenerovaných certifikátů serveru TLS se vyberou automaticky. Zprostředkovatel MQTT však umožňuje přizpůsobení určitých vlastností podle stejné syntaxe jako certifikáty cert-manageru. Můžete například zadat algoritmus privátního klíče a zásady obměně. Tato nastavení jsou v tls.certManagerCertificateSpec podokně konfigurace protokolu TLS na webu Azure Portal nebo v podokně konfigurace protokolu TLS.

Úplný seznam těchto nastavení naleznete v tématu Zprostředkovatel listener CertManagerCertificateSpec ROZHRANÍ API.

Ověření nasazení

Pomocí kubectl zkontrolujte, jestli je spuštěná služba přidružená k prostředku BrokerListener. V předchozím příkladu je aio-broker-loadbalancer-tls název služby a obor názvů je azure-iot-operations. Následující příkaz zkontroluje stav služby:

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

Připojení ke zprostředkovateli pomocí protokolu TLS

Po nakonfigurování certifikátu serveru je povolený protokol TLS. Testování pomocí Mosquitto:

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

Argument --cafile umožňuje protokol TLS na klientovi Mosquitto a určuje, že klient by měl důvěřovat všem certifikátům serveru vydaným konkrétním souborem. Musíte zadat soubor, který obsahuje vystavitele nakonfigurovaného certifikátu serveru TLS.

Nahraďte $HOST příslušným hostitelem:

Pokud se připojujete ze stejného clusteru, nahraďte názvem služby (my-new-tls-listener v příkladu) nebo službou CLUSTER-IP.
Pokud se připojujete mimo cluster, použijte službu EXTERNAL-IP.

Nezapomeňte v případě potřeby zadat metody ověřování.

Výchozí kořenová certifikační autorita a vystavitel

Aby vám to pomohlo začít, nasadí se operace IoT s výchozím certifikátem certifikační autority pro rychlý start a vystavitelem pro certifikáty serveru TLS. Tento vystavitel můžete použít pro vývoj a testování. Další informace najdete v tématu Výchozí kořenová certifikační autorita a vystavitel pro certifikáty serveru TLS.

V produkčním prostředí musíte nakonfigurovat vystavitele certifikační autority s certifikátem od důvěryhodné certifikační autority, jak je popsáno v předchozích částech.

Konfigurace protokolu TLS s ruční správou certifikátů

Pokud chcete ručně nakonfigurovat zprostředkovatele MQTT tak, aby používal konkrétní certifikát TLS, zadejte ho v prostředku BrokerListener s odkazem na tajný klíč Kubernetes a nasaďte ho pomocí kubectl. Tento článek ukazuje příklad, který konfiguruje protokol TLS s certifikáty podepsanými svým držitelem pro testování.

Vytvoření certifikační autority pomocí rozhraní příkazového řádku kroku

Krok je správce certifikátů, který vás rychle zprovozní při vytváření a správě vlastní privátní certifikační autority.

Nainstalujte krok cli a vytvořte kořenový certifikát a klíč certifikační autority.
```
step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key
```

Vytvořte certifikát a klíč zprostředkující certifikační autority podepsaný kořenovou certifikační autoritou.

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

Vytvoření certifikátu serveru

Pomocí rozhraní příkazového řádku kroku vytvořte certifikát serveru z certifikátu a klíče zprostředkující certifikační autority.

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

mqtts-endpoint Tady jsou localhost alternativní názvy subjektu (SANs) pro front-end zprostředkovatele MQTT v Kubernetes a místních klientech. Pokud se chcete připojit přes internet, přidejte --san externí IP adresu. Příznaky --no-password --insecure se používají k testování, aby se přeskočí výzvy k zadání hesla a zakázala ochranu heslem pro privátní klíč, protože je uložená v tajném kódu Kubernetes. V produkčním prostředí použijte heslo a privátní klíč uložte do zabezpečeného umístění, jako je Azure Key Vault.

Požadavky na algoritmus klíče certifikátu

Podporují se klíče EC i RSA, ale všechny certifikáty v řetězu musí používat stejný algoritmus klíče. Pokud importujete vlastní certifikáty certifikační autority, ujistěte se, že certifikát serveru používá stejný algoritmus klíče jako certifikační autority.

Import řetězu certifikátů serveru jako tajného kódu Kubernetes

Vytvořte úplný řetěz certifikátů serveru, ve kterém záleží na pořadí certifikátů. Certifikát serveru je první certifikát v souboru a zprostředkující je druhý.
```
cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt
```

Vytvořte tajný klíč Kubernetes s řetězem certifikátů serveru a klíčem serveru pomocí kubectl.

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

Povolení ruční správy certifikátů TLS pro port

Následující příklad ukazuje prostředek BrokerListener, který umožňuje tls na portu 8884 s ruční správou certifikátů.

Na webu Azure Portal přejděte do vaší instance ioT Operations.
V části Součásti vyberte Zprostředkovatele MQTT.
Vyberte nebo vytvořte naslouchací proces. Pro každý typ služby můžete vytvořit pouze jeden naslouchací proces. Pokud už máte naslouchací proces stejného typu služby, můžete do existujícího naslouchacího procesu přidat další porty. Pokud chcete postupovat podle příkladu, zadejte název služby naslouchacího procesu jako mqtts-endpoint.

Nastavení protokolu TLS můžete do naslouchacího procesu přidat výběrem protokolu TLS na existujícím portu nebo přidáním nového portu.

Zadejte následující nastavení:

Nastavení	Popis
Port	Číslo portu, na kterém BrokerListener naslouchá připojení MQTT. Povinný:
Ověřování	Referenční informace k prostředkům ověřování.
Autorizace	Referenční informace k prostředkům autorizace.
Protokol TLS	Vyberte tlačítko Přidat.
Název tajného klíče	Tajný klíč Kubernetes obsahující klientský certifikát X.509

Výběrem možnosti Použít uložíte nastavení protokolu TLS.

tls Upravte nastavení v prostředku BrokerListener a určete ruční konfiguraci protokolu TLS odkazující na tajný klíč Kubernetes. Poznamenejte si název tajného klíče použitého pro certifikát serveru TLS (server-cert-secret v předchozím příkladu).

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param listenerServiceName string = 'mqtts-endpoint'
param listenerName string = '<LISTENER_NAME>' // Match the SAN in the server certificate

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource loadBalancerListener 'Microsoft.IoTOperations/instances/brokers/listeners@2024-11-01' = {
  parent: defaultBroker
  name: listenerName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }

  properties: {
    serviceName: listenerServiceName
    serviceType: 'LoadBalancer'
    ports: [
      {
        authenticationRef: 'default'
        port: 8885 // Avoid port conflict with default listener at 18883
        tls: {
          mode: 'Manual'
          manual: {
            secretRef: 'server-cert-secret'
          }
        }
      }
    ]
  }
}

Nasazení souboru Bicep pomocí Azure CLI:

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerListener
metadata:
  name: loadbalancer-tls
  namespace: azure-iot-operations
spec:
  brokerRef: default
  serviceType: loadBalancer # Optional, defaults to clusterIP
  serviceName: mqtts-endpoint # Match the SAN in the server certificate
  ports:
  - port: 8885 # Avoid port conflict with default listener at 18883
    tls:
      mode: Manual
      manual:
        secretRef: server-cert-secret

Po vytvoření prostředku BrokerListener operátor automaticky vytvoří službu Kubernetes a nasadí naslouchací proces. Stav služby můžete zkontrolovat spuštěním kubectl get svcpříkazu .

Připojení ke zprostředkovateli pomocí protokolu TLS

Pokud chcete otestovat připojení TLS s klientem Mosquitto, publikujte zprávu a předejte kořenový certifikát certifikační autority v parametru --cafile.

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

Nezapomeňte zadat položky, jako je uživatelské jméno a heslo, pokud je povolené ověřování zprostředkovatele MQTT.

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

Tip

Pokud chcete použít localhost, musí být port dostupný na hostitelském počítači. Příklad: kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. S některými distribucemi Kubernetes, jako je K3d, můžete přidat přesměrovaný port s k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Pokud se chcete připojit ke zprostředkovateli, musíte distribuovat kořen důvěryhodnosti, označovaný také jako sada důvěryhodnosti, všem klientům. V tomto případě je kořenem důvěryhodnosti kořenová certifikační autorita podepsaná svým držitelem vytvořená v rozhraní příkazového řádku kroku. Aby klient ověřil řetěz certifikátů serveru, vyžaduje se distribuce kořenového adresáře důvěryhodnosti. Pokud jsou klienti MQTT úlohami v clusteru Kubernetes, musíte také vytvořit objekt ConfigMap s kořenovou certifikační autoritou a připojit ho do podu.

Použití externí IP adresy pro certifikát serveru

Pokud se chcete připojit pomocí protokolu TLS přes internet, musí mít certifikát serveru zprostředkovatele MQTT svůj externí název hostitele nebo IP adresu jako síť SAN. V produkčním prostředí jsou tyto informace obvykle názvem DNS nebo dobře známou IP adresou. Během vývoje/testování možná nevíte, jaký název hostitele nebo externí IP adresa se přiřadí před nasazením. Pokud chcete tento problém vyřešit, nasaďte nejprve naslouchací proces bez certifikátu serveru, vytvořte certifikát serveru a tajný klíč s externí IP adresou a naimportujte tajný kód do naslouchacího procesu.

Pokud se pokusíte nasadit ukázkový naslouchací proces manual-tls-listener TLS, ale odkazovaný tajný klíč server-cert-secret Kubernetes neexistuje, vytvoří se přidružená služba, ale pody se nespustí. Služba se vytvoří, protože operátor musí rezervovat externí IP adresu pro naslouchací proces.

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

Toto chování se očekává při importu certifikátu serveru. V protokolech správce stavu se uvádí, že zprostředkovatel MQTT čeká na certifikát serveru.

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.

Poznámka:

Obecně platí, že v distribuovaném systému nejsou protokoly podů deterministické a měly by se používat s opatrností. Správný způsob, jak se dostat k informacím, je prostřednictvím událostí Kubernetes a stavu vlastních prostředků, které jsou v backlogu. Představte si předchozí krok jako dočasné alternativní řešení.

I když front-endové pody nejsou vzhůru, externí IP adresa je už dostupná.

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

Odsud postupujte podle stejných kroků jako dříve, abyste vytvořili certifikát serveru s touto externí IP adresou --san a stejným způsobem vytvořili tajný klíč Kubernetes. Po vytvoření tajného kódu se automaticky naimportuje do naslouchacího procesu.

Sdílet prostřednictvím

Zabezpečení komunikace zprostředkovatele MQTT pomocí BrokerListener

Výchozí brokerListener

Vyhněte se úpravám výchozího naslouchacího procesu zprostředkovatele.

Vytvoření nových naslouchacích procesů zprostředkovatele

Příklad: Vytvoření nového naslouchacího procesu se dvěma porty

Typ služby

Pouze jeden naslouchací proces na typ služby

Service name

Porty

Použití stejného portu mezi naslouchacími procesy

Podpora pro WebSockets

Konfigurace protokolu TLS s automatickou správou certifikátů

Ověření instalace nástroje cert-manager

Vytvoření vystavitele pro certifikát serveru TLS

Nastavení kořenového certifikátu jako tajného kódu Kubernetes

Distribuce kořenového certifikátu

Vytvoření vystavitele na základě certifikátu certifikační autority

Povolení automatické správy certifikátů TLS pro port

Volitelné: Konfigurace parametrů certifikátu serveru

Ověření nasazení

Připojení ke zprostředkovateli pomocí protokolu TLS

Výchozí kořenová certifikační autorita a vystavitel

Konfigurace protokolu TLS s ruční správou certifikátů

Vytvoření certifikační autority pomocí rozhraní příkazového řádku kroku

Vytvoření certifikátu serveru

Požadavky na algoritmus klíče certifikátu

Import řetězu certifikátů serveru jako tajného kódu Kubernetes

Povolení ruční správy certifikátů TLS pro port

Připojení ke zprostředkovateli pomocí protokolu TLS

Použití externí IP adresy pro certifikát serveru

Váš názor

Další materiály

Sdílet prostřednictvím

Zabezpečení komunikace zprostředkovatele MQTT pomocí BrokerListener

Výchozí brokerListener

Vyhněte se úpravám výchozího naslouchacího procesu zprostředkovatele.

Vytvoření nových naslouchacích procesů zprostředkovatele

Příklad: Vytvoření nového naslouchacího procesu se dvěma porty

Typ služby

Pouze jeden naslouchací proces na typ služby

Service name

Porty

Použití stejného portu mezi naslouchacími procesy

Podpora pro WebSockets

Konfigurace protokolu TLS s automatickou správou certifikátů

Ověření instalace nástroje cert-manager

Vytvoření vystavitele pro certifikát serveru TLS

Nastavení kořenového certifikátu jako tajného kódu Kubernetes

Distribuce kořenového certifikátu

Vytvoření vystavitele na základě certifikátu certifikační autority

Povolení automatické správy certifikátů TLS pro port

Volitelné: Konfigurace parametrů certifikátu serveru

Ověření nasazení

Připojení ke zprostředkovateli pomocí protokolu TLS

Výchozí kořenová certifikační autorita a vystavitel

Konfigurace protokolu TLS s ruční správou certifikátů

Vytvoření certifikační autority pomocí rozhraní příkazového řádku kroku

Vytvoření certifikátu serveru

Požadavky na algoritmus klíče certifikátu

Import řetězu certifikátů serveru jako tajného kódu Kubernetes

Povolení ruční správy certifikátů TLS pro port

Připojení ke zprostředkovateli pomocí protokolu TLS

Použití externí IP adresy pro certifikát serveru

Související obsah

Váš názor

Další materiály