Sdílet prostřednictvím

Konfigurace ověřování zprostředkovatele MQTT

Důležité

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

Podívejte se na doplňkové podmínky užívání služby Microsoft Azure Preview pro právní podmínky, které se vztahují na funkce Azure, jež jsou ve verzi beta, Preview nebo jinak ještě nejsou obecně dostupné.

Zprostředkovatel MQTT podporuje více metod ověřování pro klienty. Každý naslouchací port můžete nakonfigurovat tak, aby měl vlastní nastavení ověřování pomocí prostředku BrokerAuthentication. Seznam dostupných nastavení najdete v referenčních informacích k rozhraní API pro ověřování zprostředkovatele .

Následující pravidla platí pro vztah mezi prostředky BrokerListener a BrokerAuthentication:

  • Každý prostředek BrokerListener může mít více portů. Každý port můžete propojit s prostředkem BrokerAuthentication.
  • Každý prostředek BrokerAuthentication může podporovat více metod ověřování najednou.
  • Porty, které nejsou propojené s prostředkem BrokerAuthentication, mají ověřování zakázáno.

Pokud chcete propojit port BrokerListener s prostředkem BrokerAuthentication, zadejte authenticationRef pole v ports nastavení prostředku BrokerListener. Další informace najdete v tématu Prostředek BrokerListener.

Výchozí prostředek ověření zprostředkovatele

Operace Azure IoT nasadí výchozí prostředek BrokerAuthentication s názvem default propojeným s výchozím naslouchacím procesem azure-iot-operations v oboru názvů. K ověřování používá pouze tokeny účtů služby Kubernetes .

Důležité

Metoda ověřování SAT ve výchozím prostředku BrokerAuthentication je nutná pro správné fungování komponent v operacích IoT. Vyhněte se aktualizaci nebo odstranění výchozího prostředku BrokerAuthentication.

  1. Na webu Azure Portal přejděte do vaší instance ioT Operations.

  2. V části Součásti vyberte Zprostředkovatele MQTT.

  3. Vyberte kartu Ověřování.

  4. V seznamu zásad ověřování vyberte výchozí název zásady.

    Snímek obrazovky znázorňující použití webu Azure Portal k zobrazení výchozích zásad ověřování zprostředkovatele MQTT

Pokud chcete přidat nové metody ověřování, vyberte Přidat metodu.

Průběh ověřování

Pořadí zadaných metod ověřování určuje, jak zprostředkovatel MQTT ověřuje klienty. Zprostředkovatel MQTT se pokusí ověřit přihlašovací údaje klienta pomocí první zadané metody a iteruje zadanými metodami, dokud nenajde shodu nebo nedosáhne konce.

Pro každou metodu zprostředkovatel MQTT nejprve zkontroluje, jestli jsou přihlašovací údaje klienta pro danou metodu relevantní . Například ověřování SAT vyžaduje uživatelské jméno začínající K8S-SATa ověřování X.509 vyžaduje klientský certifikát. Pokud jsou přihlašovací údaje klienta relevantní, zprostředkovatel MQTT pak ověří, jestli jsou platné. Další informace najdete v části Konfigurace metody ověřování .

U vlastního ověřování považuje zprostředkovatel MQTT selhání při komunikaci s vlastním ověřovacím serverem za neplatné přihlašovací údaje. Toto chování umožňuje zprostředkovateli MQTT přejít k jiným metodám, pokud je vlastní ověřovací server nedostupný.

Tok ověřování končí v následujících případech:

  • Jedna z těchto podmínek je pravdivá:
    • Přihlašovací údaje klienta jsou relevantní a platné pro jednu z metod.
    • Přihlašovací údaje klienta nejsou pro žádnou z metod relevantní.
    • Přihlašovací údaje klienta jsou pro některou z metod relevantní, ale neplatné.
  • Zprostředkovatel MQTT buď udělí nebo odmítne přístup k klientovi na základě výsledku ověřovacího toku.

