Zabezpieczanie komunikacji brokera MQTT przy użyciu brokeraListener

Artykuł
11/20/2024

Ważne

Ta strona zawiera instrukcje dotyczące zarządzania składnikami operacji usługi Azure IoT przy użyciu manifestów wdrażania platformy Kubernetes, które są w wersji zapoznawczej. Ta funkcja jest udostępniana z kilkoma ograniczeniami i nie powinna być używana w przypadku obciążeń produkcyjnych.

Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

BrokerListener odpowiada punktowi końcowemu sieci, który uwidacznia brokera klientom za pośrednictwem sieci. Dla każdego brokera można mieć co najmniej jeden zasób BrokerListener z wieloma portami i inną kontrolą dostępu.

Każdy port BrokerListener może mieć własne reguły uwierzytelniania i autoryzacji, które definiują, kto może nawiązać połączenie na tym porcie odbiornika i jakie akcje mogą wykonywać na brokerze. Możesz użyć zasobów BrokerAuthentication i BrokerAuthorization , aby określić zasady kontroli dostępu dla każdego portu odbiornika. Ta elastyczność pozwala dostosować uprawnienia i role dla klientów MQTT w zależności od ich potrzeb i przypadków użycia.

Napiwek

Domyślne wdrożenie brokera MQTT to usługa ip klastra, która wymaga od klientów nawiązywania połączenia z protokołem TLS i uwierzytelniania przy użyciu tokenów konta usługi. Klienci łączący się spoza klastra potrzebują dodatkowej konfiguracji , zanim będą mogli nawiązać połączenie.

Odbiorniki brokera mają następujące cechy:

Nazwa: nazwa odbiornika. Ta nazwa jest również nazwą usługi Kubernetes, chyba że zostanie zastąpiona.
Typ usługi: można mieć maksymalnie trzy odbiorniki, jeden na typ usługi. Domyślny odbiornik to typ ClusterIpusługi .
Porty: każdy odbiornik obsługuje wiele portów. Porty nie mogą powodować konfliktu między różnymi odbiornikami.
Dokumentacja uwierzytelniania i autoryzacji: BrokerAuthentication i BrokerAuthorization są konfigurowane na port.
TLS: ręczna lub automatyczna konfiguracja protokołu TLS jest stosowana na port.
Protokół: protokół MQTT za pośrednictwem obiektów WebSocket można włączyć na port.

Aby uzyskać listę wszystkich dostępnych ustawień, zobacz dokumentację interfejsu API odbiornika brokera.

Domyślny element BrokerListener

Podczas wdrażania operacji usługi Azure IoT wdrożenie tworzy zasób BrokerListener o nazwie default. Ten odbiornik jest używany do szyfrowanej komunikacji wewnętrznej między składnikami operacji usługi Azure IoT. Domyślny odbiornik jest częścią domyślnego brokera.

Uwidacznia usługę ClusterIp na porcie 18883
Wymaga to od klientów korzystania z uwierzytelniania konta usługi Kubernetes Service
Ma automatycznie zarządzany certyfikat TLS
Nie konfiguruje żadnych zasad autoryzacji klienta

Uwaga

Aby uniknąć zakłócania wewnętrznej komunikacji operacji usługi Azure IoT, zachowaj domyślny odbiornik bez zmian i dedykowany do użytku wewnętrznego. W przypadku komunikacji zewnętrznej utwórz nowy odbiornik. Jeśli musisz użyć usługi ClusterIp, dodaj więcej portów do odbiornika domyślnego bez zmiany żadnego z istniejących ustawień.

Aby wyświetlić lub edytować odbiornik domyślny:

W witrynie Azure Portal przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Z listy odbiornika brokera wybierz odbiornik domyślny .
Przejrzyj ustawienia odbiornika, ale unikaj modyfikowania dowolnego z istniejących ustawień. Zamiast tego utwórz nowy port i skonfiguruj go zgodnie z potrzebami.

Zachowaj ostrożność podczas modyfikowania odbiornika domyślnego przy użyciu Bicep. Nie zmieniaj istniejących ustawień. Zamiast tego dodaj więcej portów do odbiornika domyślnego. W poniższym przykładzie pokazano, jak dodać nowy port do odbiornika domyślnego.

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'
      }
    ]
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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

Aby wyświetlić domyślny zasób BrokerListener, użyj następującego polecenia:

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

Dane wyjściowe powinny wyglądać podobnie do tych, a większość metadanych została usunięta w celu zwięzłości:

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

