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

Zprostředkovatel MQTT 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 . Seznam dostupných nastavení najdete v referenčních informacích k rozhraní API pro ověřování zprostředkovatele.

Propojení BrokerListener a BrokerAuthentication

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

• Každý brokerListener může mít více portů. Každý port může být propojený s prostředkem BrokerAuthentication .
• Každá metoda BrokerAuthentication může podporovat více metod ověřování najednou.

Chcete-li propojit 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 BrokerAuthentication

Azure IoT Operations Preview nasadí výchozí prostředek BrokerAuthentication propojený default s výchozím naslouchacím procesem azure-iot-operations v oboru názvů. Je nakonfigurovaná tak, aby k ověřování používala pouze tokeny účtů služby Kubernetes Service.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-09-15-preview' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-09-15-preview' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-09-15-preview' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
          ]
        }
      }
    ]
  }
}

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

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

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: BrokerAuthentication
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - aio-internal

Tok ověřování

Pořadí metod ověřování v poli 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 polem, 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 ověří, jestli jsou platné. Další informace najdete v části Konfigurace metody ověřování.

U vlastního ověřování zprostředkovatel MQTT zachází s chybou komunikace s vlastním ověřovacím serverem jako s přihlašovacími údaji, které nejsou relevantní. Toto chování umožňuje zprostředkovateli MQTT 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é.
• Zprostředkovatel MQTT buď udělí nebo odmítne přístup k klientovi na základě výsledku ověřovacího toku.

S několika metodami ověřování má zprostředkovatel MQTT záložní mechanismus. Příklad:

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

Předchozí příklad určuje vlastní a SAT. Když se klient připojí, zprostředkovatel MQTT se pokusí ověřit klienta pomocí zadaných metod v daném pořadí , 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ává je na vlastní ověřovací server.
2. Pokud vlastní ověřovací server odpoví Pass nebo Fail výsledek, tok ověřování skončí. Pokud ale vlastní ověřovací server není dostupný, vrátí se zprostředkovatel MQTT zpě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 uživatelské jméno MQTT začíná K8S-SATna , zprostředkovatel MQTT vyhodnotí heslo MQTT jako SAT.

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.

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řidání metody ověřování do zásady:

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

resource aioInstance 'Microsoft.IoTOperations/instances@2024-09-15-preview' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-09-15-preview' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-09-15-preview' = {
  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: {
          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'
            }
          }
        }
      }
    ]
  }
}

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

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
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:
        authorizationAttributes:
          trustedClientCaCert: client-ca
          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

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

Další informace o povolení nastavení zabezpečení konfigurací služby Azure Key Vault a povolením identit úloh najdete v tématu Povolení nastavení zabezpečení v nasazení Azure IoT Operations Preview.

X.509

K ověření klientského certifikátu se vyžaduje certifikát důvěryhodné kořenové certifikační autority. Klientské certifikáty musí být kořenové v této certifikační autoritě, aby je zprostředkovatel MQTT ověřil. 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. Chcete-li importovat kořenový certifikát, který lze použít k ověření klientských certifikátů, naimportujte certifikát PEM jako Objekt ConfigMap pod klíčem client_ca.pem. Příklad:

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-----
<Certificate>
-----END CERTIFICATE-----


BinaryData
====

Po importu certifikátu důvěryhodné kořenové certifikační autority klienta a mapování atributů certifikátu povolte ověření klienta X.509 tak, že ho přidáte jako jednu z metod ověřování jako součást prostředku BrokerAuthentication propojeného s naslouchacím procesem s povoleným protokolem TLS.

Atributy certifikátu pro autorizaci

Atributy X.509 je možné zadat v prostředku BrokerAuthentication a slouží k autorizaci klientů na základě jejich vlastností certifikátu. Atributy jsou definovány v authorizationAttributes poli.

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

resource aioInstance 'Microsoft.IoTOperations/instances@2024-09-15-preview' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-09-15-preview' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-09-15-preview' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'X509'
        x509Settings: {
          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'
              }
            }
          }
        }
      }
    ]
  }
}

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

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        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

