Konfigurace ověřování Azure IoT MQ Preview
Důležité
Azure IoT Operations Preview – Služba Azure Arc je aktuálně ve verzi PREVIEW. Tento software ve verzi Preview byste neměli používat v produkčních prostředích.
Právní podmínky, které platí pro funkce Azure, které jsou ve verzi beta, verzi Preview nebo které zatím nejsou veřejně dostupné, najdete v Dodatečných podmínkách použití pro Microsoft Azure verze Preview.
Azure IoT MQ Preview podporuje více metod ověřování pro klienty a každý naslouchací proces můžete nakonfigurovat tak, aby měl vlastní ověřovací systém s prostředky BrokerAuthentication .
Výchozí prostředek BrokerAuthentication
Azure IoT Operations Preview nasadí výchozí prostředek BrokerAuthentication, authn který je propojený s výchozím naslouchacím procesem pojmenovaným listener v azure-iot-operations oboru názvů. Je nakonfigurovaná tak, aby k ověřování používala pouze tokeny účtů služby Kubernetes Service. Pokud ho chcete zkontrolovat, spusťte:
kubectl get brokerauthentication authn -n azure-iot-operations -o yaml
Výstup zobrazuje výchozí prostředek BrokerAuthentication s odebranými metadaty pro stručnost:
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- sat:
audiences: ["aio-mq"]
Pokud chcete změnit konfiguraci, upravte authenticationMethods nastavení v tomto prostředku BrokerAuthentication nebo vytvořte nový úplně nový prostředek BrokerAuthentication s jiným názvem. Pak ho nasaďte pomocí kubectl apply.
Vztah mezi BrokerListener a BrokerAuthentication
BrokerListener a BrokerAuthentication jsou samostatné prostředky, ale jsou propojené pomocí listenerRef. Platí následující pravidla:
- BrokerListener může být propojen pouze s jedním BrokerAuthentication
- BrokerAuthentication může být propojen s více BrokerListeners
- Každá metoda BrokerAuthentication může podporovat více metod ověřování najednou.
Tok ověřování
Pořadí metod ověřování v poli určuje, jak Azure IoT MQ ověřuje klienty. Azure IoT MQ se pokusí ověřit přihlašovací údaje klienta pomocí první zadané metody a iteruje polem, dokud nenajde shodu nebo nedosáhne konce.
Pro každou metodu Azure IoT MQ 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í $sata ověřování X.509 vyžaduje klientský certifikát. Pokud jsou přihlašovací údaje klienta relevantní, Azure IoT MQ ověří, jestli jsou platné. Další informace najdete v části Konfigurace metody ověřování.
V případě vlastního ověřování azure IoT MQ zachází se selháním komunikace s vlastním ověřovacím serverem jako s přihlašovacími údaji, které nejsou relevantní. Toto chování umožňuje Azure IoT MQ vrátit se k jiným metodám, pokud je vlastní 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é.
- Azure IoT MQ buď udělí nebo odmítne přístup k klientovi na základě výsledku toku ověřování.
S několika metodami ověřování má Azure IoT MQ záložní mechanismus. Příklad:
apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
name: authn
namespace: azure-iot-operations
spec:
listenerRef:
- listener
authenticationMethods:
- custom:
# ...
- sat:
# ...
- usernamePassword:
# ...
Předchozí příklad určuje vlastní, SAT a ověřování pomocí uživatelského jména a hesla. Když se klient připojí, Azure IoT MQ se pokusí ověřit klienta pomocí zadaných metod ve vlastním uživatelském jménu SAT > v dané objednávce.>
Azure IoT MQ 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ává je na vlastní ověřovací server.
Pokud vlastní ověřovací server odpoví
PassneboFailvýsledek, tok ověřování skončí. Pokud ale vlastní ověřovací server není k dispozici, Azure IoT MQ se vrátí ke zbývajícím zadaným metodám, přičemž sat je další.Azure IoT MQ se pokusí ověřit přihlašovací údaje jako přihlašovací údaje SAT. Pokud uživatelské jméno MQTT začíná
$satna , Azure IoT MQ vyhodnotí heslo MQTT jako SAT. V opačném případě se zprostředkovatel vrátí k uživatelskému jménu a zkontroluje, jestli je zadané uživatelské jméno a heslo MQTT platné.
Pokud je vlastní ověřovací server nedostupný a všechny následné metody zjistily, že zadané přihlašovací údaje nejsou relevantní, zprostředkovatel odmítne připojení klienta.
Zakázání ověřování
Pro účely testování zakažte ověřování tak, že ho změníte v prostředku BrokerListener.
spec:
authenticationEnabled: false
Konfigurace metody ověřování
Další informace o jednotlivých možnostech ověřování najdete v následujících částech:
Uživatelské jméno a heslo
Každý klient má následující požadované vlastnosti:
- Username
- Heslo (kódované PBKDF2)
- Atributy pro autorizaci
Začněte například s clients.toml identitami a kódovanými hesly PBKDF2.
# Credential #1
# username: client1
# password: password
[client1]
password = "$pbkdf2-sha512$i=100000,l=64$HqJwOCHweNk1pLryiu3RsA$KVSvxKYcibIG5S5n55RvxKRTdAAfCUtBJoy5IuFzdSZyzkwvUcU+FPawEWFPn+06JyZsndfRTfpiEh+2eSJLkg"
[client1.attributes]
floor = "floor1"
site = "site1"
# Credential #2
# username: client2
# password: password2
[client2]
password = "$pbkdf2-sha512$i=100000,l=64$+H7jXzcEbq2kkyvpxtxePQ$jTzW6fSesiuNRLMIkDDAzBEILk7iyyDZ3rjlEwQap4UJP4TaCR+EXQXNukO7qNJWlPPP8leNnJDCBgX/255Ezw"
[client2.attributes]
floor = "floor2"
site = "site1"
Pokud chcete zakódovat heslo pomocí PBKDF2, použijte rozšíření Azure IoT Operations CLI, které obsahuje az iot ops mq get-password-hash tento příkaz. Generuje hodnotu hash hesla PBKDF2 z fráze hesla pomocí algoritmu SHA-512 a 128bitové randomizované soli.
az iot ops mq get-password-hash --phrase TestPassword
Výstup zobrazuje hodnotu hash hesla PBKDF2, která se má zkopírovat:
{
"hash": "$pbkdf2-sha512$i=210000,l=64$4SnaHtmi7m++00fXNHMTOQ$rPT8BWv7IszPDtpj7gFC40RhhPuP66GJHIpL5G7SYvw+8rFrybyRGDy+PVBYClmdHQGEoy0dvV+ytFTKoYSS4A"
}
Potom soubor uložte jako passwords.toml a naimportujte ho do tajného kódu Kubernetes pod tímto klíčem.
kubectl create secret generic passwords-db --from-file=passwords.toml -n azure-iot-operations
Zahrnutí odkazu na tajný klíč do vlastního prostředku BrokerAuthentication
spec:
authenticationMethods:
- usernamePassword:
secretName: passwords-db
Může trvat několik minut, než se změny projeví.
Službu Azure Key Vault můžete použít ke správě tajných kódů pro Azure IoT MQ místo tajných kódů Kubernetes. Další informace najdete v tématu Správa tajných kódů pomocí služby Azure Key Vault nebo tajných kódů Kubernetes.
Klientský certifikát X.509
Požadavky
- Azure IoT MQ nakonfigurovaný s povoleným protokolem TLS.
- Rozhraní příkazového řádku krok
- Klientské certifikáty a vydávající řetěz certifikátů v souborech PEM. Pokud žádné nemáte, vygenerujte je pomocí rozhraní příkazového řádku Kroku.
- Znalost kryptografie veřejného klíče a termínů, jako jsou kořenová certifikační autorita, privátní klíč a zprostředkující certifikáty.
Podporují se klíče EC i RSA, ale všechny certifikáty v řetězu musí používat stejný algoritmus klíče. Pokud importujete vlastní certifikáty certifikační autority, ujistěte se, že klientský certifikát používá stejný algoritmus klíče jako certifikační autority.
Import certifikátu důvěryhodné kořenové certifikační autority klienta
K ověření klientského certifikátu se vyžaduje certifikát důvěryhodné kořenové certifikační autority. Chcete-li importovat kořenový certifikát, který lze použít k ověření klientských certifikátů, nejprve naimportujte certifikát PEM jako ConfigMap pod klíčem client_ca.pem. Klientské certifikáty musí být kořenové v této certifikační autoritě, aby je Služba Azure IoT MQ ověřila.
kubectl create configmap client-ca --from-file=client_ca.pem -n azure-iot-operations
Pokud chcete zkontrolovat, jestli je kořenový certifikát certifikační autority správně importovaný, spusťte kubectl describe configmappříkaz . Výsledek ukazuje 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
====
client_ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIBmzCCAUGgAwIBAgIQVAZ2I0ydpCut1imrk+fM3DAKBggqhkjOPQQDAjAsMRAw
...
t2xMXcOTeYiv2wnTq0Op0ERKICHhko2PyCGGwnB2Gg==
-----END CERTIFICATE-----
BinaryData
====
Import mapování certifikátů na atribut
Pokud chcete použít zásady autorizace pro klienty používající vlastnosti na certifikátech X.509, vytvořte soubor TOML mapování certifikátu na atribut a naimportujte ho jako tajný klíč Kubernetes pod klíčem x509Attributes.toml. Tento soubor mapuje název subjektu klientského certifikátu na atributy, které lze použít v zásadách autorizace. To se vyžaduje i v případě, že nepoužíváte zásady autorizace.
kubectl create secret generic x509-attributes --from-file=x509Attributes.toml -n azure-iot-operations
Další informace o syntaxi souboru atributů najdete v tématu Autorizace klientů používajících ověřování X.509.
Stejně jako u ověřování pomocí uživatelského jména a hesla můžete použít Azure Key Vault ke správě tohoto tajného klíče místo tajných kódů Kubernetes. Další informace najdete v tématu Správa tajných kódů pomocí služby Azure Key Vault nebo tajných kódů Kubernetes.
Povolení ověřování klientů X.509
Nakonec po importu certifikátu důvěryhodné kořenové certifikační autority klienta a mapování atributu certifikátu povolte ověřování klientů X.509 přidáním x509 jedné z metod ověřování jako součásti prostředku BrokerAuthentication propojeného s naslouchacím procesem s povoleným protokolem TLS. Příklad:
spec:
authenticationMethods:
- x509:
trustedClientCaCert: client-ca
attributes:
secretName: x509-attributes
Připojení klienta mosquitto do Azure IoT MQ Preview s klientským certifikátem X.509
Klient, jako je mosquitto, potřebuje tři soubory, aby se mohl připojit k Azure IoT MQ pomocí protokolu TLS a ověřování klientů X.509. Příklad:
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<IOT_MQ_EXTERNAL_IP>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile chain.pem
V tomto příkladu:
- Parametr
--certurčuje soubor PEM klientského certifikátu. - Parametr
--keyurčuje soubor PEM privátního klíče klienta. - Třetí parametr
--cafileje nejsložitější: důvěryhodná databáze certifikátů používaná pro dva účely:- Když se klient mosquitto připojí k Azure IoT MQ přes TLS, ověří certifikát serveru. Vyhledá kořenové certifikáty v databázi a vytvoří důvěryhodný řetěz certifikátu serveru. Z tohoto důvodu musí být kořenový certifikát serveru zkopírován do tohoto souboru.
- Když Azure IoT MQ požaduje klientský certifikát od klienta mosquitto, vyžaduje také platný řetěz certifikátů, který se má odeslat na server. Parametr
--certříká moskvitu, který certifikát se má odeslat, ale nestačí. Azure IoT MQ nemůže ověřit samotný certifikát, protože potřebuje také zprostředkující certifikát. Mosquitto používá soubor databáze k sestavení nezbytného řetězu certifikátů. Aby to bylo podporováno,cafilemusí obsahovat zprostředkující i kořenové certifikáty.
Principy toku ověřování klientů X.509 v Azure IoT MQ Preview
Postup pro tok ověřování klientů:
- Když je zapnuté ověřování klientů X.509, musí připojení klienti předložit svůj klientský certifikát a všechny zprostředkující certifikáty, aby služba Azure IoT MQ sestavila řetěz certifikátů s jedním z nakonfigurovaných důvěryhodných certifikátů.
- Nástroj pro vyrovnávání zatížení směruje komunikaci na jednoho z front-endových zprostředkovatelů.
- Jakmile front-endový zprostředkovatel obdržel klientský certifikát, pokusí se vytvořit řetěz certifikátů, který je rootovaný na jednom z nakonfigurovaných certifikátů. Certifikát se vyžaduje pro metodu handshake protokolu TLS. Pokud front-endový zprostředkovatel úspěšně vytvořil řetěz a prezentovaný řetězec je ověřený, dokončí metodu handshake protokolu TLS. Připojovací klient dokáže odesílat pakety MQTT do front-endu prostřednictvím vytvořeného kanálu TLS.
- Kanál TLS je otevřený, ale ověřování nebo autorizace klienta ještě není dokončené.
- Klient pak odešle paket CONNECT do Azure IoT MQ.
- Paket CONNECT se znovu směruje do front-endu.
- Front-end shromažďuje všechny přihlašovací údaje, které klient dosud zobrazil, jako jsou pole uživatelského jména a hesla, ověřovací data z paketu CONNECT a řetěz klientských certifikátů prezentovaný během metody handshake protokolu TLS.
- 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.
- Ověřovací služba používá nakonfigurovaná autorizační pravidla k určení atributů, které mají připojující se klienti. Tyto atributy určují, jaké operace může klient provést, včetně samotného paketu CONNECT.
- Ověřovací služba vrací rozhodnutí o front-endovém zprostředkovatele.
- 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 určené autorizačními pravidly.
Tokeny účtu služby Kubernetes Service
Tokeny účtů služby Kubernetes Service (SAT) jsou webové tokeny JSON přidružené k účtům služby Kubernetes Service. Klienti prezentují SAT zprostředkovateli Azure IoT MQ MQTT, aby se ověřili sami.
Azure IoT MQ používá vázané tokeny účtu služby, které jsou podrobně popsány v tématu Co uživatelé GKE potřebují vědět o příspěvku o nových tokenech účtu služby Kubernetes . Tady jsou nejdůležitější funkce z příspěvku:
Spuštěno v Kubernetes 1.13 a stává se výchozím formátem ve verzi 1.21, vázané tokeny řeší všechny omezené funkce starších tokenů a další:
- Samotné tokeny jsou těžší ukrást a zneužít; jsou vázané na čas, cílovou skupinu a objektově vázané.
- Přijímají standardizovaný formát: OpenID Připojení (OIDC) s úplným zjišťováním OIDC, což poskytovatelům služeb usnadňuje jejich přijetí.
- Distribuují se do podů bezpečněji pomocí nového typu svazku s projektovaným kubeletem.
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á, nejde použít SAT.
Vytvoření obchodního vztahu 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
Přidání atributů pro autorizaci
Ověřování klientů prostřednictvím SAT může volitelně obsahovat poznámky SAT s atributy, které se mají použít s vlastními zásadami autorizace. Další informace najdete v tématu Autorizace klientů, kteří používají tokeny účtů služby Kubernetes.
Povolení ověřování tokenu účtu služby (SAT)
authenticationMethods Upravte nastavení v prostředku BrokerAuthentication tak, aby bylo možné zadat sat jako platnou metodu ověřování. Určuje audiences seznam platných cílových skupin pro tokeny. Zvolte jedinečné hodnoty, které identifikují zprostředkovou službu Azure IoT MQ. Musíte zadat alespoň jednu cílovou skupinu a všechny SAT musí odpovídat jedné z určených cílových skupin.
spec:
authenticationMethods:
- sat:
audiences: ["aio-mq", "my-audience"]
Použijte změny s kubectl apply. Může trvat několik minut, než se změny projeví.
Testování ověřování SAT
Ověřování SAT se musí použít z klienta ve stejném clusteru jako Azure IoT MQ. Následující příkaz určuje pod, který má klienta mosquitto a připojí sat vytvořenou v předchozích krocích k podu.
apiVersion: v1
kind: Pod
metadata:
name: mqtt-client
namespace: azure-iot-operations
spec:
serviceAccountName: mqtt-client
containers:
- image: efrecon/mqtt-client
name: mqtt-client
command: ["sleep", "infinity"]
volumeMounts:
- name: mqtt-client-token
mountPath: /var/run/secrets/tokens
volumes:
- name: mqtt-client-token
projected:
sources:
- serviceAccountToken:
path: mqtt-client-token
audience: my-audience
expirationSeconds: 86400
serviceAccountName V této části musí pole v konfiguraci podu odpovídat účtu služby přidruženému k použitému tokenu. Pole serviceAccountToken.audience v konfiguraci podu musí být také jedním z audiences nakonfigurovaných prostředků BrokerAuthentication.
Po vytvoření podu spusťte v podu prostředí:
kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh
Token se připojí k cestě zadané v konfiguraci /var/run/secrets/tokens v předchozím příkladu. Načtěte token a použijte ho k ověření.
token=$(cat /var/run/secrets/tokens/mqtt-client-token)
mosquitto_pub -h aio-mq-dmqtt-frontend -V mqttv5 -t hello -m world -u '$sat' -P "$token"
Uživatelské jméno MQTT musí být nastaveno na $sathodnotu . Heslo MQTT musí být nastaveno na samotné SAT.
Aktualizace tokenů účtu služby
Tokeny účtu služby jsou platné po omezenou dobu a konfigurují s 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 podem, který používá token připojený jako svazek, například v testovacím příkladu ověřování SAT, je nejnovější token k dispozici ve stejné cestě /var/run/secrets/tokens/mqtt-client-token. Při vytváření nového 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 možné ji připojit, protože služba může být cokoli, pokud dodržuje rozhraní API.
Když se klient připojí k Azure IoT MQ a povolí se vlastní ověřování, Azure IoT MQ deleguje ověření přihlašovacích údajů klienta na vlastní ověřovací server s požadavkem HTTP spolu se všemi přihlašovacími údaji, které klient prezentuje. Vlastní ověřovací server odpoví schválením nebo odepřením klienta s atributy klienta pro autorizaci.
Vytvoření vlastní ověřovací služby
Vlastní ověřovací server se implementuje a nasazuje odděleně od Azure IoT MQ.
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í.
rozhraní API
Rozhraní API mezi Azure IoT MQ 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.
Azure IoT MQ 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 Azure IoT MQ a vlastním ověřovacím serverem šifrovaná pomocí protokolu TLS.
Vlastní ověřovací server musí předložit certifikát serveru a Azure IoT MQ 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 Azure IoT MQ předložil klientský certifikát, aby se ověřil sám.
Povolení vlastního ověřování pro naslouchací proces
authenticationMethods Upravte nastavení v prostředku BrokerAuthentication tak, aby bylo možné zadat custom jako platnou metodu ověřování. Pak zadejte parametry potřebné ke komunikaci s vlastním ověřovacím serverem.
Tento příklad ukazuje všechny možné parametry. Přesné požadované parametry závisí na požadavcích jednotlivých vlastních serverů.
spec:
authenticationMethods:
- custom:
# Endpoint for custom authentication requests. Required.
endpoint: https://auth-server-template
# Trusted CA certificate for validating custom authentication server certificate.
# Required unless the server certificate is publicly-rooted.
caCert: custom-auth-ca
# Authentication between Azure IoT MQ with the custom authentication server.
# The broker may present X.509 credentials or no credentials to the server.
auth:
x509:
secretName: custom-auth-client-cert
namespace: azure-iot-operations
# Optional additional HTTP headers that the broker will send to the
# custom authentication server.
headers:
header_key: header_value