Aby dodać nowy port 1883 bez protokołu TLS i uwierzytelniania wyłączonego do odbiornika domyślnego, użyj kubectl patch polecenia :

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

Unikaj modyfikowania domyślnego odbiornika brokera

Aby zapobiec zakłócaniu wewnętrznej komunikacji operacji usługi Azure IoT, zachowaj domyślny odbiornik bez zmian i dedykowany do użytku wewnętrznego. W przypadku komunikacji zewnętrznej utwórz nowy odbiornik.

Ponieważ domyślny odbiornik brokera używa typu usługi ClusterIp i można mieć tylko jeden odbiornik na typ usługi, dodaj więcej portów do odbiornika domyślnego bez zmiany żadnych istniejących ustawień, jeśli chcesz użyć usługi ClusterIp.

Tworzenie nowych odbiorników brokera

Aby utworzyć nowy odbiornik, określ następujące ustawienia:

Nazwa: nazwa odbiornika. Ta nazwa jest również nazwą usługi Kubernetes, chyba że zostanie zastąpiona.
Typ usługi: typ usługi Kubernetes. Zobacz Typ usługi.
Porty: lista portów do nasłuchiwania. Zobacz Porty.
(Opcjonalnie) Nazwa usługi: przesłaniaj nazwę usługi Kubernetes. Zobacz Nazwa usługi.

Przykład: tworzenie nowego odbiornika z dwoma portami

W tym przykładzie pokazano, jak utworzyć nowy odbiornik z typem usługi modułu równoważenia obciążenia. Zasób BrokerListener definiuje dwa porty, które akceptują połączenia MQTT od klientów.

Pierwszy port nasłuchuje na porcie 1883 bez protokołu TLS i uwierzytelniania. Ta konfiguracja jest odpowiednia tylko do testowania. Nie używaj tej konfiguracji w środowisku produkcyjnym.
Drugi port nasłuchuje na porcie 8883 z włączonym protokołem TLS i uwierzytelnianiem. Tylko uwierzytelnieni klienci z tokenem konta usługi Kubernetes mogą się łączyć. Protokół TLS jest ustawiony na tryb automatyczny, używając menedżera certyfikatów do zarządzania certyfikatem serwera z domyślnego wystawcy. Ta konfiguracja jest bliższa konfiguracji produkcyjnej.

W witrynie Azure Portal przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.

Wybierz pozycję Odbiornik brokera MQTT dla pozycji LoadBalancer>Utwórz.

Wprowadź następujące ustawienia:

Ustawienie	opis
Nazwa/nazwisko	Nazwa zasobu BrokerListener.
Service name	Nazwa usługi Kubernetes. Pozostaw wartość pustą, aby użyć nazwy odbiornika jako nazwy usługi.
Typ usługi	Moduł LoadBalancer został już wybrany.

W obszarze Porty wprowadź następujące ustawienia dla pierwszego portu:

Ustawienie opis

Port Wprowadź wartość 1883

Uwierzytelnianie Wybierz pozycję Brak

Autoryzacja Wybierz pozycję Brak

Protokół Wybierz MQTT

TLS Nie dodawaj
Wybierz pozycję Dodaj wpis portu, aby dodać drugi port, a następnie wprowadź następujące ustawienia:

Ustawienie opis

Port Wprowadź wartość 8883

Uwierzytelnianie Wybierz wartość domyślną

Autoryzacja Wybierz pozycję Brak

Protokół Wybierz MQTT

TLS Wybierz Dodaj
W okienku Konfiguracja protokołu TLS wprowadź następujące ustawienia:

Ustawienie opis

Tryb TLS Wybierz pozycję Automatyczne

Nazwa wystawcy Wprowadź azure-iot-operations-aio-certificate-issuer

Rodzaj wystawcy Wybierz pozycję ClusterIssuer

Pozostaw inne ustawienia jako domyślne, a następnie wybierz pozycję Zastosuj.
Wybierz pozycję Utwórz odbiornik.

Ustawienie	opis
Port	Wprowadź wartość 1883
Uwierzytelnianie	Wybierz pozycję Brak
Autoryzacja	Wybierz pozycję Brak
Protokół	Wybierz MQTT
TLS	Nie dodawaj

Ustawienie	opis
Port	Wprowadź wartość 8883
Uwierzytelnianie	Wybierz wartość domyślną
Autoryzacja	Wybierz pozycję Brak
Protokół	Wybierz MQTT
TLS	Wybierz Dodaj