Například:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

Předchozí příklad určuje custom a SAT. Když se klient připojí, zprostředkovatel MQTT se pokusí ověřit klienta pomocí zadaných metod v pořadí custom a pak SAT.

  1. Zprostředkovatel MQTT zkontroluje, jestli jsou přihlašovací údaje klienta platné pro vlastní ověřování. Vzhledem k tomu, že vlastní ověřování závisí na externím serveru k určení platnosti přihlašovacích údajů, zprostředkovatel považuje všechny přihlašovací údaje relevantní pro vlastní ověřování a předá je vlastnímu ověřovacímu serveru.
  2. Pokud vlastní ověřovací server odpoví Pass nebo Fail výsledkem, tok ověřování skončí. Pokud vlastní ověřovací server není k dispozici, zprostředkovatel MQTT se vrátí ke zbývajícím zadaným metodám, přičemž sat je další.
  3. Zprostředkovatel MQTT se pokusí ověřit přihlašovací údaje jako přihlašovací údaje SAT.

Pokud vlastní ověřovací server není dostupný a všechny následné metody určují, že zadané přihlašovací údaje nejsou relevantní, zprostředkovatel odmítne připojení klienta.

Konfigurace metody ověřování

Do zásad ověřování můžete přidat metody ověřování, jako je X.509, SAT nebo vlastní.

Přidejte metodu ověřování do zásady:

  1. Na webu Azure Portal přejděte do vaší instance ioT Operations.

  2. V části Součásti vyberte Zprostředkovatele MQTT.

  3. Vyberte kartu Ověřování.

  4. Zvolte existující zásady ověřování nebo vytvořte novou.

  5. Novou metodu přidáte výběrem možnosti Přidat metodu.

  6. V rozevíracím seznamu zvolte typ metody a pak vyberte Přidat podrobnosti a nakonfigurujte metodu.

    Snímek obrazovky znázorňující použití webu Azure Portal k přidání metody zásad ověřování zprostředkovatele MQTT

Další informace o jednotlivých možnostech ověřování najdete v dalších částech jednotlivých metod.

Další informace o tom, jak povolit zabezpečená nastavení konfigurací instance služby Azure Key Vault a povolením identit úloh, najdete v tématu Povolení nastavení zabezpečení v nasazení operací Azure IoT.

Položka X.509

Návod

Kompletní příklad konfigurace ověřování X.509 najdete v tématu Kurz: Tls, ověřování klientů X.509 a autorizace řízení přístupu na základě atributů (ABAC).

S ověřováním X.509 používá zprostředkovatel MQTT certifikát důvěryhodné certifikační autority (CA) k ověření klientských certifikátů. Tato důvěryhodná certifikační autorita může být kořenovou nebo zprostředkující certifikační autoritou. Zprostředkovatel zkontroluje řetěz klientských certifikátů vůči certifikátu důvěryhodné certifikační autority. Pokud je řetěz platný, klient se ověří.

Pokud chcete použít ověřování X.509 s důvěryhodným certifikátem certifikační autority, musíte splnit následující požadavky:

  • Protokol TLS (Transport Layer Security): Vzhledem k tomu, že X.509 využívá klientské certifikáty TLS, musí být pro porty povolené ověřování X.509.
  • Klíčové algoritmy: Podporují se klíče EC i RSA, ale všechny certifikáty v řetězu musí používat stejný algoritmus klíče.
  • Formát: Certifikát CA musí být ve formátu Privacy-Enhanced Mail (PEM).

Návod

Formát PEM je běžný formát pro certifikáty a klíče. Soubory PEM jsou soubory ASCII s kódováním Base64 s hlavičkami jako -----BEGIN CERTIFICATE----- a -----BEGIN EC PRIVATE KEY-----.

Pokud máte certifikát v jiném formátu, můžete ho převést na PEM pomocí OpenSSL. Další informace naleznete v tématu Převod certifikátu do příslušného formátu.

