Konfigurowanie uwierzytelniania brokera MQTT

Artykuł
12/04/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.

Broker MQTT obsługuje wiele metod uwierzytelniania dla klientów i można skonfigurować każdy port odbiornika tak, aby miał własne ustawienia uwierzytelniania za pomocą zasobu BrokerAuthentication . Aby uzyskać listę dostępnych ustawień, zobacz dokumentację interfejsu API uwierzytelniania brokera .

Link BrokerListener i BrokerAuthentication

Następujące reguły dotyczą relacji między zasobami BrokerListener i BrokerAuthentication :

Każdy element BrokerListener może mieć wiele portów. Każdy port może być połączony z zasobem BrokerAuthentication .
Każdy 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 usługi Azure IoT wdraża domyślny zasób BrokerAuthentication o nazwie default połączony z odbiornikiem domyślnym azure-iot-operations w przestrzeni nazw. Używa tylko tokenów kont usługi Kubernetes Service do uwierzytelniania.

Ważne

Metoda uwierzytelniania tokenu konta usługi (SAT) w domyślnym zasobie BrokerAuthentication jest wymagana do prawidłowego działania składników w operacjach usługi Azure IoT. Unikaj aktualizowania lub usuwania domyślnego zasobu BrokerAuthentication .

W witrynie Azure Portal 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ę.

Aby edytować domyślny punkt końcowy, utwórz plik Bicep .bicep z następującą zawartością. Zaktualizuj ustawienia zgodnie z potrzebami i zastąp wartości symboli zastępczych, na przykład <AIO_INSTANCE_NAME> własnymi.

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 defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
          ]
        }
      }
    ]
  }
}

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

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

Aby sprawdzić domyślny zasób uwierzytelniania brokera, uruchom polecenie:

kubectl get brokerauthentication default -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: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - aio-internal

Jeśli musisz wprowadzić zmiany, zmodyfikuj authenticationMethods pole w tym zasobie, zachowując metodę uwierzytelniania SAT z odbiorcami aio-internal . Następnie wdróż go przy użyciu polecenia kubectl apply.

Przepływ uwierzytelniania

Kolejność określonych metod uwierzytelniania określa sposób uwierzytelniania klientów przez brokera MQTT. Broker MQTT próbuje uwierzytelnić poświadczenia klienta przy użyciu pierwszej określonej metody i iteruje za pośrednictwem określonych metod, dopóki nie znajdzie dopasowania lub osiągnie koniec.

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, ponieważ poświadczenia nie są istotne. To zachowanie umożliwia brokerowi MQTT powrót do innych metod, jeśli niestandardowy serwer uwierzytelniania jest niemożliwy do osiągnięcia.

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.

Na 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 niestandardowe i SAT. Gdy klient nawiązuje połączenie, broker MQTT próbuje uwierzytelnić klienta przy użyciu określonych metod w kolejności niestandardowej, a następnie SAT.

Broker MQTT sprawdza, czy poświadczenia klienta są prawidłowe do 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 Pass na wartość lub Fail wynik, przepływ uwierzytelniania kończy się. Jeśli jednak niestandardowy serwer uwierzytelniania nie jest dostępny, broker MQTT powraca do pozostałych określonych metod, a serwer SAT jest następny.
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 witrynie Azure Portal 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ę.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        customSettings: {
          endpoint: 'https://auth-server-template'
          caCertConfigMap: 'custom-auth-ca'
          auth: {
            x509: {
              secretRef: 'custom-auth-client-cert'
            }
          }
          headers: {
            header_key: 'header_value'
          }
        }
      }
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: 'client-ca'
          authorizationAttributes: {
            root: {
              attributes: {
                organization: 'contoso'
              }
              subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
            }
            intermediate: {
              attributes: {
                city: 'seattle'
                foo: 'bar'
              }
              subject: 'CN = Contoso Intermediate CA'
            }
            smartfan: {
              attributes: {
                building: '17'
              }
              subject: 'CN = smart-fan'
            }
          }
        }
      }
    ]
  }
}

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

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