Ustawienie	opis
Tryb TLS	Wybierz pozycję Automatyczne
Nazwa wystawcy	Wprowadź `azure-iot-operations-aio-certificate-issuer`
Rodzaj wystawcy	Wybierz pozycję 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'
            }
          }
        }
      }
    ]
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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 usługi

Każdy element BrokerListener jest mapowy na usługę Kubernetes. Typ usługi określa, jak broker jest uwidoczniony w sieci. Obsługiwane typy usług to:

ClusterIp: uwidacznia brokera w wewnętrznym adresie IP klastra. Klienci mogą łączyć się z brokerem z poziomu klastra. Jest to domyślny typ usługi dla odbiornika domyślnego.
NodePort: uwidacznia brokera w adresie IP każdego węzła na porcie statycznym. Klienci mogą łączyć się z brokerem spoza klastra. Ten typ usługi jest przydatny do programowania i testowania.
LoadBalancer: uwidacznia brokera zewnętrznie. Usługa ma przypisany zewnętrzny adres IP, którego klienci mogą używać do nawiązywania połączenia z brokerem. Jest to najbardziej typowy typ usługi dla wdrożeń produkcyjnych.

Tylko jeden odbiornik na typ usługi

Dozwolony jest tylko jeden odbiornik na typ usługi. Jeśli potrzebujesz więcej łączności tego samego typu usługi, dodaj więcej portów do istniejącego odbiornika tego typu usługi.

Service name

Nazwa usługi to nazwa usługi Kubernetes skojarzonej z brokerem. Jeśli nie zostanie określona, nazwa odbiornika brokera jest używana jako nazwa usługi. Nazwa usługi musi być unikatowa w przestrzeni nazw.

Napiwek

Aby zapobiec narzuceniu zarządzania, zalecamy pozostawienie pustej nazwy usługi. Nazwa odbiornika jest unikatowa i może służyć do identyfikowania usługi. Użyj nazwy usługi jako przesłonięcia tylko wtedy, gdy nie można nazwać usługi po odbiorniku.

Porty

Każdy odbiornik może mieć wiele portów, a każdy port może mieć własne ustawienia uwierzytelniania, autoryzacji, protokołu i protokołu TLS.

Aby użyć własnego ustawienia uwierzytelniania lub autoryzacji dla portu, należy utworzyć odpowiednie zasoby przed użyciem go z odbiornikiem. Aby uzyskać więcej informacji, zobacz Konfigurowanie uwierzytelniania brokera MQTT i Konfigurowanie autoryzacji brokera MQTT.

Aby użyć protokołu TLS, zobacz Konfigurowanie protokołu TLS z automatycznym zarządzaniem certyfikatami lub Konfigurowanie protokołu TLS przy użyciu ręcznych sekcji zarządzania certyfikatami .

Używanie tego samego portu między odbiornikami

Używanie tego samego numeru portu w różnych odbiornikach nie jest obsługiwane. Każdy numer portu musi być unikatowy w ramach brokera MQTT operacji usługi Azure IoT.

Jeśli na przykład masz odbiornik przy użyciu portu 1883, nie możesz utworzyć innego odbiornika z portem 1883. Podobnie odbiornik domyślny używa portu 18883, więc nie można utworzyć innego odbiornika z portem 18883.

Obsługa obiektów WebSocket

Broker MQTT operacji usługi Azure IoT obsługuje protokół MQTT za pośrednictwem obiektów WebSocket. Aby włączyć protokoły WebSocket, ustaw protokół WebSockets dla portu.

Konfigurowanie protokołu TLS z automatycznym zarządzaniem certyfikatami

Aby włączyć protokół TLS z automatycznym zarządzaniem certyfikatami, określ ustawienia protokołu TLS na porcie odbiornika.

Weryfikowanie instalacji menedżera certyfikatów

Automatyczne zarządzanie certyfikatami umożliwia zarządzanie certyfikatem serwera TLS za pomocą menedżera certyfikatów. Domyślnie program cert-manager jest instalowany wraz z operacjami usługi Azure IoT w cert-manager przestrzeni nazw. Przed kontynuowaniem sprawdź instalację.

Służy kubectl do sprawdzania zasobników pasujących do etykiet aplikacji 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

Jeśli zobaczysz zasobniki wyświetlane jako gotowe i uruchomione, narzędzie cert-manager jest zainstalowane i gotowe do użycia.

Napiwek

Aby jeszcze bardziej zweryfikować instalację, zapoznaj się z dokumentacją narzędzia cert-manager, aby zweryfikować instalację. Pamiętaj, aby użyć cert-manager przestrzeni nazw.