Získání certifikátu důvěryhodné certifikační autority

V produkčním nastavení poskytuje certifikát certifikační autority infrastruktura veřejných klíčů (PKI) organizace nebo veřejná certifikační autorita.

Pro účely testování vytvořte certifikát certifikační autority podepsaný svým držitelem pomocí OpenSSL. Spuštěním následujícího příkazu vygenerujte certifikát certifikační autority podepsaný svým držitelem s klíčem RSA, rozlišujícím názvem CN=Contoso Root CA Certa platností 365 dnů:

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

Stejný příkaz pomocí nástroje příkazového řádku Step, což je pohodlný nástroj pro správu certifikátů, je:

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

Tyto příkazy vytvoří certifikát ca.pemcertifikační autority a privátní klíč ca-key.pemve formátu PEM. Certifikát certifikační autority ca.pem můžete importovat do brokeru MQTT pro ověřování X.509.

Import certifikátu důvěryhodné certifikační autority

Pokud chcete začít s ověřováním X.509, naimportujte důvěryhodný certifikát certifikační autority do ConfigMap v oboru názvů azure-iot-operations. Pokud chcete importovat certifikát důvěryhodné certifikační autority ca.pem do objektu ConfigMap s názvem client-ca, spusťte:

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

V tomto příkladu se certifikát certifikační autority naimportuje pod klíčem ca.pem. Zprostředkovatel MQTT důvěřuje všem certifikátům certifikační autority v objektu ConfigMap, takže pro název klíče můžete použít cokoli.

Pokud chcete zkontrolovat, jestli je kořenový certifikát certifikační autority správně importovaný, spusťte kubectl describe configmappříkaz . Výsledkem je stejné kódování Base64 souboru certifikátu 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
====

Konfigurace metody ověřování X.509

Po importu certifikátu důvěryhodné certifikační autority povolte ověření klienta X.509 tak, že ho přidáte jako metodu ověřování do prostředku BrokerAuthentication. Ujistěte se, že je tento prostředek propojený s naslouchacím portem s povoleným protokolem TLS.

  1. Na webu Azure Portal přejděte do vaší instance ioT Operations.

  2. V části Součásti vyberte Zprostředkovatele MQTT.

  3. Vyberte kartu Ověřování.

  4. Zvolte existující zásady ověřování nebo vytvořte novou.

  5. Novou metodu přidáte výběrem možnosti Přidat metodu.

  6. V rozevíracím seznamu zvolte typ metody X.509 . Pak vyberte Přidat podrobnosti a nakonfigurujte metodu.

  7. V podokně podrobnosti o autentizaci X.509 zadejte název objektu ConfigMap důvěryhodné certifikační autority ve formátu JSON.

    {
    "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
}

    Nahraďte <TRUSTED_CA_CONFIGMAP> názvem objektu ConfigMap, který obsahuje certifikát důvěryhodné certifikační autority. Například použijte "trustedClientCaCert": "client-ca".

    Snímek obrazovky znázorňující použití webu Azure Portal k nastavení metody ověřování X.509 zprostředkovatele MQTT

  8. Volitelně můžete přidat atributy autorizace pro klienty pomocí certifikátů X.509. Další informace najdete v tématu Atributy certifikátu pro autorizaci.

  9. Chcete-li uložit změny, vyberte Použít .

Volitelné: Atributy certifikátu pro autorizaci

V prostředku BrokerAuthentication můžete zadat atributy X.509 pro autorizaci klientů na základě jejich vlastností certifikátu. Atributy jsou definovány v authorizationAttributes poli.

Například:

Když na webu Azure Portal nakonfigurujete metodu ověřování X.509, přidejte atributy autorizace v podokně podrobností o ověřování X.509 ve formátu 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"
      }
    }
  }
}

