Konfigurowanie uwierzytelniania usługi Azure IoT MQ w wersji zapoznawczej

Ważne

Usługa Azure IoT Operations Preview — włączona przez usługę Azure Arc jest obecnie dostępna w wersji zapoznawczej. Nie należy używać tego oprogramowania w wersji zapoznawczej w środowiskach 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.

Wersja zapoznawcza usługi Azure IoT MQ obsługuje wiele metod uwierzytelniania dla klientów i można skonfigurować każdy odbiornik tak, aby miał własny system uwierzytelniania przy użyciu zasobów BrokerAuthentication .

Domyślny zasób BrokerAuthentication

Usługa Azure IoT Operations Preview wdraża domyślny zasób BrokerAuthentication o nazwie połączony z odbiornikiem domyślnym o nazwie authnlistener w azure-iot-operations przestrzeni nazw. Jest ona skonfigurowana do używania tylko tokenów kont usługi Kubernetes Service do uwierzytelniania. Aby go sprawdzić, uruchom polecenie:

kubectl get brokerauthentication authn -n azure-iot-operations -o yaml

Dane wyjściowe zawierają domyślny zasób BrokerAuthentication z metadanymi usuniętymi w celu zwięzłości:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: authn
  namespace: azure-iot-operations
spec:
  listenerRef:
    - listener
  authenticationMethods:
    - sat:
        audiences: ["aio-mq"]

Aby zmienić konfigurację, zmodyfikuj authenticationMethods ustawienie w tym zasobie BrokerAuthentication lub utwórz nowy zasób BrokerAuthentication o innej nazwie. Następnie wdróż go przy użyciu polecenia kubectl apply.

Relacja między brokerlistener i brokerAuthentication

BrokerListener i BrokerAuthentication są oddzielnymi zasobami, ale są połączone przy użyciu polecenia listenerRef. Obowiązują następujące zasady:

• BrokerListener może być połączony tylko z jednym brokeremAuthentication
• BrokerAuthentication może być połączony z wieloma elementami BrokerListeners
• Każdy brokerAuthentication może obsługiwać wiele metod uwierzytelniania jednocześnie

Przepływ uwierzytelniania

Kolejność metod uwierzytelniania w tablicy określa, jak usługa Azure IoT MQ uwierzytelnia klientów. Usługa Azure IoT MQ próbuje uwierzytelnić poświadczenia klienta przy użyciu pierwszej określonej metody i iteruje przez tablicę, dopóki nie znajdzie dopasowania lub osiągnie koniec.

Dla każdej metody usługa Azure IoT MQ najpierw sprawdza, czy poświadczenia klienta są istotne dla tej metody. Na przykład uwierzytelnianie SAT wymaga nazwy użytkownika rozpoczynającej się od $sat, a uwierzytelnianie X.509 wymaga certyfikatu klienta. Jeśli poświadczenia klienta są istotne, usługa Azure IoT MQ sprawdza, czy są prawidłowe. Aby uzyskać więcej informacji, zobacz sekcję Konfigurowanie metody uwierzytelniania.

W przypadku uwierzytelniania niestandardowego usługa Azure IoT MQ traktuje błąd komunikacji z niestandardowym serwerem uwierzytelniania, ponieważ poświadczenia nie są istotne. To zachowanie umożliwia usłudze Azure IoT MQ powrót do innych metod, jeśli serwer niestandardowy jest nieosiągalny.

Przepływ uwierzytelniania kończy się po:

• Jeden z tych warunków jest spełniony:
  • Poświadczenia klienta są istotne i prawidłowe dla jednej z metod.
  • Poświadczenia klienta nie są istotne dla żadnej z metod.
  • Poświadczenia klienta są istotne, ale nieprawidłowe dla dowolnej z metod.
• Usługa Azure IoT MQ udziela lub odmawia dostępu do klienta na podstawie wyniku przepływu uwierzytelniania.

W przypadku wielu metod uwierzytelniania usługa Azure IoT MQ ma mechanizm rezerwowy. Na przykład:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata: 
  name: authn
  namespace: azure-iot-operations
spec:
  listenerRef:
    - listener
  authenticationMethods:
    - custom:
        # ...
    - sat:
        # ...
    - usernamePassword:
        # ...