Tworzenie wystawcy dla certyfikatu serwera TLS

Zasób wystawcy certyfikatu definiuje sposób automatycznego wystawiania certyfikatów. Menedżer certyfikatów obsługuje natywnie kilka typów wystawców. Obsługuje również zewnętrzny typ wystawcy na potrzeby rozszerzania funkcji poza natywnie obsługiwanymi wystawcami. Broker MQTT może być używany z dowolnym typem wystawcy cert-manager.

Ważne

Podczas początkowego wdrażania operacje usługi Azure IoT są instalowane z domyślnym wystawcą dla certyfikatów serwera TLS. Tego wystawcy można użyć do programowania i testowania. Aby uzyskać więcej informacji, zobacz Domyślny główny urząd certyfikacji i wystawca przy użyciu operacji usługi Azure IoT. Poniższe kroki są wymagane tylko wtedy, gdy chcesz użyć innego wystawcy.

Podejście do tworzenia wystawcy różni się w zależności od scenariusza. W poniższych sekcjach wymieniono przykłady ułatwiające rozpoczęcie pracy.

Programowanie lub testowanie
Produkcyjne

Wystawca urzędu certyfikacji jest przydatny do programowania i testowania. Należy go skonfigurować przy użyciu certyfikatu i klucza prywatnego przechowywanego w kluczu tajnym kubernetes.

Konfigurowanie certyfikatu głównego jako wpisu tajnego kubernetes

Jeśli masz istniejący certyfikat urzędu certyfikacji, utwórz klucz tajny Kubernetes z certyfikatem urzędu certyfikacji i plikami PEM klucza prywatnego urzędu certyfikacji. Uruchom następujące polecenie, aby zaimportować certyfikat urzędu certyfikacji jako wpis tajny Kubernetes i pominąć następną sekcję.

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

Jeśli nie masz certyfikatu urzędu certyfikacji, menedżer certyfikatów może wygenerować certyfikat urzędu certyfikacji. Generowanie certyfikatu urzędu certyfikacji przy użyciu menedżera certyfikatu jest nazywane uruchamianiem wystawcy urzędu certyfikacji z certyfikatem z podpisem własnym.

Zacznij od utworzenia elementu 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

Utwórz certyfikat urzędu certyfikacji z podpisem własnym za pomocą następującego polecenia:
```
kubectl apply -f ca.yaml
```

Menedżer certyfikatów tworzy certyfikat urzędu certyfikacji przy użyciu jego wartości domyślnych. Właściwości tego certyfikatu można zmienić, modyfikując specyfikację certyfikatu. Aby uzyskać listę prawidłowych opcji, zobacz dokumentację menedżera certyfikatów.

Dystrybuowanie certyfikatu głównego

Poprzedni przykład przechowuje certyfikat urzędu certyfikacji w kluczu tajnym Kubernetes o nazwie test-ca. Certyfikat w formacie PEM można pobrać z wpisu tajnego i przechowywać w pliku ca.crt za pomocą następującego polecenia:

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

Ten certyfikat musi być dystrybuowany i zaufany przez wszystkich klientów. Na przykład użyj flagi --cafile dla klienta mosquitto.

Tworzenie wystawcy na podstawie certyfikatu urzędu certyfikacji

Menedżer certyfikatów wymaga wystawcy na podstawie certyfikatu urzędu certyfikacji wygenerowanego lub zaimportowanego we wcześniejszym kroku. Utwórz następujący plik jako 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

Utwórz wystawcę za pomocą następującego polecenia:

kubectl apply -f issuer-ca.yaml

Poprzednie polecenie tworzy wystawcę do wystawiania certyfikatów serwera TLS. Zanotuj nazwę i rodzaj wystawcy. W tym przykładzie nazwa to my-issuer , a rodzaj to Issuer. Te wartości są ustawiane w zasobie BrokerListener później.

Aby uzyskać informacje o środowisku produkcyjnym, zapoznaj się z dokumentacją menedżera certyfikatów, aby sprawdzić, który wystawca działa najlepiej. Na przykład za pomocą wystawcy magazynu:

Wdróż magazyn HashiCorp w wybranym środowisku, na przykład Kubernetes. Odpowiednio zainicjuj i rozpakuj magazyn.
Utwórz i skonfiguruj aparat wpisów tajnych infrastruktury kluczy publicznych, importując certyfikat urzędu certyfikacji.
Skonfiguruj magazyn z rolą i zasadami na potrzeby wystawiania certyfikatów serwera.