V tomto příkladu každý klient, který má certifikát vydaný kořenovou certifikační autoritou s rozlišujícím názvem CN = Contoso Root CA Cert, OU = Engineering, C = US nebo zprostředkující certifikační autoritou s rozlišujícím názvem CN = Contoso Intermediate CA , obdrží uvedené atributy. Kromě toho klientský certifikát inteligentního ventilátoru přijímá atributy specifické pro něj.

Porovnávání atributů vždy začíná od klientského certifikátu typu list a pak pokračuje po řetězu. Přiřazení atributu se zastaví po první shodě. V předchozím příkladu, i když smart-fan má zprostředkující certifikát CN = Contoso Intermediate CA, nezískute přidružené atributy.

Autorizační pravidla můžete použít pro klienty pomocí certifikátů X.509 s těmito atributy. Další informace najdete v tématu Autorizace klientů, kteří používají ověřování X.509.

Volitelné: Integrace služby Azure Device Registry pro ověřování X.509 (Preview)

Důležité

Integrace služby Azure Device Registry pro ověřování X.509 je aktuálně ve verzi Preview. Tato funkce podléhá určitým omezením a nedoporučuje se pro produkční úlohy. Další informace najdete v dodatečných podmínkách použití pro verze Preview v Microsoft Azure.

Integraci služby Azure Device Registry s ověřováním X.509 můžete povolit k vynucení ověření a odvolání certifikátu na úrovni zařízení. Pokud je tato funkce povolená, vyžaduje klienty X.509, aby měli odpovídající zařízení v registru zařízení a umožňuje zakázat klienty zakázáním odpovídajícího zařízení.

S povolenou integrací služby Azure Device Registry:

  • Klientské certifikáty musí mít běžný název (CN), který odpovídá názvu zařízení ve službě Azure Device Registry.
  • Úspěšně se můžou ověřit jenom zařízení v registru.
  • Stav zařízení se kontroluje při ověřování klientů a každých 10 minut.
  • Zakázaná nebo odebraná zařízení jsou automaticky odepřena přístup.

Před povolením této funkce vytvořte odpovídající zařízení ve službě Azure Device Registry pro každý klientský certifikát. Název zařízení se musí shodovat s běžným názvem certifikátu (CN). Pokud chcete vytvářet a spravovat zařízení ve službě Azure Device Registry, přečtěte si téma:

Pokud chcete povolit integraci služby Azure Device Registry, nastavte additionalValidation pole v AzureDeviceRegistry nastavení X.509. Pole additionalValidation provádí dodatečné ověření klientského certifikátu pomocí zadané metody s podporovanými hodnotami AzureDeviceRegistry nebo None (výchozí):

Když na webu Azure Portal nakonfigurujete metodu ověřování X.509, přidejte do podokna podrobností o ověřování X.509 ve formátu JSON ověření ověření Azure Device Registry:

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "additionalValidation": "AzureDeviceRegistry"
}

Po povolení integrace služby Azure Device Registry vytvořte odpovídající zařízení ve službě Azure Device Registry pro každý klientský certifikát. Název zařízení se musí shodovat s běžným názvem certifikátu (CN). Pokud se klient pokusí ověřit pomocí certifikátu, který nemá v registru odpovídající povolené zařízení, ověřování selže.

Povolení ověřování X.509 pro port naslouchání

Po importu certifikátu od důvěryhodné certifikační autority a nakonfigurování prostředku BrokerAuthentication jej propojte s portem posluhače podporujícím TLS. Tento krok je důležitý, protože ověřování X.509 spoléhá na ověřování klientských certifikátů na tls.

Pokud chcete získat port naslouchacího procesu s povoleným protokolem TLS, přečtěte si téma Povolení ruční správy certifikátů PROTOKOLU TLS pro port a povolení automatické správy certifikátů PROTOKOLU TLS pro port.

Poznámka:

Povolení protokolu TLS na portu naslouchacího procesu zprostředkovatele znamená, že zprostředkovatel používá pro šifrování TLS certifikát serveru. Když se klienti připojují k tomuto portu, musí důvěřovat certifikátu serveru tak, že mají certifikát certifikační autority, který ho podepsal, ve svém důvěryhodném úložišti. Tento proces se označuje jako distribuce důvěryhodnosti nebo sdružování důvěryhodnosti. Je důležité pochopit rozdíl mezi ověřováním klienta a ověřováním serveru:

  • Ověření klienta: Zprostředkovatel MQTT (server) kontroluje klientský certifikát vůči důvěryhodnému certifikátu certifikační autority zadanému v trustedClientCaCert poli pro ověřování klientů X.509.
  • Ověření serveru: Klienti (například Mosquitto nebo MQTTX) kontrolují certifikát serveru zprostředkovatele MQTT vůči důvěryhodnému certifikátu certifikační autority ve svém úložišti důvěryhodnosti. Pro klienty Mosquitto použijte --cafile parametr k určení souboru certifikátu certifikační autority. Pro MQTTX přidejte certifikát certifikační autority do úložiště důvěryhodnosti v nastavení.

Po povolení ověřování X.509 zajistěte, aby klienti důvěřovali certifikátu serveru zprostředkovatele tím, že mají certifikát certifikační autority na straně serveru ve svém úložišti důvěryhodnosti. Nezaměňujte důvěryhodnost certifikátu certifikační autority na straně serveru s certifikátem certifikační autority na straně klienta , který se používá pro ověřování klienta zadaného trustedClientCaCert v poli.

Úplný příklad najdete v tématu Kurz: TLS, ověřování klientů X.509 a autorizace řízení přístupu na základě atributů (ABAC).

Připojení klienta Mosquitto ke zprostředkovateli MQTT pomocí klientského certifikátu X.509

Klient, jako je Mosquitto, potřebuje dva soubory, aby se mohl připojit ke zprostředkovateli MQTT pomocí protokolu TLS a ověřování klientů X.509:

  • Parametr --cert určuje soubor PEM klientského certifikátu. Tento soubor by měl obsahovat také všechny zprostředkující certifikáty, které zprostředkovateli MQTT pomůžou sestavit kompletní řetěz certifikátů.
  • Parametr --key určuje soubor PEM privátního klíče klienta.

V případech, kdy zprostředkovatel MQTT používá certifikát certifikační autority podepsané svým držitelem k vydání certifikátu serveru TLS, je potřeba parametr --cafile . Tento soubor obsahuje certifikát certifikační autority (označovaný také jako sada důvěryhodných certifikátů), který klient Mosquitto používá k ověření certifikátu serveru zprostředkovatele při připojení přes protokol TLS. Pokud je vystavitel certifikátu serveru zprostředkovatele MQTT součástí systémového kořenového úložiště (například známých veřejných certifikačních autorit), --cafile může být parametr vynechán.

Například:

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

Porozumění toku ověřování klienta X.509 s brokerem MQTT

Diagram znázorňující tok ověřování klienta X.509

Při ověřování klientů postupujte takto:

  1. Pokud je zapnuté ověřování klientů X.509, musí připojení klienti předložit klientský certifikát a všechny zprostředkující certifikáty, aby zprostředkovatel MQTT vytvořil řetěz certifikátů root s jedním z nakonfigurovaných důvěryhodných certifikátů.
  2. Nástroj pro vyrovnávání zatížení směruje komunikaci na jednoho z front-endových zprostředkovatelů.
  3. Jakmile front-endový zprostředkovatel obdrží klientský certifikát, pokusí se vytvořit řetěz certifikátů, který je rootovaný na jednom z nakonfigurovaných certifikátů. Pokud front-endový zprostředkovatel úspěšně sestaví řetězec a předložený řetězec je ověřen, dokončí handshake protokolu TLS. Připojovací klient dokáže odesílat pakety MQTT do front-endu prostřednictvím kanálu TLS.
  4. Kanál TLS je otevřený, ale ověřování nebo autorizace klienta ještě není dokončené.
  5. Klient pak odešle paket CONNECT do zprostředkovatele MQTT.
  6. Paket CONNECT se znovu směruje do front-endu.
  7. Front-end shromažďuje všechny přihlašovací údaje, které klient dosud zobrazil, jako jsou ověřovací data z paketu CONNECT, a řetěz klientských certifikátů prezentovaný během metody handshake protokolu TLS.
  8. Front-end tyto přihlašovací údaje odešle ověřovací službě. Ověřovací služba znovu zkontroluje řetěz certifikátů a shromažďuje názvy subjektu všech certifikátů v řetězu.
  9. Ověřovací služba používá nakonfigurovaná autorizační pravidla k určení atributů, které mají připojující klienti. Tyto atributy určují, jaké operace může klient spustit, včetně samotného paketu CONNECT.
  10. Ověřovací služba vrátí rozhodnutí front-endovému zprostředkovateli.
  11. Front-endový zprostředkovatel zná atributy klienta a jestli se může připojit. Pokud ano, připojení MQTT se dokončí a klient může dál odesílat a přijímat pakety MQTT podle autorizačních pravidel.