Zmodyfikuj zasób BrokerAuthentication dla zasad uwierzytelniania, dodając nowe metody do authenticationMethods sekcji. W poniższym przykładzie przedstawiono wiele metod uwierzytelniania dla zasobu BrokerAuthentication :

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: my-policy
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: Custom
    customSettings:
      endpoint: https://auth-server-template
      caCertConfigMap: custom-auth-ca
      auth:
        x509:
          secretRef: custom-auth-client-cert
      headers:
        header_key: header_value
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience
    - method: X509
      x509Settings:
        trustedClientCaCert: client-ca
        authorizationAttributes:
          root:
            attributes:
              organization: contoso
            subject: CN = Contoso Root CA Cert, OU = Engineering, C = US
          intermediate:
            attributes:
              city: seattle
              foo: bar
            subject: CN = Contoso Intermediate CA
          smart-fan:
            attributes:
              building: "17"
            subject: CN = smart-fan

Aby zmienić konfigurację, zmodyfikuj authenticationMethods ustawienie w tym zasobie BrokerAuthentication , a następnie wdróż je przy użyciu polecenia kubectl apply.

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ń przez skonfigurowanie usługi Azure Key Vault i włączanie tożsamości obciążeń, zobacz Włączanie bezpiecznych ustawień we wdrożeniu operacji usługi Azure IoT.

X.509

Napiwek

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 można było używać uwierzytelniania X.509 z zaufanym certyfikatem urzędu certyfikacji, należy spełnić następujące wymagania:

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 mieć format PEM.

Napiwek

Format PEM jest typowym formatem certyfikatów i kluczy. Pliki PEM są plikami ASCII zakodowanymi 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 biblioteki OpenSSL. Aby uzyskać więcej informacji, zobacz Jak przekonwertować certyfikat na odpowiedni format.

Uzyskiwanie zaufanego certyfikatu urzędu certyfikacji

W konfiguracji produkcyjnej certyfikat urzędu certyfikacji jest dostarczany 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 urzędu certyfikacji z podpisem własnym z kluczem RSA, nazwą CN=Contoso Root CA Certwyróżniającą 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 z interfejsem wiersza polecenia kroku, które jest wygodnym narzędziem do zarządzania certyfikatami, jest:

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 ca.pem certyfikacji i klucz ca-key.pem prywatny w formacie PEM. Certyfikat urzędu ca.pem certyfikacji można zaimportować do brokera MQTT na potrzeby uwierzytelniania X.509.

Importowanie zaufanego certyfikatu urzędu certyfikacji

Aby rozpocząć uwierzytelnianie 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, więc nazwa klucza może być niczym.

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
====
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 witrynie Azure Portal 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, a następnie wybierz pozycję Dodaj szczegóły , aby skonfigurować metodę.
W okienku szczegółów uwierzytelniania X.509 określ nazwę ConfigMap zaufanego certyfikatu urzędu certyfikacji przy użyciu formatu JSON.
```
{
    "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
}
```
Zastąp <TRUSTED_CA_CONFIGMAP> ciąg nazwą ConfigMap, która zawiera zaufany certyfikat urzędu certyfikacji. Na przykład "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 pozycję Zastosuj , aby zapisać zmiany.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'
param trustedCaConfigMap string = '<TRUSTED_CA_CONFIGMAP>'

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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: trustedCaConfigMap
          // authorizationAttributes: {
            //// Optional authorization attributes
            //// See the next section for more information
          // }
        }
      }
    ]
  }
}

Zastąp <TRUSTED_CA_CONFIGMAP> ciąg nazwą ConfigMap, która zawiera zaufany certyfikat urzędu certyfikacji. Na przykład client-ca.

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

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

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
        # authorizationAttributes:
          ## Optional authorization attributes
          ## See the next section for more information

Zastąp <TRUSTED_CA_CONFIGMAP> ciąg nazwą ConfigMap, która zawiera zaufany certyfikat urzędu certyfikacji. Na przykład client-ca.

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.

Na 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"
      }
    }
  }
}

x509Settings: {
  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'
      }
    }
  }
}

x509Settings:
  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
    smart-fan:
      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 lub pośrednim urzędem certyfikacji o nazwie CN = Contoso Root CA Cert, OU = Engineering, C = US CN = Contoso Intermediate CA wyróżniającej otrzymuje wymienione atrybuty. Ponadto certyfikat klienta wentylatora inteligentnego odbiera 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.