Poniżej przedstawiono przykładową rolę. Uwaga ExtKeyUsageServerAuth sprawia, że certyfikat serwera działa:
```
vault write pki/roles/my-issuer \
  allow_any_name=true \
  client_flag=false \
  ext_key_usage=ExtKeyUsageServerAuth \
  no_store=true \
  max_ttl=240h
```
Przykładowe zasady dla roli:
```
path "pki/sign/my-issuer" {
  capabilities = ["create", "update"]
}
```
Skonfiguruj uwierzytelnianie między menedżerem certyfikatów i magazynem przy użyciu wybranej metody, takiej jak SAT.
Skonfiguruj wystawcę magazynu cert-manager.

Włączanie automatycznego zarządzania certyfikatami TLS dla portu

Poniżej przedstawiono przykład zasobu BrokerListener, który umożliwia protokół TLS na porcie 8884 z automatycznym zarządzaniem certyfikatami.

W witrynie Azure Portal przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Wybierz lub utwórz odbiornik. Można utworzyć tylko jeden odbiornik na typ usługi. Jeśli masz już odbiornik tego samego typu usługi, możesz dodać więcej portów do istniejącego odbiornika.

Ustawienia protokołu TLS można dodać do odbiornika, wybierając protokół TLS na istniejącym porcie lub dodając nowy port.

Wprowadź następujące ustawienia:

Ustawienie	opis
Nazwa/nazwisko	Nazwa zasobu BrokerListener. Wprowadź `aio-broker-loadbalancer-tls`.
Port	Numer portu, na którym brokerListener nasłuchuje połączeń MQTT. Wprowadź wartość 8884.
Uwierzytelnianie	Dokumentacja zasobu uwierzytelniania.
Autoryzacja	Dokumentacja zasobu autoryzacji.
TLS	Kliknij przycisk Dodaj.
Nazwa wystawcy	Nazwa wystawcy menedżera certyfikatów. Wymagany.
Rodzaj wystawcy	Rodzaj wystawcy menedżera certyfikatów. Wymagany.
Grupa wystawców	Grupa wystawcy menedżera certyfikatów. Wymagany.
Algorytm klucza prywatnego	Algorytm klucza prywatnego.
Zasady rotacji kluczy prywatnych	Zasady rotacji klucza prywatnego.
Nazwy DNS	Alternatywne nazwy podmiotu DNS dla certyfikatu.
Adresy IP	Adresy IP alternatywne nazwy podmiotu dla certyfikatu.
Nazwa wpisu tajnego	Wpis tajny kubernetes zawierający certyfikat klienta X.509.
Czas trwania	Łączny okres istnienia certyfikatu serwera TLS Domyślnie wynosi 90 dni.
Odnów przed	Kiedy rozpocząć odnawianie certyfikatu.

Wybierz pozycję Zastosuj , aby zapisać ustawienia protokołu 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'
            }
          }
        }
      }
    ]
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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

Zmodyfikuj tls ustawienie w zasobie BrokerListener, aby określić port TLS i wystawcę dla frontonów.

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 skonfigurowaniu zasobu BrokerListener broker MQTT automatycznie tworzy nową usługę z włączonym określonym portem i protokołem TLS.

Opcjonalne: Konfigurowanie parametrów certyfikatu serwera

Jedynymi wymaganymi parametrami są nazwa wystawcy i rodzaj wystawcy. Wszystkie inne właściwości wygenerowanych certyfikatów serwera TLS są wybierane automatycznie. Jednak broker MQTT umożliwia dostosowanie niektórych właściwości zgodnie z tą samą składnią co certyfikaty menedżera certyfikatów. Można na przykład określić algorytm klucza prywatnego i zasady rotacji. Te ustawienia znajdują tls.certManagerCertificateSpec się w okienku konfiguracji protokołu TLS lub w witrynie Azure Portal.

Pełną listę tych ustawień można znaleźć w temacie Broker Listener CertManagerCertificateSpec API reference (Dokumentacja interfejsu API CertManagerCertificateSpec dla odbiornika brokera).

Weryfikowanie wdrożenia

Użyj narzędzia kubectl, aby sprawdzić, czy usługa skojarzona z zasobem BrokerListener jest uruchomiona. W powyższym przykładzie nazwa usługi to aio-broker-loadbalancer-tls , a przestrzeń nazw to azure-iot-operations. Następujące polecenie sprawdza stan usługi:

$ 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