Tokeny účtu služby Kubernetes Service

SAT Kubernetes jsou webové tokeny JSON přidružené k účtům služby Kubernetes. Klienti prezentují SAT zprostředkovateli MQTT, aby se ověřili.

Zprostředkovatel MQTT používá vázané tokeny účtu služby, které jsou popsány v tématu Co uživatelé GKE potřebují vědět o nových tokenech účtu služby Kubernetes. Tady jsou hlavní funkce z příspěvku:

Vázané tokeny spuštěné v Kubernetes 1.13 a staly se výchozím formátem ve verzi 1.21. Vázané tokeny řeší všechny omezené funkce starších tokenů a další:

  • Tokeny jsou těžké ukrást a zneužít. Jsou vázané na čas, cílové skupiny a objektově vázané.
  • Přijímají standardizovaný formát. OpenID Connect (OIDC) s úplným zjišťováním OIDC usnadňuje poskytovatelům služeb jejich přijetí.
  • Distribuují se bezpečněji do podů pomocí nového typu projektovaného svazku Kubelet.

Zprostředkovatel ověřuje tokeny pomocí rozhraní API pro kontrolu tokenů Kubernetes. Povolte funkci Kubernetes TokenRequestProjection k určení audiences (výchozí od verze 1.21). Pokud tato funkce není povolená, nemůžete použít SAT.

Vytvoření účtu služby

Pokud chcete vytvořit SAT, nejprve vytvořte účet služby. Následující příkaz vytvoří účet služby s názvem mqtt-client:

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

Volitelné: Přidání atributů pro autorizaci

Klienti, kteří se ověřují pomocí SAT, mohou mít volitelně jejich účty služeb opatřeny atributy pro použití se zásadami autorizace. Aby se tyto poznámky odlišily od ostatních, začínají předponou aio-broker-auth/ .

Účet služby můžete komentovat pomocí:kubectl annotate

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

Nebo můžete přidat poznámky do souboru manifestu účtu služby:

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>

Další informace najdete v tématu Autorizace klientů, kteří používají tokeny účtu služby Kubernetes.

Povolit ověřování SAT

authenticationMethods Upravte nastavení v prostředku BrokerAuthentication tak, aby bylo možné zadat ServiceAccountToken jako platnou metodu ověřování. Parametr audiences určuje seznam platných cílových skupin pro tokeny. Zvolte jedinečné hodnoty, které identifikují službu zprostředkovatele MQTT. Musíte zadat alespoň jednu cílovou skupinu a všechny SAT musí odpovídat jedné z určených cílových skupin.

  1. Na webu Azure Portal přejděte do vaší instance ioT Operations.
  2. V části Součásti vyberte Zprostředkovatele MQTT.
  3. Vyberte kartu Ověřování.
  4. Zvolte existující zásady ověřování nebo vytvořte novou.
  5. Novou metodu přidáte výběrem možnosti Přidat metodu.
  6. V rozevíracím seznamu zvolte typ metody Kubernetes SAT . Pak vyberte Přidat podrobnosti a nakonfigurujte metodu.