Włączanie uwierzytelniania X.509 dla portu odbiornika

Po zaimportowaniu certyfikatu zaufanego 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

Włączenie protokołu TLS na porcie odbiornika brokera oznacza, że broker używa certyfikatu serwera do szyfrowania TLS. Gdy klienci łączą się z tym portem, muszą ufać certyfikatowi serwera, mając certyfikat urzędu certyfikacji, który go podpisał w magazynie zaufania. Ten proces jest nazywany dystrybucją zaufania lub tworzeniem pakietów zaufania. Ważne jest, aby zrozumieć różnicę między weryfikacją serwera a weryfikacją klienta:

Weryfikacja klienta: broker MQTT (serwer) sprawdza certyfikat klienta względem zaufanego certyfikatu urzędu certyfikacji określonego trustedClientCaCert w polu 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 magazynie zaufania. 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 urzędu certyfikacji po stronie serwera w magazynie zaufania. Nie należy mylić zaufania certyfikatu urzędu certyfikacji po stronie serwera z certyfikatem urzędu certyfikacji po stronie klienta używanym do uwierzytelniania klienta określonego trustedClientCaCert w polu.

Pełny przykład można znaleźć w artykule Tutorial: TLS, X.509 client authentication (Samouczek: 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 --cert okreś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 --key okreś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, --cafile wymagany jest parametr. 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ą magazynu głównego systemu (na przykład znanych publicznych urzędów certyfikacji), --cafile parametr można pominąć.

Na 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

Diagram przepływu uwierzytelniania klienta X.509.

Poniżej przedstawiono kroki uwierzytelniania klienta:

Gdy uwierzytelnianie klienta X.509 jest włączone, łączenie klientów musi przedstawić certyfikat klienta i wszystkie certyfikaty pośrednie, aby umożliwić brokerowi MQTT utworzenie łańcucha certyfikatów rooted do jednego ze skonfigurowanych zaufanych certyfikatów.
Moduł równoważenia obciążenia kieruje komunikację z jednym z brokerów frontonu.
Gdy broker frontonu odebrał certyfikat klienta, próbuje utworzyć łańcuch certyfikatów, który jest zakorzeniony w jednym ze skonfigurowanych certyfikatów. 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 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 kierowany do frontonu.
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 ma łączących się klientów. Te atrybuty określają, jakie operacje może wykonać klient, w tym sam pakiet CONNECT.
Usługa uwierzytelniania zwraca decyzję o brokerze frontonu.
Broker frontonu zna atrybuty klienta i 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 Service

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

Broker MQTT 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ą ustandaryzowany format: OpenID Connect (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

Opcjonalne: Dodawanie atrybutów autoryzacji

Klienci uwierzytelniający się za pośrednictwem sat mogą opcjonalnie mieć swoje konta usług z adnotacjami z atrybutami, które mają być używane z zasadami 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 Service.

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

Zmodyfikuj authenticationMethods ustawienie w zasobie BrokerAuthentication , aby określić ServiceAccountToken jako prawidłową metodę uwierzytelniania. Określa audiences 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 grupy Zabezpieczeń muszą być zgodne z jedną z określonych grup odbiorców.

W witrynie Azure Portal 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, a następnie wybierz pozycję Dodaj szczegóły , aby skonfigurować metodę.

Zrzut ekranu przedstawiający konfigurowanie metody uwierzytelniania SAT brokera MQTT przy użyciu witryny Azure Portal.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_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 myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

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

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

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience

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

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 przy użyciu 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 serviceAccountName zasobnika pole musi być zgodne z kontem usługi skojarzonym z używanym tokenem, a serviceAccountToken.audience pole 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.

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/broker-sat. 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 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.

interfejs API

Interfejs API między brokerem MQTT 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

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ć od brokera MQTT przedstawienia certyfikatu 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:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: 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

Wyłączanie uwierzytelniania

Na potrzeby testowania można wyłączyć uwierzytelnianie dla portu odbiornika brokera. Wyłączenie uwierzytelniania nie jest zalecane w środowiskach produkcyjnych.

W witrynie Azure Portal 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, który chcesz wyłączyć uwierzytelnianie, wybierz pozycję Brak z listy rozwijanej uwierzytelniania.

Klienci rozłączą się po wygaśnięciu poświadczeń

Broker MQTT rozłącza klientów po wygaśnięciu poświadczeń. Rozłącz po wygaśnięciu poświadczeń dotyczy wszystkich klientów łączących się z frontonami brokera MQTT, w tym:

Klienci uwierzytelnieni przy użyciu protokołu 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 niestandardowego serwera 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ą ponownie uwierzytelniać się i muszą ponownie ustanowić połączenie, ponieważ uwierzytelnianie odbywa się w warstwie PROTOKOŁU TLS.

Klienci mogą ponownie uwierzytelniać się, wysyłając pakiet UWIERZYTELNIANIA MQTT v5 z przyczyną ReAuth.

Klienci SAT wysyłają klienta UWIERZYTELNIANIA przy użyciu pól method: K8S-SAT, data: <token>. Klienci uwierzytelniania niestandardowego ustawiają metodę i pole danych zgodnie z wymaganiami niestandardowego serwera uwierzytelniania.

Pomyślne ponowne uwierzytelnienie aktualizuje wygasanie poświadczeń klienta z upływem czasu wygaśnięcia nowego poświadczenia, a broker odpowiada za pomocą pakietu Success AUTH. Uwierzytelnianie nie powiodło się z powodu przejściowych problemów, takich jak niedostępny niestandardowy serwer uwierzytelniania, co powoduje, że broker odpowie pakietem ContinueAuthentication AUTH. 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.

Udostępnij za pośrednictwem

Konfigurowanie uwierzytelniania brokera MQTT

Link BrokerListener i BrokerAuthentication

Domyślny zasób BrokerAuthentication

Przepływ uwierzytelniania

Konfigurowanie metody uwierzytelniania

X.509

Uzyskiwanie zaufanego certyfikatu urzędu certyfikacji

Importowanie zaufanego certyfikatu urzędu certyfikacji

Konfigurowanie metody uwierzytelniania X.509

Opcjonalne: atrybuty certyfikatu na potrzeby autoryzacji

Włączanie uwierzytelniania X.509 dla portu odbiornika

Łączenie klienta mosquitto z brokerem MQTT przy użyciu certyfikatu klienta X.509

Omówienie przepływu uwierzytelniania klienta X.509 brokera MQTT

Tokeny konta usługi Kubernetes Service

Tworzenie konta usługowego

Opcjonalne: Dodawanie atrybutów autoryzacji

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

Testowanie uwierzytelniania SAT

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

Uwierzytelnianie niestandardowe

Tworzenie niestandardowej usługi uwierzytelniania

interfejs API

Protokół HTTPS z szyfrowaniem TLS jest wymagany

Włączanie uwierzytelniania niestandardowego dla odbiornika

Wyłączanie uwierzytelniania

Klienci rozłączą się po wygaśnięciu poświadczeń

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Konfigurowanie uwierzytelniania brokera MQTT

Link BrokerListener i BrokerAuthentication

Domyślny zasób BrokerAuthentication

Przepływ uwierzytelniania

Konfigurowanie metody uwierzytelniania

X.509

Uzyskiwanie zaufanego certyfikatu urzędu certyfikacji

Importowanie zaufanego certyfikatu urzędu certyfikacji

Konfigurowanie metody uwierzytelniania X.509

Opcjonalne: atrybuty certyfikatu na potrzeby autoryzacji

Włączanie uwierzytelniania X.509 dla portu odbiornika

Łączenie klienta mosquitto z brokerem MQTT przy użyciu certyfikatu klienta X.509

Omówienie przepływu uwierzytelniania klienta X.509 brokera MQTT

Tokeny konta usługi Kubernetes Service

Tworzenie konta usługowego

Opcjonalne: Dodawanie atrybutów autoryzacji

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

Testowanie uwierzytelniania SAT

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

Uwierzytelnianie niestandardowe

Tworzenie niestandardowej usługi uwierzytelniania

interfejs API

Protokół HTTPS z szyfrowaniem TLS jest wymagany

Włączanie uwierzytelniania niestandardowego dla odbiornika

Wyłączanie uwierzytelniania

Klienci rozłączą się po wygaśnięciu poświadczeń

Powiązana zawartość

Opinia

Dodatkowe zasoby