Nawiązywanie połączenia z brokerem przy użyciu protokołu TLS

Po skonfigurowaniu certyfikatu serwera protokół TLS jest włączony. Aby przetestować z mosquitto:

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

--cafile Argument włącza protokół TLS na kliencie mosquitto i określa, że klient powinien ufać wszystkim certyfikatom serwera wystawionym przez dany plik. Należy określić plik zawierający wystawcę skonfigurowanego certyfikatu serwera TLS.

Zastąp $HOST element odpowiednim hostem:

Jeśli nawiązujesz połączenie z poziomu tego samego klastra, zastąp ciąg nazwą usługi podaną (my-new-tls-listener na przykład) lub usługą CLUSTER-IP.
W przypadku nawiązywania połączenia spoza klastra usługa EXTERNAL-IP.

Pamiętaj, aby w razie potrzeby określić metody uwierzytelniania.

Domyślny główny urząd certyfikacji i wystawca

Aby ułatwić rozpoczęcie pracy, operacje usługi Azure IoT są wdrażane przy użyciu domyślnego certyfikatu urzędu certyfikacji "Szybki start" i wystawcy dla certyfikatów serwera TLS. Tego wystawcy można użyć do programowania i testowania. Aby uzyskać więcej informacji, zobacz Domyślny główny urząd certyfikacji i wystawca dla certyfikatów serwera TLS.

W środowisku produkcyjnym należy skonfigurować wystawcę urzędu certyfikacji z certyfikatem z zaufanego urzędu certyfikacji, zgodnie z opisem w poprzednich sekcjach.

Konfigurowanie protokołu TLS przy użyciu ręcznego zarządzania certyfikatami

Aby ręcznie skonfigurować brokera MQTT do używania określonego certyfikatu TLS, określ go w zasobie BrokerListener z odwołaniem do wpisu tajnego kubernetes i wdróż go przy użyciu narzędzia kubectl. W tym artykule przedstawiono przykład konfigurowania protokołu TLS przy użyciu certyfikatów z podpisem własnym na potrzeby testowania.

Tworzenie urzędu certyfikacji przy użyciu interfejsu wiersza polecenia kroku

Krok to menedżer certyfikatów, który umożliwia szybkie rozpoczęcie pracy podczas tworzenia własnego prywatnego urzędu certyfikacji i zarządzania nim.

Zainstaluj krok interfejsu wiersza polecenia i utwórz certyfikat i klucz głównego urzędu certyfikacji.
```
step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key
```

Utwórz certyfikat pośredniego urzędu certyfikacji i klucz podpisany przez główny urząd certyfikacji.

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

Tworzenie certyfikatu serwera

Użyj kroku interfejsu wiersza polecenia, aby utworzyć certyfikat serwera na podstawie certyfikatu podpisanego przez pośredni urząd certyfikacji.

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 Tutaj i localhost są alternatywne nazwy podmiotów (SAN) dla frontonu brokera MQTT w kubernetes i klientów lokalnych, odpowiednio. Aby nawiązać połączenie za pośrednictwem Internetu, dodaj obiekt --san z zewnętrznym adresem IP. Flagi --no-password --insecure są używane do testowania w celu pomijania monitów o hasło i wyłączania ochrony haseł dla klucza prywatnego, ponieważ są one przechowywane w kluczu tajnym kubernetes. W środowisku produkcyjnym użyj hasła i zapisz klucz prywatny w bezpiecznej lokalizacji, takiej jak Azure Key Vault.

Wymagania dotyczące algorytmu klucza certyfikatu

Obsługiwane są zarówno klucze EC, jak i RSA, ale wszystkie certyfikaty w łańcuchu muszą używać tego samego algorytmu klucza. W przypadku importowania własnych certyfikatów urzędu certyfikacji upewnij się, że certyfikat serwera używa tego samego algorytmu klucza co urzędy certyfikacji.

Importowanie łańcucha certyfikatów serwera jako wpisu tajnego platformy Kubernetes

Utwórz pełny łańcuch certyfikatów serwera, w którym kolejność certyfikatów ma znaczenie: certyfikat serwera jest pierwszym w pliku, pośrednim jest drugi.
```
cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt
```

Utwórz wpis tajny kubernetes z łańcuchem certyfikatów serwera i kluczem serwera przy użyciu narzędzia kubectl.

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

Włączanie ręcznego zarządzania certyfikatami TLS dla portu

Poniżej przedstawiono przykład zasobu BrokerListener, który włącza protokół TLS na porcie 8884 z ręcznym zarządzaniem certyfikatami.