Snímek obrazovky znázorňující použití webu Azure Portal k nastavení metody ověřování SAT zprostředkovatele MQTT

Testování ověřování SAT

Ověřování SAT používá pole rozšířeného ověřování MQTT v5. Klient musí nastavit rozšířenou metodu ověřování na K8S-SAT a rozšířená ověřovací data na token.

Použijte například Mosquitto (některá pole vynechána pro stručnost):

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

<TOKEN> Tady je token účtu služby. Pokud chcete získat testovací token, spusťte:

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

Tady je název účtu služby, <SERVICE_ACCOUNT> který jste vytvořili, a <AUDIENCE> je jedním z cílových skupin nakonfigurovaných v prostředku BrokerAuthentication.

Příklad konfigurace podu Kubernetes tak, aby používal ověřování SAT, najdete v tématu Připojení k výchozímu naslouchacímu procesu v clusteru.

V konfiguraci podu serviceAccountName musí pole odpovídat účtu služby přidruženému k použitému tokenu. Pole serviceAccountToken.audience musí být jedním z nakonfigurovaných audiences ve prostředku BrokerAuthentication.

Aktualizace tokenů účtu služby

Tokeny účtu služby jsou platné po omezenou dobu a jsou nastaveny pomocí expirationSeconds. Kubernetes ale token před vypršením platnosti automaticky aktualizuje. Token se aktualizuje na pozadí a klient nemusí dělat nic jiného, než aby ho znovu načítal.

Pokud je například klient pod, který používá token připojený jako svazek, jako v testovacím příkladu ověřování SAT, je nejnovější token k dispozici na stejném místě /var/run/secrets/tokens/broker-sat. Když klient vytvoří nové připojení, může klient načíst nejnovější token a použít ho k ověření. Klient by měl mít také mechanismus pro zpracování neoprávněných chyb MQTT načtením nejnovějšího tokenu a opakováním připojení.

Vlastní ověřování

Rozšiřte ověřování klientů nad rámec zadaných metod ověřování pomocí vlastního ověřování. Je připojitelný , protože služba může být cokoli, pokud dodržuje rozhraní API.

Když se klient připojí ke zprostředkovateli MQTT s povoleným vlastním ověřováním, zprostředkuje požadavek HTTPS na vlastní ověřovací server s přihlašovacími údaji klienta. Server pak odpoví schválením nebo odepřením, včetně autorizačních atributů klienta.

Vytvoření vlastní ověřovací služby

Vlastní ověřovací server se implementuje a nasazuje odděleně od zprostředkovatele MQTT.

Ukázkový vlastní ověřovací server a pokyny jsou k dispozici na GitHubu. Tuto ukázku použijte jako šablonu a výchozí bod pro implementaci vlastní logiky ověřování.

API

Rozhraní API mezi zprostředkovatelem MQTT a vlastním ověřovacím serverem se řídí specifikací rozhraní API pro vlastní ověřování. Specifikace OpenAPI je k dispozici na GitHubu.

Vyžaduje se šifrování HTTPS s protokolem TLS.

Zprostředkovatel MQTT odesílá požadavky obsahující citlivé přihlašovací údaje klienta na vlastní ověřovací server. Aby bylo možné tyto přihlašovací údaje chránit, musí být komunikace mezi zprostředkovatelem MQTT a vlastním ověřovacím serverem šifrovaná pomocí protokolu TLS.

Vlastní ověřovací server musí předložit certifikát serveru a zprostředkovatel MQTT musí mít certifikát důvěryhodné kořenové certifikační autority pro ověření certifikátu serveru. Volitelně může vlastní ověřovací server vyžadovat, aby zprostředkovatel MQTT předložil klientský certifikát k ověření.

Povolení vlastního ověřování pro naslouchací službu