V tomto příkladu každý klient, který má certifikát vydaný kořenovou certifikační autoritou nebo zprostředkující certifikační autoritou CN = Contoso Root CA Cert, OU = Engineering, C = US CN = Contoso Intermediate CA , obdrží uvedené atributy. Kromě toho inteligentní ventilátor 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 lze použít pro klienty používající certifikáty X.509 s těmito atributy. Další informace najdete v tématu Autorizace klientů, kteří používají ověřování X.509.

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

Klient, jako je mosquitto, potřebuje tři soubory, aby se mohl připojit ke zprostředkovateli MQTT pomocí protokolu TLS a ověřování klienta 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 --cert určuje soubor PEM klientského certifikátu.
• Parametr --key určuje soubor PEM privátního klíče klienta.
• Třetí parametr --cafile je nejsložitější: důvěryhodná databáze certifikátů používaná pro dva účely:
  • Když se klient mosquitto připojí ke zprostředkovateli MQTT přes protokol 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ž zprostředkovatel MQTT požaduje klientský certifikát od klienta mosquitto, vyžaduje také platný řetěz certifikátů k odeslání na server. Parametr --cert říká moskvitu, který certifikát se má odeslat, ale nestačí. Zprostředkovatel MQTT nemůže tento certifikát ověřit sám, 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, cafile musí obsahovat zprostředkující i kořenové certifikáty.

Principy toku ověřování klienta X.509 zprostředkovatele MQTT

Postup pro tok ověřování klientů:

1. Pokud 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 zprostředkovatel MQTT vytvořil řetěz certifikátů kořenový 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ž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.
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 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.
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í se klienti. Tyto atributy určují, jaké operace může klient provést, včetně samotného paketu CONNECT.
10. Ověřovací služba vrací rozhodnutí o front-endovém zprostředkovatele.
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 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 MQTT, aby se ověřili.

Zprostředkovatel MQTT používá tokeny účtu vázané 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 Connect (OIDC) s úplným zjišťováním OIDC, což usnadňuje poskytovatelům služeb 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 ServiceAccountToken jako platnou metodu ověřování. Určuje audiences 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.

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

resource aioInstance 'Microsoft.IoTOperations/instances@2024-09-15-preview' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-09-15-preview' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-09-15-preview' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

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

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

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

Ověřování SAT musí být použito z klienta ve stejném clusteru jako zprostředkovatel MQTT. Jsou povolena pouze pole rozšířeného ověřování. Nastavte metodu ověřování na K8S-SAT token a ověřovací data.

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

V prostředí podu spusťte následující příkaz, který publikuje zprávu do zprostředkovatele:

mosquitto_pub --host aio-broker --port 18883 --message "hello" --topic "world" --debug --cafile /var/run/certs/ca.crt -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data $(cat /var/run/secrets/tokens/broker-sat)

Výstup by měl vypadat zhruba takto:

Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending PUBLISH (d0, q0, r0, m1, 'world', ... (5 bytes))
Client (null) sending DISCONNECT

Klient mosquitto používá token účtu služby připojený /var/run/secrets/tokens/broker-sat k ověření u zprostředkovatele. Token je platný 24 hodin. Klient také používá výchozí kořenový certifikát certifikační autority připojený k /var/run/certs/ca.crt ověření řetězu certifikátů TLS zprostředkovatele.

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í ke zprostředkovateli MQTT a povolí se vlastní ověřování, bude zprostředkovatel MQTT delegovat 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 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í.

rozhraní 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, 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:
    - 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

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

Pro účely testování můžete zakázat ověřování pro port naslouchacího procesu zprostředkovatele. Zakázání ověřování se nedoporučuje pro produkční prostředí.

Po vypršení platnosti přihlašovacích údajů se klient odpojí

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, včetně:

• Klienti ověření pomocí SAT se odpojí, když vyprší jejich platnost SAT.
• 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 odpojil klienta.

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

Klienti můžou znovu provést ověření odesláním paketu MQTT v5 AUTH.

Klienti SAT odesílají klienta AUTH s poli method: K8S-SAT, 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 časem vypršení platnosti jeho nových přihlašovacích údajů a zprostředkovatel odpoví paketem Success AUTH . Neúspěšné ověřování kvůli přechodným problémům způsobuje, že zprostředkovatel reaguje paketem ContinueAuthentication AUTH . Například vlastní ověřovací server není k dispozici. 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

• Informace o prostředku BrokerListener
• Konfigurace autorizace pro BrokerListener