W witrynie Azure Portal przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Wybierz lub utwórz odbiornik. Można utworzyć tylko jeden odbiornik na typ usługi. Jeśli masz już odbiornik tego samego typu usługi, możesz dodać więcej portów do istniejącego odbiornika. Aby postępować zgodnie z przykładem, określ nazwę usługi odbiornika jako mqtts-endpoint.

Ustawienia protokołu TLS można dodać do odbiornika, wybierając protokół TLS na istniejącym porcie lub dodając nowy port.

Wprowadź następujące ustawienia:

Ustawienie	opis
Port	Numer portu, na którym brokerListener nasłuchuje połączeń MQTT. Wymagany.
Uwierzytelnianie	Dokumentacja zasobu uwierzytelniania.
Autoryzacja	Dokumentacja zasobu autoryzacji.
TLS	Kliknij przycisk Dodaj.
Nazwa wpisu tajnego	Wpis tajny kubernetes zawierający certyfikat klienta X.509.

Wybierz pozycję Zastosuj , aby zapisać ustawienia protokołu TLS.

Zmodyfikuj tls ustawienie w zasobie BrokerListener, aby określić ręczną konfigurację protokołu TLS odwołującą się do wpisu tajnego kubernetes. Zanotuj nazwę wpisu tajnego używanego dla certyfikatu serwera TLS (server-cert-secret w przykładzie wcześniej).

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'
          }
        }
      }
    ]
  }
}

Wdróż plik Bicep przy użyciu interfejsu wiersza polecenia platformy Azure.

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 utworzeniu zasobu BrokerListener operator automatycznie tworzy usługę Kubernetes i wdraża odbiornik. Stan usługi można sprawdzić, uruchamiając polecenie kubectl get svc.

Nawiązywanie połączenia z brokerem przy użyciu protokołu TLS

Aby przetestować połączenie TLS z klientem mosquitto, opublikuj komunikat i przekaż certyfikat głównego urzędu certyfikacji w parametrze --cafile.

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

Pamiętaj, aby określić nazwę użytkownika, hasło itp., jeśli jest włączone uwierzytelnianie brokera 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

Napiwek

Aby użyć hosta lokalnego, port musi być dostępny na maszynie hosta. Na przykład kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. W przypadku niektórych dystrybucji kubernetes, takich jak K3d, można dodać przekierowany port za pomocą polecenia k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Uwaga

Aby nawiązać połączenie z brokerem, należy rozpowszechnić katalog główny zaufania, znany również jako pakiet zaufania, do wszystkich klientów. W takim przypadku głównym elementem zaufania jest główny urząd certyfikacji z podpisem własnym utworzony przez interfejs wiersza polecenia kroku. Dystrybucja katalogu głównego zaufania jest wymagana, aby klient zweryfikował łańcuch certyfikatów serwera. Jeśli klienci MQTT są obciążeniami w klastrze Kubernetes, należy również utworzyć obiekt ConfigMap z głównym urzędem certyfikacji i zainstalować go w zasobniku.

Użyj zewnętrznego adresu IP dla certyfikatu serwera

Aby nawiązać połączenie z protokołem TLS przez Internet, certyfikat serwera brokera MQTT musi mieć zewnętrzną nazwę hosta lub adres IP jako sieć SAN. W środowisku produkcyjnym jest to zazwyczaj nazwa DNS lub dobrze znany adres IP. Jednak podczas tworzenia i testowania możesz nie wiedzieć, jaka nazwa hosta lub zewnętrzny adres IP jest przypisywany przed wdrożeniem. Aby rozwiązać ten problem, najpierw wdróż odbiornik bez certyfikatu serwera, utwórz certyfikat serwera i wpis tajny z zewnętrznym adresem IP i zaimportuj wpis tajny do odbiornika.

Jeśli spróbujesz wdrożyć przykładowy odbiornik manual-tls-listener TLS, ale przywoływał wpis tajny server-cert-secret Kubernetes nie istnieje, skojarzona usługa zostanie utworzona, ale zasobniki nie zostaną uruchomione. Usługa jest tworzona, ponieważ operator musi zarezerwować zewnętrzny adres IP dla odbiornika.

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

Jednak to zachowanie jest oczekiwane podczas importowania certyfikatu serwera. Dzienniki menedżera kondycji wspominają, że broker MQTT oczekuje na certyfikat serwera.

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.

Uwaga