Upravte nastavení metod ověřování v prostředku BrokerAuthentication a specifikujte Vlastní jako platnou metodu ověřování. Pak zadejte parametry potřebné ke komunikaci s vlastním ověřovacím serverem.

  1. Na webu Azure Portal přejděte do vaší instance ioT Operations.

  2. V části Součásti vyberte Zprostředkovatele MQTT.

  3. Vyberte kartu Ověřování.

  4. Zvolte existující zásady ověřování nebo vytvořte novou.

  5. Novou metodu přidáte výběrem možnosti Přidat metodu.

  6. V rozevíracím seznamu zvolte typ metody Vlastní . Pak vyberte Přidat podrobnosti a nakonfigurujte metodu.

    Snímek obrazovky znázorňující použití webu Azure Portal k nastavení metody vlastního ověřování zprostředkovatele MQTT

Použijte vlastní ověření pomocí uživatelského jména a hesla

Přizpůsobené ověřování můžete použít k implementování ověřování pomocí uživatelského jména a hesla. Ukázka ukázkového vlastního ověřovacího serveru je k dispozici pro testování. Podívejte se na ukázku ověřování uživatelského jména a hesla azure IoT Operations MQTT na GitHubu.

Zakázání ověřování

Pro účely testování můžete zakázat ověřování pro port naslouchajícího zprostředkovatele. Nedoporučujeme zakázat ověřování pro produkční prostředí.

  1. Na webu Azure Portal přejděte do vaší instance ioT Operations.
  2. V části Součásti vyberte Zprostředkovatele MQTT.
  3. Ze seznamu vyberte naslouchací komponentu zprostředkovatele, kterou chcete upravit.
  4. Na portu, na kterém chcete zakázat ověřování, vyberte v rozevíracím seznamu Ověřování možnost Žádné .

Klienti se odpojí po vypršení platnosti přihlašovacích údajů.

Zprostředkovatel MQTT odpojí klienty, když jejich přihlašovací údaje vyprší. Odpojení po vypršení platnosti přihlašovacích údajů platí pro všechny klienty, kteří se připojují k front-endům zprostředkovatele MQTT, například:

  • Klienti ověření pomocí SAT se odpojí, když jejich SAT vyprší.
  • Klienti ověření pomocí X.509 se odpojí, když jejich klientský certifikát vyprší.
  • Klienti ověření pomocí vlastního ověřování se odpojí na základě doby vypršení platnosti vrácené z vlastního ověřovacího serveru.

Při odpojení je síťové připojení klienta uzavřeno. Klient neobdrží paket MQTT DISCONNECT, ale zprostředkovatel zaznamená zprávu, že klienta odpojil.

Klienti MQTT v5, kteří jsou ověřeni pomocí SAT a vlastního ověřování, se mohou znovu ověřit s novými přihlašovacími údaji před vypršením počátečních přihlašovacích údajů. Klienti X.509 nemohou znovu autentizovat a musí znovu navázat připojení, protože ověřování probíhá ve vrstvě TLS.

Klienti mohou znovu provést ověření odesláním paketu MQTT v5 AUTH s důvodem ReAuth.

Klienti SAT odesílají klienta AUTH s poli method: K8S-SAT a data: <token>. Vlastní klienti ověřování nastavují metodu a datové pole podle požadavků vlastního ověřovacího serveru.

Úspěšné opětovné ověření aktualizuje vypršení platnosti přihlašovacích údajů klienta s časem vypršení platnosti jeho nových přihlašovacích údajů. Zprostředkovatel odpoví paketem Success AUTH. Neúspěšné ověřování kvůli přechodným problémům, jako je nedostupný vlastní ověřovací server, způsobí, že zprostředkovatel odpoví paketem ContinueAuthentication AUTH. Klient se může později zkusit znovu. Jiná selhání ověřování způsobují, že zprostředkovatel odešle paket DISCONNECT a zavře síťové připojení klienta.

Související obsah

  • Last updated on