Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 dla wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta, wersji zapoznawczej lub w inny sposób nie zostały jeszcze wydane w wersji ogólnodostępnej.
Broker MQTT obsługuje wiele metod uwierzytelniania dla klientów. Każdy port odbiornika można skonfigurować tak, aby miał własne ustawienia uwierzytelniania za pomocą zasobu BrokerAuthentication. Aby uzyskać listę dostępnych ustawień, zobacz dokumentację API Uwierzytelnianie brokera.
Link BrokerListener i BrokerAuthentication
Następujące reguły dotyczą relacji między zasobami BrokerListener i BrokerAuthentication:
- Każdy zasób BrokerListener może mieć wiele portów. Każdy port można połączyć z zasobem BrokerAuthentication.
- Każdy zasób BrokerAuthentication może obsługiwać wiele metod uwierzytelniania jednocześnie.
- Porty, które nie łączą zasobu BrokerAuthentication, mają wyłączone uwierzytelnianie.
Aby połączyć port BrokerListener z zasobem BrokerAuthentication, określ authenticationRef pole w ports ustawieniu zasobu BrokerListener. Aby dowiedzieć się więcej, zobacz Zasób BrokerListener.
Domyślny zasób BrokerAuthentication
Operacje Azure IoT wdrażają domyślny zasób BrokerAuthentication o nazwie default, związany z odbiornikiem domyślnym w przestrzeni nazw azure-iot-operations. Do uwierzytelniania używane są tylko tokeny kont usługi Kubernetes (SATs).
Ważne
Metoda uwierzytelniania SAT w domyślnym zasobie BrokerAuthentication jest wymagana, aby składniki w operacjach IoT działały poprawnie. Unikaj aktualizowania lub usuwania domyślnego zasobu BrokerAuthentication.
W portalu Azure przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Wybierz kartę Uwierzytelnianie .
Z listy zasad uwierzytelniania wybierz domyślną nazwę zasad.
Aby dodać nowe metody uwierzytelniania, wybierz pozycję Dodaj metodę.
Przepływ uwierzytelniania
Kolejność określonych metod uwierzytelniania określa, w jaki sposób broker MQTT uwierzytelnia klientów. Broker MQTT próbuje uwierzytelnić poświadczenia klienta przy użyciu pierwszej określonej metody i przechodzi przez kolejne metody, dopóki nie znajdzie pasującej metody lub nie osiągnie końca.
Dla każdej metody broker MQTT najpierw sprawdza, czy poświadczenia klienta są istotne dla tej metody. Na przykład uwierzytelnianie SAT wymaga nazwy użytkownika rozpoczynającej się od K8S-SAT, a uwierzytelnianie X.509 wymaga certyfikatu klienta. Jeśli poświadczenia klienta są istotne, broker MQTT sprawdza, czy są prawidłowe. Aby uzyskać więcej informacji, zobacz sekcję Konfigurowanie metody uwierzytelniania .
W przypadku uwierzytelniania niestandardowego broker MQTT traktuje błąd komunikacji z niestandardowym serwerem uwierzytelniania jako poświadczenia nieistotne. To zachowanie umożliwia brokerowi MQTT przełączenie się na inne metody w przypadku, gdy niestandardowy serwer uwierzytelniania jest niedostępny.
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.
- Broker MQTT udziela lub odmawia dostępu do klienta na podstawie wyniku przepływu uwierzytelniania.
Przykład:
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
Wcześniejszy przykład określa wartość custom i SAT. Gdy klient nawiązuje połączenie, broker MQTT próbuje uwierzytelnić klienta przy użyciu określonych metod w kolejności custom , a następnie SAT.
- Broker MQTT 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.
- Jeśli niestandardowy serwer uwierzytelniania odpowiada z wynikiem
PasslubFail, przepływ uwierzytelniania kończy się. Jeśli niestandardowy serwer uwierzytelniania jest niedostępny, broker MQTT wraca do pozostałych określonych metod, z SAT jako kolejną opcją. - Broker MQTT próbuje uwierzytelnić poświadczenia jako poświadczenia SAT.
Jeśli niestandardowy serwer uwierzytelniania jest niedostępny, a wszystkie kolejne metody określają, że podane poświadczenia nie są istotne, broker odmawia połączenia klienta.
Konfigurowanie metody uwierzytelniania
Możesz dodać metody uwierzytelniania, takie jak X.509, SAT lub niestandardowe, do zasad uwierzytelniania.
Aby dodać metodę uwierzytelniania do zasad:
W portalu Azure przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Wybierz kartę Uwierzytelnianie .
Wybierz istniejące zasady uwierzytelniania lub utwórz nowe.
Dodaj nową metodę, wybierając pozycję Dodaj metodę.
Wybierz typ metody z listy rozwijanej, a następnie wybierz pozycję Dodaj szczegóły , aby skonfigurować metodę.
Aby dowiedzieć się więcej o każdej z opcji uwierzytelniania, zobacz następne sekcje dla każdej metody.
Aby uzyskać więcej informacji na temat włączania bezpiecznych ustawień, konfigurując wystąpienie usługi Azure Key Vault i włączając tożsamości obciążeń, zobacz Włączanie bezpiecznych ustawień we wdrożeniu operacji usługi Azure IoT.
Zobacz materiał X.509
Wskazówka
Aby zapoznać się z kompleksowego przykładu konfigurowania uwierzytelniania X.509, zobacz Samouczek: uwierzytelnianie klienta protokołu TLS, X.509 i autoryzacja kontroli dostępu opartej na atrybutach (ABAC).
W przypadku uwierzytelniania X.509 broker MQTT używa zaufanego certyfikatu urzędu certyfikacji do sprawdzania poprawności certyfikatów klienta. Ten zaufany urząd certyfikacji może być głównym lub pośrednim urzędem certyfikacji. Broker sprawdza łańcuch certyfikatów klienta względem zaufanego certyfikatu urzędu certyfikacji. Jeśli łańcuch jest prawidłowy, klient jest uwierzytelniany.
Aby użyć uwierzytelniania X.509 z zaufanym certyfikatem urzędu certyfikacji, należy spełnić następujące wymagania:
- Protokół Transport Layer Security (TLS): Ponieważ protokół X.509 opiera się na certyfikatach klienta TLS, protokół TLS musi być włączony dla portów przy użyciu uwierzytelniania X.509.
- Algorytmy kluczy: klucze EC i RSA są obsługiwane, ale wszystkie certyfikaty w łańcuchu muszą używać tego samego algorytmu klucza.
- Format: certyfikat urzędu certyfikacji musi być w formacie Privacy-Enhanced Mail (PEM).
Wskazówka
Format PEM jest typowym formatem certyfikatów i kluczy. Pliki PEM to pliki ASCII zakodowane w formacie Base64 z nagłówkami takimi jak -----BEGIN CERTIFICATE----- i -----BEGIN EC PRIVATE KEY-----.
Jeśli masz certyfikat w innym formacie, możesz przekonwertować go na PEM przy użyciu protokołu OpenSSL. Aby uzyskać więcej informacji, zobacz Konwertowanie certyfikatu na odpowiedni format.
Uzyskaj zaufany certyfikat CA
W środowisku produkcyjnym certyfikat CA jest zapewniany przez infrastrukturę kluczy publicznych organizacji (PKI) lub publiczny urząd certyfikacji.
Na potrzeby testowania utwórz certyfikat urzędu certyfikacji z podpisem własnym za pomocą protokołu OpenSSL. Na przykład uruchom następujące polecenie, aby wygenerować certyfikat CA z podpisem własnym, z kluczem RSA, nazwą wyróżniającą CN=Contoso Root CA Cert i ważnością 365 dni:
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
To samo polecenie przy użyciu Step CLI, który jest wygodnym narzędziem do zarządzania certyfikatami, brzmi:
step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
--not-after 8760h
Te polecenia tworzą certyfikat urzędu certyfikacji, ca.pemi klucz prywatny, ca-key.pemw formacie PEM. Certyfikat CA ca.pem można zaimportować do brokera MQTT na potrzeby uwierzytelniania X.509.
Zaimportuj zaufany certyfikat urzędu certyfikacji
Aby rozpocząć uwierzytelnianie przy użyciu X.509, zaimportuj zaufany certyfikat urzędu certyfikacji do obiektu ConfigMap w azure-iot-operations przestrzeni nazw. Aby zaimportować zaufany certyfikat ca.pem urzędu certyfikacji do obiektu ConfigMap o nazwie client-ca, uruchom polecenie:
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
W tym przykładzie certyfikat urzędu certyfikacji jest importowany pod kluczem ca.pem. Broker MQTT ufa wszystkim certyfikatom urzędu certyfikacji w ConfigMap, dzięki czemu można użyć dowolnej nazwy dla klucza.
Aby sprawdzić, czy certyfikat głównego urzędu certyfikacji został prawidłowo zaimportowany, uruchom polecenie kubectl describe configmap. Wynik pokazuje to samo kodowanie Base64 pliku certyfikatu PEM.
kubectl describe configmap client-ca -n azure-iot-operations
Name: client-ca
Namespace: azure-iot-operations
Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----
BinaryData
====
Konfigurowanie metody uwierzytelniania X.509
Po zaimportowaniu zaufanego certyfikatu urzędu certyfikacji włącz uwierzytelnianie klienta X.509, dodając go jako metodę uwierzytelniania w zasobie BrokerAuthentication. Upewnij się, że ten zasób jest połączony z portem odbiornika z obsługą protokołu TLS.
W portalu Azure przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Wybierz kartę Uwierzytelnianie .
Wybierz istniejące zasady uwierzytelniania lub utwórz nowe.
Dodaj nową metodę, wybierając pozycję Dodaj metodę.
Wybierz typ metody X.509 z listy rozwijanej. Następnie wybierz pozycję Dodaj szczegóły , aby skonfigurować metodę.
Na panelu szczegóły uwierzytelniania X.509 określ nazwę ConfigMap zaufanego certyfikatu CA, używając formatu JSON.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Zastąp
<TRUSTED_CA_CONFIGMAP>nazwą ConfigMap, która zawiera certyfikat zaufanej jednostki certyfikującej. Użyj na przykład nazwy"trustedClientCaCert": "client-ca".
Opcjonalnie dodaj atrybuty autoryzacji dla klientów przy użyciu certyfikatów X.509. Aby dowiedzieć się więcej, zobacz Atrybuty certyfikatu na potrzeby autoryzacji.
Wybierz Zastosuj, aby zapisać zmiany.
Opcjonalne: atrybuty certyfikatu na potrzeby autoryzacji
Atrybuty X.509 można określić w zasobie BrokerAuthentication na potrzeby autoryzowania klientów na podstawie ich właściwości certyfikatu. Atrybuty są zdefiniowane w authorizationAttributes polu.
Przykład:
W witrynie Azure Portal podczas konfigurowania metody uwierzytelniania X.509 dodaj atrybuty autoryzacji w okienku szczegółów uwierzytelniania X.509 w formacie JSON.
{
"trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
"authorizationAttributes": {
"root": {
"subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
"attributes": {
"organization": "contoso"
}
},
"intermediate": {
"subject": "CN = Contoso Intermediate CA",
"attributes": {
"city": "seattle",
"foo": "bar"
}
},
"smartfan": {
"subject": "CN = smart-fan",
"attributes": {
"building": "17"
}
}
}
}
W tym przykładzie każdy klient z certyfikatem wystawionym przez główny urząd certyfikacji o nazwie wyróżniającej CN = Contoso Root CA Cert, OU = Engineering, C = US lub pośredni urząd certyfikacji o nazwie wyróżniającej CN = Contoso Intermediate CA otrzymuje wymienione atrybuty. Ponadto certyfikat klienta smart-fan otrzymuje atrybuty specyficzne dla niego.
Dopasowanie atrybutów zawsze rozpoczyna się od certyfikatu klienta liścia, a następnie przechodzi wzdłuż łańcucha. Przypisanie atrybutu zostaje zatrzymane po pierwszym dopasowaniu. W poprzednim przykładzie, nawet jeśli smart-fan ma certyfikat CN = Contoso Intermediate CApośredni , nie pobiera skojarzonych atrybutów.
Reguły autoryzacji można stosować do klientów przy użyciu certyfikatów X.509 z tymi atrybutami. Aby dowiedzieć się więcej, zobacz Autoryzowanie klientów korzystających z uwierzytelniania X.509.
Opcjonalnie: integracja usługi Azure Device Registry z uwierzytelnianiem X.509 (wersja zapoznawcza)
Ważne
Integracja usługi Azure Device Registry z uwierzytelnianiem X.509 jest obecnie dostępna w wersji zapoznawczej. Ta funkcja podlega pewnym ograniczeniom i nie jest zalecana w przypadku obciążeń produkcyjnych. Aby uzyskać więcej informacji, zobacz Warunki dodatkowe korzystania z testowych wersji Microsoft Azure.
Integrację usługi Azure Device Registry z uwierzytelnianiem X.509 można włączyć, aby wymusić weryfikację i odwołanie certyfikatu na poziomie urządzenia. Po włączeniu tej funkcji klienci X.509 muszą mieć zgodne urządzenia w rejestrze urządzeń i umożliwia wyłączenie klientów przez wyłączenie odpowiedniego urządzenia.
Po włączeniu integracji z usługą Azure Device Registry:
- Certyfikaty klienta muszą mieć nazwę pospolitą zgodną z nazwą urządzenia w rejestrze urządzeń platformy Azure.
- Tylko włączone urządzenia w rejestrze mogą pomyślnie uwierzytelniać.
- Stan urządzenia jest sprawdzany po uwierzytelnieniu klienta i co 10 minut później.
- Wyłączone lub usunięte urządzenia są automatycznie blokowane.
Przed włączeniem tej funkcji utwórz odpowiednie urządzenie w rejestrze urządzeń platformy Azure dla każdego certyfikatu klienta. Nazwa urządzenia musi być zgodna z nazwą pospolitą certyfikatu (CN). Aby utworzyć urządzenia i zarządzać nimi w usłudze Azure Device Registry, zobacz:
- Używanie środowiska operacji do zarządzania zasobami, takimi jak zasoby, urządzenia i przepływy danych
- Informacje o zasobach i urządzeniach
Aby włączyć integrację usługi Azure Device Registry, ustaw additionalValidation pole na AzureDeviceRegistry w ustawieniach X.509. Pole additionalValidation wykonuje dodatkową walidację certyfikatu klienta przy użyciu określonej metody z obsługiwanymi wartościami AzureDeviceRegistry lub None (ustawienie domyślne):
W witrynie Azure Portal podczas konfigurowania metody uwierzytelniania X.509 dodaj walidację usługi Azure Device Registry w okienku szczegółów uwierzytelniania X.509 w formacie JSON:
{
"trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
"additionalValidation": "AzureDeviceRegistry"
}
Po włączeniu integracji usługi Azure Device Registry utwórz odpowiednie urządzenie w rejestrze urządzeń platformy Azure dla każdego certyfikatu klienta. Nazwa urządzenia musi być zgodna z nazwą pospolitą certyfikatu (CN). Jeśli klient spróbuje uwierzytelnić się przy użyciu certyfikatu, który nie ma pasującego urządzenia włączonego w rejestrze, uwierzytelnianie zakończy się niepowodzeniem.
Włączanie uwierzytelniania X.509 dla portu odbiornika
Po zaimportowaniu zaufanego certyfikatu urzędu certyfikacji i skonfigurowaniu zasobu BrokerAuthentication połącz go z portem odbiornika z obsługą protokołu TLS. Ten krok jest ważny, ponieważ uwierzytelnianie X.509 opiera się na protokole TLS na potrzeby weryfikacji certyfikatu klienta.
Aby uzyskać port odbiornika z obsługą protokołu TLS, zobacz Włączanie ręcznego zarządzania certyfikatami TLS dla portu i Włączanie automatycznego zarządzania certyfikatami TLS dla portu.
Uwaga / Notatka
Włączenie protokołu TLS na porcie odbiornika brokera oznacza, że broker używa certyfikatu serwera do szyfrowania TLS. Kiedy klienci łączą się z tym portem, muszą ufać certyfikatowi serwera, mając w swoim magazynie zaufania certyfikat urzędu certyfikacji, który go podpisał. Ten proces jest nazywany dystrybucją zaufania lub tworzeniem pakietów zaufania. Ważne jest, aby zrozumieć różnicę między weryfikacją klienta a weryfikacją serwera:
-
Weryfikacja klienta: broker MQTT (serwer) sprawdza certyfikat klienta względem certyfikatu urzędu certyfikacji, określonego jako zaufany, w polu
trustedClientCaCertdla uwierzytelniania klienta X.509. -
Weryfikacja serwera: klienci (na przykład Mosquitto lub MQTTX) sprawdzają certyfikat serwera brokera MQTT względem zaufanego certyfikatu urzędu certyfikacji w repozytorium zaufanych certyfikatów. W przypadku klientów Mosquitto użyj parametru
--cafile, aby określić plik certyfikatu urzędu certyfikacji. W przypadku MQTTX dodaj certyfikat urzędu certyfikacji do magazynu zaufania w ustawieniach.
Po włączeniu uwierzytelniania X.509 upewnij się, że klienci ufają certyfikatowi serwera brokera, mając certyfikat CA po stronie serwera w swoim magazynie zaufania. Nie należy mylić zaufania do certyfikatu urzędu certyfikacji po stronie serwera z certyfikatem urzędu certyfikacji po stronie klienta, który jest używany do uwierzytelniania klienta i określony w polu trustedClientCaCert.
Pełny przykład można znaleźć w samouczku: TLS, uwierzytelnianie klienta X.509 i autoryzacja kontroli dostępu opartej na atrybutach (ABAC).
Łączenie klienta Mosquitto z brokerem MQTT przy użyciu certyfikatu klienta X.509
Klient, taki jak Mosquitto, potrzebuje dwóch plików, aby móc nawiązać połączenie z brokerem MQTT przy użyciu uwierzytelniania klienta TLS i X.509:
- Parametr
--certokreśla plik PEM certyfikatu klienta. Ten plik powinien również zawierać wszystkie certyfikaty pośrednie, aby ułatwić brokerowi MQTT utworzenie kompletnego łańcucha certyfikatów. - Parametr
--keyokreśla plik PEM klucza prywatnego klienta.
W przypadkach, gdy broker MQTT używa certyfikatu urzędu certyfikacji z podpisem własnym do wystawiania certyfikatu serwera TLS, parametr --cafile jest wymagany. Ten plik zawiera certyfikat urzędu certyfikacji (znany również jako pakiet zaufania), którego klient Mosquitto używa do sprawdzania poprawności certyfikatu serwera brokera podczas nawiązywania połączenia za pośrednictwem protokołu TLS. Jeśli wystawca certyfikatu serwera brokera MQTT jest częścią głównej pamięci systemowej (na przykład znanych publicznych organizacji certyfikujących), parametr --cafile można pominąć.
Przykład:
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem
Omówienie przepływu uwierzytelniania klienta X.509 brokera MQTT
Wykonaj następujące kroki na potrzeby uwierzytelniania klienta:
- Po włączeniu uwierzytelniania klienta X.509 klienci, którzy się łączą, muszą przedstawić certyfikat klienta i wszystkie certyfikaty pośrednie, aby umożliwić brokerowi MQTT zbudowanie łańcucha certyfikatów zakorzenionego w jednym z jego skonfigurowanych zaufanych certyfikatów.
- Moduł równoważenia obciążenia kieruje komunikację do jednego z brokerów frontowych.
- Po tym, jak broker frontendowy otrzymuje certyfikat klienta, próbuje zbudować łańcuch certyfikatów, który jest zakotwiczony w jednym ze skonfigurowanych certyfikatów. Jeśli broker frontowy pomyślnie zbuduje łańcuch, a przedstawiony łańcuch zostanie zweryfikowany, zakończy uzgadnianie TLS. Klient łączący może wysyłać pakiety MQTT do frontonu za pośrednictwem kanału TLS.
- Kanał TLS jest otwarty, ale uwierzytelnianie lub autoryzacja klienta nie zostało jeszcze zakończone.
- Następnie klient wysyła pakiet CONNECT do brokera MQTT.
- Pakiet CONNECT jest ponownie przekierowywany do frontendu.
- Fronton zbiera wszystkie poświadczenia przedstawione do tej pory przez klienta, takie jak dane uwierzytelniania z pakietu CONNECT, oraz łańcuch certyfikatów klienta przedstawiony podczas uzgadniania protokołu TLS.
- 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.
- Usługa uwierzytelniania używa skonfigurowanych reguł autoryzacji , aby określić, jakie atrybuty mają łączących się klientów. Te atrybuty określają, jakie operacje może uruchomić klient, w tym sam pakiet CONNECT.
- Usługa uwierzytelniania zwraca decyzję do pośrednika frontendowego.
- Broker frontendowy zna atrybuty klienta i wie, czy może nawiązać połączenie. Jeśli tak, połączenie MQTT zostanie ukończone, a klient może nadal wysyłać i odbierać pakiety MQTT zgodnie z regułami autoryzacji.
Tokeny konta usługi Kubernetes
Tokeny SAT Kubernetes to tokeny sieciowe JSON skojarzone z kontami usług Kubernetes. Klienci przedstawiają tokeny SAT brokerowi MQTT w celu uwierzytelnienia się.
Broker MQTT używa tokenów powiązanego konta usługi, które są opisane we wpisie Co użytkownicy GKE muszą wiedzieć o nowych tokenach kont usługi Kubernetes. Oto główne funkcje wpisu:
Powiązane tokeny uruchomione na platformie Kubernetes 1.13 i stały się formatem domyślnym w wersji 1.21. Powiązane tokeny rozwiązują wszystkie ograniczenia funkcjonalne przestarzałych tokenów, a także oferują dodatkowe możliwości.
- Tokeny są trudne do kradzieży i nieprawidłowego użycia. Są one powiązane czasowo, powiązane z odbiorcami i powiązane z obiektem.
- Przyjmują ustandaryzowany format. OpenID Connect (OIDC) z pełnym odnajdywaniem OIDC ułatwia dostawcom usług ich akceptowanie.
- Są one dystrybuowane do zasobników bezpieczniej przy użyciu nowego typu woluminu projektowanego przez Kubelet.
Broker weryfikuje tokeny za pomocą Kubernetes Token Review API. 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 używać SAT.
Tworzenie konta usługowego
Aby stworzyć SAT, 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
Opcjonalne: Dodawanie atrybutów autoryzacji
Klienci uwierzytelniający się za pośrednictwem SAT mogą opcjonalnie mieć adnotowane swoje konta usługowe atrybutami do wykorzystania w zasadach autoryzacji. Aby odróżnić te adnotacje od innych, zaczynają się od aio-broker-auth/ prefiksu.
Możesz dodać adnotację do konta usługi przy użyciu polecenia kubectl annotate:
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
Możesz też dodać adnotacje do pliku manifestu konta usługi:
apiVersion: v1
kind: ServiceAccount
metadata:
name: <SERVICE_ACCOUNT_NAME>
namespace: azure-iot-operations
annotations:
aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>
Aby dowiedzieć się więcej, zobacz Autoryzowanie klientów korzystających z tokenów konta usługi Kubernetes.
Włączanie uwierzytelniania SAT
Zmodyfikuj authenticationMethods ustawienia w zasobie BrokerAuthentication, aby wskazać ServiceAccountToken jako jedną z prawidłowych metod uwierzytelniania. Parametr audiences określa listę prawidłowych odbiorców tokenów. Wybierz unikatowe wartości identyfikujące usługę brokera MQTT. Musisz określić co najmniej jedną grupę odbiorców, a wszystkie SAT-y muszą odpowiadać jednej z określonych grup odbiorców.
- W portalu Azure przejdź do wystąpienia operacji IoT.
- W obszarze Składniki wybierz pozycję Broker MQTT.
- Wybierz kartę Uwierzytelnianie .
- Wybierz istniejące zasady uwierzytelniania lub utwórz nowe.
- Dodaj nową metodę, wybierając pozycję Dodaj metodę.
- Wybierz typ metody Kubernetes SAT z listy rozwijanej. Następnie wybierz pozycję Dodaj szczegóły , aby skonfigurować metodę.
Testowanie uwierzytelniania SAT
Uwierzytelnianie SAT używa rozszerzonych pól uwierzytelniania MQTT v5. Klient musi ustawić ulepszoną metodę uwierzytelniania na K8S-SAT i rozszerzone dane uwierzytelniania na token.
Na przykład użyj Mosquitto (niektóre pola pominięte dla zwięzłości):
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
<TOKEN> Oto token konta usługi. Aby uzyskać token testowy, uruchom polecenie:
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
<SERVICE_ACCOUNT> Oto nazwa utworzonego konta usługi i <AUDIENCE> jest jedną z grup odbiorców skonfigurowanych w zasobie BrokerAuthentication.
Aby zapoznać się z przykładem konfigurowania zasobnika Kubernetes w celu korzystania z uwierzytelniania SAT, zobacz Connect to the default listener inside the cluster (Nawiązywanie połączenia z odbiornikiem domyślnym w klastrze).
W konfiguracji zasobnika pole serviceAccountName musi być zgodne z kontem usługi skojarzonym używanym tokenem. Pole serviceAccountToken.audience musi być jednym ze skonfigurowanych audiences w zasobie BrokerAuthentication.
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.
Na przykład, jeśli klient jest podem, który używa tokenu zmontowanego jako wolumin, podobnie jak w przykładzie testowego uwierzytelniania SAT, najnowszy token jest dostępny w tej samej ścieżce /var/run/secrets/tokens/broker-sat. Gdy klient nawiązuje nowe połączenie, 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 elastyczna, ponieważ usługa może być czymkolwiek, o ile jest zgodna z interfejsem API.
Gdy klient łączy się z brokerem MQTT z włączonym uwierzytelnianiem niestandardowym, broker wysyła żądanie HTTPS do niestandardowego serwera uwierzytelniania przy użyciu poświadczeń klienta. Następnie serwer odpowiada za pomocą zatwierdzenia lub odmowy, w tym atrybutów autoryzacji klienta.
Tworzenie niestandardowej usługi uwierzytelniania
Niestandardowy serwer uwierzytelniania jest implementowany i wdrażany oddzielnie od brokera MQTT.
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.
API
Interfejs API między brokerem MQTT a niestandardowym serwerem uwierzytelniania jest zgodny ze specyfikacją interfejsu API na potrzeby uwierzytelniania niestandardowego. Specyfikacja interfejsu OpenAPI jest dostępna w witrynie GitHub.
Protokół HTTPS z szyfrowaniem TLS jest wymagany
Broker MQTT wysyła żądania zawierające poufne poświadczenia klienta do niestandardowego serwera uwierzytelniania. Aby chronić te poświadczenia, komunikacja między brokerem MQTT i niestandardowym serwerem uwierzytelniania musi być szyfrowana przy użyciu protokołu TLS.
Niestandardowy serwer uwierzytelniania musi przedstawić certyfikat serwera, a broker MQTT musi mieć zaufany certyfikat głównego urzędu certyfikacji do weryfikacji certyfikatu serwera. Opcjonalnie niestandardowy serwer uwierzytelniania może wymagać, aby broker MQTT przedstawił certyfikat klienta w celu uwierzytelnienia się.
Włączanie niestandardowego uwierzytelniania dla nasłuchującego
Zmodyfikuj ustawienie Metody uwierzytelniania 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 portalu Azure przejdź do wystąpienia operacji IoT.
W obszarze Składniki wybierz pozycję Broker MQTT.
Wybierz kartę Uwierzytelnianie .
Wybierz istniejące zasady uwierzytelniania lub utwórz nowe.
Dodaj nową metodę, wybierając pozycję Dodaj metodę.
Wybierz typ metody Niestandardowy z listy rozwijanej. Następnie wybierz pozycję Dodaj szczegóły , aby skonfigurować metodę.
Używanie uwierzytelniania niestandardowego na potrzeby uwierzytelniania nazwy użytkownika i hasła
Uwierzytelnianie niestandardowe służy do implementowania uwierzytelniania nazwy użytkownika i hasła. Przykładowy niestandardowy serwer uwierzytelniania jest dostępny do testowania. Zobacz przykład uwierzytelniania za pomocą nazwy użytkownika i hasła MQTT dla operacji Azure IoT na GitHub.
Wyłączanie uwierzytelniania
Na potrzeby testowania można wyłączyć uwierzytelnianie dla portu odbiornika brokera. Nie zalecamy wyłączania uwierzytelniania w środowiskach produkcyjnych.
- W portalu Azure przejdź do wystąpienia operacji IoT.
- W obszarze Składniki wybierz pozycję Broker MQTT.
- Wybierz odbiornik brokera, który chcesz edytować z listy.
- Na porcie, na którym chcesz wyłączyć uwierzytelnianie, wybierz pozycję Brak z listy rozwijanej uwierzytelniania.
Klienci zostaną rozłączeni po wygaśnięciu danych uwierzytelniających.
Broker MQTT rozłącza klientów po wygaśnięciu poświadczeń. Odłączenie po wygaśnięciu poświadczeń dotyczy wszystkich klientów łączących się z frontendami brokera MQTT, takimi jak:
- Klienci uwierzytelnieni przy użyciu SAT rozłączają się po wygaśnięciu ich SAT.
- Klienci uwierzytelnieni za pomocą protokołu X.509 rozłączają się po wygaśnięciu certyfikatu klienta.
- Klienci uwierzytelnieni za pomocą niestandardowego uwierzytelniania rozłączają się na podstawie czasu wygaśnięcia zwróconego z serwera niestandardowego uwierzytelniania.
Po rozłączeniu połączenie sieciowe klienta jest zamknięte. Klient nie odbiera pakietu MQTT DISCONNECT, ale broker rejestruje komunikat, że odłączył klienta.
Klienci MQTT w wersji 5 uwierzytelnieni za pomocą protokołów SAT i uwierzytelniania niestandardowego mogą ponownie uwierzytelniać się przy użyciu nowego poświadczenia przed wygaśnięciem ich początkowych poświadczeń. Klienci X.509 nie mogą się ponownie uwierzytelniać i muszą ponownie nawiązać połączenie, ponieważ uwierzytelnianie odbywa się na warstwie TLS.
Klienci mogą ponownie się uwierzytelnić, wysyłając pakiet AUTH MQTT v5 z przyczyną ReAuth.
Klienci SAT wysyłają klienta AUTH z polami method: K8S-SAT i data: <token>. Klienci uwierzytelniania niestandardowego ustawiają metodę i pole danych zgodnie z wymaganiami niestandardowego serwera uwierzytelniania.
Pomyślne ponowne uwierzytelnienie aktualizuje termin ważności poświadczeń klienta, dopasowując go do terminu ważności nowych poświadczeń. Broker odpowiada przy użyciu Success pakietu UWIERZYTELNIANIA. Uwierzytelnianie nie powiodło się z powodu przejściowych problemów, takich jak niedostępność niestandardowego serwera uwierzytelniania, co powoduje, że broker odpowiada pakietem ContinueAuthentication UWIERZYTELNIANIA. Klient może spróbować ponownie później. Inne błędy uwierzytelniania powodują, że broker wysyła pakiet DISCONNECT i zamyka połączenie sieciowe klienta.