Ogólnie rzecz biorąc, w systemie rozproszonym dzienniki zasobników nie są deterministyczne i powinny być używane ostrożnie. Właściwym sposobem, aby uzyskać takie informacje, jest użycie zdarzeń platformy Kubernetes i stanu zasobu niestandardowego, które znajduje się na liście prac. Rozważmy poprzedni krok jako tymczasowe obejście.

Mimo że zasobniki frontonu nie są gotowe, zewnętrzny adres IP jest już dostępny.

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

W tym miejscu wykonaj te same kroki co poprzednio, aby utworzyć certyfikat serwera z tym zewnętrznym adresem IP w --san programie i utworzyć wpis tajny Kubernetes w taki sam sposób. Po utworzeniu wpisu tajnego jest on automatycznie importowany do odbiornika.

Udostępnij za pośrednictwem

Zabezpieczanie komunikacji brokera MQTT przy użyciu brokeraListener

Domyślny element BrokerListener

Unikaj modyfikowania domyślnego odbiornika brokera

Tworzenie nowych odbiorników brokera

Przykład: tworzenie nowego odbiornika z dwoma portami

Typ usługi

Tylko jeden odbiornik na typ usługi

Service name

Porty

Używanie tego samego portu między odbiornikami

Obsługa obiektów WebSocket

Konfigurowanie protokołu TLS z automatycznym zarządzaniem certyfikatami

Weryfikowanie instalacji menedżera certyfikatów

Tworzenie wystawcy dla certyfikatu serwera TLS

Konfigurowanie certyfikatu głównego jako wpisu tajnego kubernetes

Dystrybuowanie certyfikatu głównego

Tworzenie wystawcy na podstawie certyfikatu urzędu certyfikacji

Włączanie automatycznego zarządzania certyfikatami TLS dla portu

Opcjonalne: Konfigurowanie parametrów certyfikatu serwera

Weryfikowanie wdrożenia

Nawiązywanie połączenia z brokerem przy użyciu protokołu TLS

Domyślny główny urząd certyfikacji i wystawca

Konfigurowanie protokołu TLS przy użyciu ręcznego zarządzania certyfikatami

Tworzenie urzędu certyfikacji przy użyciu interfejsu wiersza polecenia kroku

Tworzenie certyfikatu serwera

Wymagania dotyczące algorytmu klucza certyfikatu

Importowanie łańcucha certyfikatów serwera jako wpisu tajnego platformy Kubernetes

Włączanie ręcznego zarządzania certyfikatami TLS dla portu

Nawiązywanie połączenia z brokerem przy użyciu protokołu TLS

Użyj zewnętrznego adresu IP dla certyfikatu serwera

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Zabezpieczanie komunikacji brokera MQTT przy użyciu brokeraListener

Domyślny element BrokerListener

Unikaj modyfikowania domyślnego odbiornika brokera

Tworzenie nowych odbiorników brokera

Przykład: tworzenie nowego odbiornika z dwoma portami

Typ usługi

Tylko jeden odbiornik na typ usługi

Service name

Porty

Używanie tego samego portu między odbiornikami

Obsługa obiektów WebSocket

Konfigurowanie protokołu TLS z automatycznym zarządzaniem certyfikatami

Weryfikowanie instalacji menedżera certyfikatów

Tworzenie wystawcy dla certyfikatu serwera TLS

Konfigurowanie certyfikatu głównego jako wpisu tajnego kubernetes

Dystrybuowanie certyfikatu głównego

Tworzenie wystawcy na podstawie certyfikatu urzędu certyfikacji

Włączanie automatycznego zarządzania certyfikatami TLS dla portu

Opcjonalne: Konfigurowanie parametrów certyfikatu serwera

Weryfikowanie wdrożenia

Nawiązywanie połączenia z brokerem przy użyciu protokołu TLS

Domyślny główny urząd certyfikacji i wystawca

Konfigurowanie protokołu TLS przy użyciu ręcznego zarządzania certyfikatami

Tworzenie urzędu certyfikacji przy użyciu interfejsu wiersza polecenia kroku

Tworzenie certyfikatu serwera

Wymagania dotyczące algorytmu klucza certyfikatu

Importowanie łańcucha certyfikatów serwera jako wpisu tajnego platformy Kubernetes

Włączanie ręcznego zarządzania certyfikatami TLS dla portu

Nawiązywanie połączenia z brokerem przy użyciu protokołu TLS

Użyj zewnętrznego adresu IP dla certyfikatu serwera

Powiązana zawartość

Opinia

Dodatkowe zasoby