W poprzednim przykładzie określono uwierzytelnianie niestandardowe, sat i hasło użytkownika. Gdy klient nawiązuje połączenie, usługa Azure IoT MQ próbuje uwierzytelnić klienta przy użyciu określonych metod w podanej kolejności niestandardowego > hasła użytkownika SAT>.

1. Usługa Azure IoT MQ sprawdza, czy poświadczenia klienta są prawidłowe w przypadku uwierzytelniania niestandardowego. Ponieważ uwierzytelnianie niestandardowe opiera się na serwerze zewnętrznym w celu określenia ważności poświadczeń, broker uwzględnia wszystkie poświadczenia istotne dla niestandardowego uwierzytelniania i przekazuje je do niestandardowego serwera uwierzytelniania.

2. Jeśli niestandardowy serwer uwierzytelniania odpowiada Pass na wartość lub Fail wynik, przepływ uwierzytelniania kończy się. Jeśli jednak niestandardowy serwer uwierzytelniania nie jest dostępny, usługa Azure IoT MQ powraca do pozostałych określonych metod, a aplikacja SAT jest następna.

3. Usługa Azure IoT MQ próbuje uwierzytelnić poświadczenia jako poświadczenia SAT. Jeśli nazwa użytkownika MQTT zaczyna się od $sat, usługa Azure IoT MQ ocenia hasło MQTT jako sat. W przeciwnym razie broker wraca do nazwy użytkownika i sprawdź, czy podana nazwa użytkownika i hasło MQTT są prawidłowe.

Jeśli niestandardowy serwer uwierzytelniania jest niedostępny, a wszystkie kolejne metody ustaliły, że podane poświadczenia nie są istotne, broker odmawia połączenia klienta.

Wyłączanie uwierzytelniania

Na potrzeby testowania wyłącz uwierzytelnianie, zmieniając je w zasobie BrokerListener.

spec:
  authenticationEnabled: false

Konfigurowanie metody uwierzytelniania

Aby dowiedzieć się więcej o każdej z opcji uwierzytelniania, zobacz następujące sekcje:

Nazwa użytkownika i hasło

Każdy klient ma następujące wymagane właściwości:

• Username
• Hasło (zakodowane w formacie PBKDF2)
• Atrybuty autoryzacji

Na przykład zacznij od elementu clients.toml z tożsamościami i hasłami zakodowanymi w formacie PBKDF2.

# Credential #1
# username: client1
# password: password
[client1]
password = "$pbkdf2-sha512$i=100000,l=64$HqJwOCHweNk1pLryiu3RsA$KVSvxKYcibIG5S5n55RvxKRTdAAfCUtBJoy5IuFzdSZyzkwvUcU+FPawEWFPn+06JyZsndfRTfpiEh+2eSJLkg"

[client1.attributes]
floor = "floor1"
site = "site1"

# Credential #2
# username: client2
# password: password2
[client2]
password = "$pbkdf2-sha512$i=100000,l=64$+H7jXzcEbq2kkyvpxtxePQ$jTzW6fSesiuNRLMIkDDAzBEILk7iyyDZ3rjlEwQap4UJP4TaCR+EXQXNukO7qNJWlPPP8leNnJDCBgX/255Ezw"

[client2.attributes]
floor = "floor2"
site = "site1"

Aby zakodować hasło przy użyciu pbKDF2, użyj rozszerzenia interfejsu az iot ops mq get-password-hash wiersza polecenia operacji usługi Azure IoT, które zawiera polecenie . Generuje skrót hasła PBKDF2 z frazy hasła przy użyciu algorytmu SHA-512 i 128-bitowej soli losowej.

az iot ops mq get-password-hash --phrase TestPassword

Dane wyjściowe zawierają skrót haseł PBKDF2 do skopiowania:

{
  "hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}

Następnie zapisz plik jako passwords.toml i zaimportuj go do wpisu tajnego kubernetes pod tym kluczem.

kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations

Dołącz odwołanie do wpisu tajnego w zasobie niestandardowym BrokerAuthentication

spec:
  authenticationMethods:
    - usernamePassword:
        secretName: passwords-db

Wprowadzenie zmian może potrwać kilka minut.

Za pomocą usługi Azure Key Vault można zarządzać wpisami tajnymi dla usługi Azure IoT MQ zamiast wpisów tajnych platformy Kubernetes. Aby dowiedzieć się więcej, zobacz Zarządzanie wpisami tajnymi przy użyciu usługi Azure Key Vault lub wpisów tajnych platformy Kubernetes.

Certyfikat klienta X.509

Wymagania wstępne

• Usługa Azure IoT MQ skonfigurowana z włączonym protokołem TLS.
• Interfejs wiersza polecenia kroków
• Certyfikaty klienta i łańcuch certyfikatów wystawiających certyfikaty w plikach PEM. Jeśli nie masz żadnych, użyj interfejsu wiersza polecenia kroku, aby wygenerować niektóre.
• Znajomość kryptografii klucza publicznego i terminów, takich jak główny urząd certyfikacji, klucz prywatny i certyfikaty pośrednie.

Obsługiwane są zarówno klucze EC, jak i RSA, ale wszystkie certyfikaty w łańcuchu muszą używać tego samego algorytmu klucza. Jeśli importujesz własne certyfikaty urzędu certyfikacji, upewnij się, że certyfikat klienta używa tego samego algorytmu klucza co urzędy certyfikacji.

Importowanie certyfikatu zaufanego głównego urzędu certyfikacji klienta

Aby zweryfikować certyfikat klienta, wymagany jest zaufany certyfikat głównego urzędu certyfikacji. Aby zaimportować certyfikat główny, który może służyć do weryfikowania certyfikatów klienta, najpierw zaimportuj certyfikat PEM jako ConfigMap pod kluczem client_ca.pem. Aby można było je uwierzytelnić, certyfikaty klienta muszą być zakorzenione w tym urzędzie certyfikacji dla usługi Azure IoT MQ.

kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations

Aby sprawdzić, czy certyfikat głównego urzędu certyfikacji został prawidłowo zaimportowany, uruchom polecenie kubectl describe configmap. Wynik przedstawia to samo kodowanie base64 pliku certyfikatu PEM.

$ kubectl describe configmap client-ca -n azure-iot-operations
Name:         client-ca
Namespace:    azure-iot-operations

Data
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----


BinaryData
====

Importowanie mapowania certyfikatu na atrybut

Aby użyć zasad autoryzacji dla klientów używających właściwości certyfikatów X.509, utwórz plik TOML mapowania certyfikatu na atrybut i zaimportuj go jako wpis tajny Kubernetes w kluczu x509Attributes.toml. Ten plik mapuje nazwę podmiotu certyfikatu klienta na atrybuty, które mogą być używane w zasadach autoryzacji. Jest to wymagane, nawet jeśli nie używasz zasad autoryzacji.

kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations

Aby dowiedzieć się więcej o składni pliku atrybutów, zobacz Autoryzowanie klientów korzystających z uwierzytelniania X.509.

Podobnie jak w przypadku uwierzytelniania za pomocą nazwy użytkownika i hasła, możesz użyć usługi Azure Key Vault do zarządzania tym wpisem tajnym zamiast wpisów tajnych platformy Kubernetes. Aby dowiedzieć się więcej, zobacz Zarządzanie wpisami tajnymi przy użyciu usługi Azure Key Vault lub wpisów tajnych platformy Kubernetes.

Włączanie uwierzytelniania klienta X.509

Na koniec po zaimportowaniu zaufanego certyfikatu głównego urzędu certyfikacji i mapowania certyfikatu na atrybut włącz uwierzytelnianie klienta X.509, dodając x509 jako jedną z metod uwierzytelniania w ramach zasobu BrokerAuthentication połączonego z odbiornikiem obsługującym protokół TLS. Na przykład:

spec:
  authenticationMethods:
    - x509:
        trustedClientCaCert: client-ca
        attributes:
          secretName: x509-attributes

Połączenie mosquitto client to Azure IoT MQ Preview with X.509 client certificate (wersja zapoznawcza usługi Azure IoT MQ z certyfikatem klienta X.509)

Klient, taki jak mosquitto, potrzebuje trzech plików, aby móc nawiązać połączenie z usługą Azure IoT MQ przy użyciu uwierzytelniania klienta TLS i X.509. Na przykład:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem

W przykładzie:

• Parametr --cert określa plik PEM certyfikatu klienta.
• Parametr --key określa plik PEM klucza prywatnego klienta.
• Trzeci parametr --cafile jest najbardziej złożony: zaufana baza danych certyfikatów używana do dwóch celów:
  • Gdy klient mosquitto łączy się z usługą Azure IoT MQ za pośrednictwem protokołu TLS, weryfikuje certyfikat serwera. Wyszukuje certyfikaty główne w bazie danych, aby utworzyć zaufany łańcuch certyfikatu serwera. W związku z tym należy skopiować certyfikat główny serwera do tego pliku.
  • Gdy usługa Azure IoT MQ żąda certyfikatu klienta z klienta mosquitto, wymaga również prawidłowego łańcucha certyfikatów do wysłania na serwer. Parametr --cert informuje mosquitto, który certyfikat ma być wysyłany, ale nie wystarczy. Usługa Azure IoT MQ nie może zweryfikować tego certyfikatu, ponieważ wymaga również certyfikatu pośredniego. Mosquitto używa pliku bazy danych do utworzenia niezbędnego łańcucha certyfikatów. Aby to umożliwić, cafile musi zawierać zarówno certyfikaty pośrednie, jak i główne.

Omówienie przepływu uwierzytelniania klienta X.509 w wersji zapoznawczej usługi Azure IoT MQ

Poniżej przedstawiono kroki przepływu uwierzytelniania klienta:

1. Po włączeniu uwierzytelniania klienta X.509 łączenie klientów musi przedstawić certyfikat klienta i wszystkie certyfikaty pośrednie, aby umożliwić usłudze Azure IoT MQ utworzenie łańcucha certyfikatów rooted do jednego ze skonfigurowanych zaufanych certyfikatów.
2. Moduł równoważenia obciążenia kieruje komunikację z jednym z brokerów frontonu.
3. Gdy broker frontonu odebrał certyfikat klienta, próbuje utworzyć łańcuch certyfikatów, który jest zakorzeniony w jednym ze skonfigurowanych certyfikatów. Certyfikat jest wymagany do uzgadniania protokołu TLS. Jeśli broker frontonu pomyślnie skompilował łańcuch, a przedstawiony łańcuch zostanie zweryfikowany, zakończy uzgadnianie protokołu TLS. Klient łączący może wysyłać pakiety MQTT do frontonu za pośrednictwem wbudowanego kanału TLS.
4. Kanał TLS jest otwarty, ale uwierzytelnianie lub autoryzacja klienta nie zostało jeszcze zakończone.
5. Następnie klient wysyła pakiet CONNECT do usługi Azure IoT MQ.
6. Pakiet CONNECT jest ponownie kierowany do frontonu.
7. Fronton zbiera wszystkie poświadczenia przedstawione do tej pory przez klienta, takie jak pola nazwy użytkownika i hasła, dane uwierzytelniania z pakietu CONNECT oraz łańcuch certyfikatów klienta przedstawiony podczas uzgadniania protokołu TLS.
8. Fronton wysyła te poświadczenia do usługi uwierzytelniania. Usługa uwierzytelniania ponownie sprawdza łańcuch certyfikatów i zbiera nazwy podmiotów wszystkich certyfikatów w łańcuchu.
9. Usługa uwierzytelniania używa skonfigurowanych reguł autoryzacji, aby określić, jakie atrybuty ma łączących się klientów. Te atrybuty określają, jakie operacje może wykonać klient, w tym sam pakiet CONNECT.
10. Usługa uwierzytelniania zwraca decyzję o brokerze frontonu.
11. Broker frontonu zna atrybuty klienta i czy może nawiązać połączenie. Jeśli tak, połączenie MQTT zostanie ukończone, a klient będzie mógł nadal wysyłać i odbierać pakiety MQTT określone przez reguły autoryzacji.

Tokeny konta usługi Kubernetes Service

Tokeny konta usługi Kubernetes Service to tokeny internetowe JSON skojarzone z kontami usługi Kubernetes. Klienci przedstawiają usługi SATs brokerowi MQTT usługi Azure IoT MQTT w celu uwierzytelnienia się.

Usługa Azure IoT MQ używa powiązanych tokenów konta usługi, które zostały szczegółowo opisane w wpisie Co użytkownicy GKE muszą wiedzieć o nowych tokenach konta usługi Kubernetes. Oto ważne funkcje z wpisu:

Uruchomiony na platformie Kubernetes 1.13 i staje się domyślnym formatem w wersji 1.21, powiązany tokeny dotyczą wszystkich ograniczonych funkcji starszych tokenów i nie tylko:

• Same tokeny są trudniejsze do kradzieży i nieprawidłowego użycia; są one powiązane czasowo, powiązane z odbiorcami i powiązane z obiektem.
• Przyjmują standardowy format: OpenID Połączenie (OIDC), z pełnym odnajdywaniem OIDC, co ułatwia dostawcom usług akceptowanie ich.
• Są one bezpiecznie dystrybuowane do zasobników przy użyciu nowego typu woluminu przewidywanego przez kubelet.

Broker weryfikuje tokeny przy użyciu interfejsu API przeglądu tokenu platformy Kubernetes. Włącz funkcję Kubernetes TokenRequestProjection , aby określić audiences (wartość domyślna od wersji 1.21). Jeśli ta funkcja nie jest włączona, nie można jej używać.

Tworzenie konta usługowego

Aby utworzyć konta usługi, najpierw utwórz konto usługi. Następujące polecenie tworzy konto usługi o nazwie mqtt-client.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

Dodawanie atrybutów autoryzacji

Uwierzytelnianie klientów za pośrednictwem sat może opcjonalnie mieć ich ATS adnotacje z atrybutami, które mają być używane z niestandardowymi zasadami autoryzacji. Aby dowiedzieć się więcej, zobacz Autoryzowanie klientów korzystających z tokenów konta usługi Kubernetes Service.

Włączanie uwierzytelniania tokenu konta usługi (SAT)

Zmodyfikuj authenticationMethods ustawienie w zasobie BrokerAuthentication, aby określić sat jako prawidłową metodę uwierzytelniania. Określa audiences listę prawidłowych odbiorców tokenów. Wybierz unikatowe wartości identyfikujące usługę brokera usługi brokera usługi Azure IoT MQ. Musisz określić co najmniej jedną grupę odbiorców, a wszystkie grupy Zabezpieczeń muszą być zgodne z jedną z określonych grup odbiorców.

spec:
  authenticationMethods:
    - sat:
        audiences: ["aio-mq", "my-audience"]

Zastosuj zmiany za pomocą polecenia kubectl apply. Wprowadzenie zmian może potrwać kilka minut.

Testowanie uwierzytelniania SAT

Uwierzytelnianie SAT musi być używane z klienta w tym samym klastrze co usługa Azure IoT MQ. Następujące polecenie określa zasobnik, który ma klienta mosquitto i instaluje sat utworzone w poprzednich krokach do zasobnika.

apiVersion: v1
kind: Pod
metadata:
  name: mqtt-client
  namespace: azure-iot-operations
spec:
  serviceAccountName: mqtt-client
  containers:
  - image: efrecon/mqtt-client
    name: mqtt-client
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: mqtt-client-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: mqtt-client-token
    projected:
      sources:
      - serviceAccountToken:
          path: mqtt-client-token
          audience: my-audience
          expirationSeconds: 86400

serviceAccountName W tym miejscu pole w konfiguracji zasobnika musi być zgodne z kontem usługi skojarzonym z używanym tokenem. serviceAccountToken.audience Ponadto pole w konfiguracji zasobnika musi być jednym ze skonfigurowanych audiences w zasobie BrokerAuthentication.

Po utworzeniu zasobnika uruchom powłokę w zasobniku:

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

Token jest instalowany w ścieżce określonej w konfiguracji /var/run/secrets/tokens w poprzednim przykładzie. Pobierz token i użyj go do uwierzytelnienia.

token=$(cat /var/run/secrets/tokens/mqtt-client-token)

mosquitto_pub -h aio-mq-dmqtt-frontend -V mqttv5 -t hello -m world -u '$sat' -P "$token"

Nazwa użytkownika MQTT musi być ustawiona na $sat. Hasło MQTT musi być ustawione na sam sat.

Odświeżanie tokenów konta usługi

Tokeny konta usługi są ważne przez ograniczony czas i skonfigurowane za pomocą polecenia expirationSeconds. Jednak platforma Kubernetes automatycznie odświeża token przed jego wygaśnięciem. Token jest odświeżany w tle, a klient nie musi wykonywać żadnych czynności innych niż pobieranie go ponownie.

Jeśli na przykład klient jest zasobnikiem, który używa tokenu zainstalowanego jako wolumin, podobnie jak w przykładzie testowego uwierzytelniania SAT, najnowszy token jest dostępny w tej samej ścieżce /var/run/secrets/tokens/mqtt-client-token. Podczas nawiązywania nowego połączenia klient może pobrać najnowszy token i użyć go do uwierzytelniania. Klient powinien również mieć mechanizm obsługi nieautoryzowanych błędów MQTT przez pobranie najnowszego tokenu i ponowienie próby połączenia.

Uwierzytelnianie niestandardowe

Rozszerzanie uwierzytelniania klienta poza podane metody uwierzytelniania przy użyciu uwierzytelniania niestandardowego. Jest ona podłączona , ponieważ usługa może być niczym, o ile jest zgodna z interfejsem API.

Gdy klient łączy się z usługą Azure IoT MQ i jest włączone uwierzytelnianie niestandardowe, usługa Azure IoT MQ deleguje weryfikację poświadczeń klienta do niestandardowego serwera uwierzytelniania z żądaniem HTTP wraz ze wszystkimi poświadczeniami prezentowanymi przez klienta. Niestandardowy serwer uwierzytelniania odpowiada za zgodą lub odmową dla klienta przy użyciu atrybutów klienta na potrzeby autoryzacji.

Tworzenie niestandardowej usługi uwierzytelniania

Niestandardowy serwer uwierzytelniania jest implementowany i wdrażany oddzielnie od usługi Azure IoT MQ.

Przykładowy niestandardowy serwer uwierzytelniania i instrukcje są dostępne w witrynie GitHub. Użyj tego przykładu jako szablonu i punktu wyjścia do implementowania własnej niestandardowej logiki uwierzytelniania.

interfejs API

Interfejs API między usługą Azure IoT MQ i niestandardowym serwerem uwierzytelniania jest zgodne ze specyfikacją interfejsu API na potrzeby uwierzytelniania niestandardowego. Specyfikacja interfejsu OpenAPI jest dostępna w witrynie GitHub.

Protokół HTTPS z szyfrowaniem TLS jest wymagany

Usługa Azure IoT MQ wysyła żądania zawierające poufne poświadczenia klienta do niestandardowego serwera uwierzytelniania. Aby chronić te poświadczenia, komunikacja między usługą Azure IoT MQ i niestandardowym serwerem uwierzytelniania musi być szyfrowana przy użyciu protokołu TLS.

Niestandardowy serwer uwierzytelniania musi przedstawić certyfikat serwera, a usługa Azure IoT MQ musi mieć zaufany certyfikat głównego urzędu certyfikacji do weryfikacji certyfikatu serwera. Opcjonalnie niestandardowy serwer uwierzytelniania może wymagać, aby usługa Azure IoT MQ prezentowała certyfikat klienta w celu uwierzytelnienia się.

Włączanie uwierzytelniania niestandardowego dla odbiornika

Zmodyfikuj authenticationMethods ustawienie w zasobie BrokerAuthentication, aby określić custom jako prawidłową metodę uwierzytelniania. Następnie określ parametry wymagane do komunikowania się z niestandardowym serwerem uwierzytelniania.

W tym przykładzie przedstawiono wszystkie możliwe parametry. Dokładne wymagane parametry zależą od wymagań poszczególnych serwerów niestandardowych.

spec:
  authenticationMethods:
    - custom:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Trusted CA certificate for validating custom authentication server certificate.
        # Required unless the server certificate is publicly-rooted.
        caCert: custom-auth-ca
        # Authentication between Azure IoT MQ with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretName: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Powiązana zawartość

• Informacje o zasobie BrokerListener
• Konfigurowanie autoryzacji dla elementu BrokerListener
• Konfigurowanie protokołu TLS przy użyciu ręcznego zarządzania certyfikatami
• Konfigurowanie protokołu TLS z automatycznym zarządzaniem certyfikatami