Megosztás a következőn keresztül:

MQTT-közvetítő hitelesítésének konfigurálása

  • Cikk

Fontos

Az Azure IoT Operations Előzetes verziója – az Azure Arc által engedélyezett verzió jelenleg előzetes verzióban érhető el. Ezt az előzetes verziójú szoftvert nem szabad éles környezetben használni.

Ha egy általánosan elérhető kiadás elérhetővé válik, üzembe kell helyeznie egy új Azure IoT Operations-telepítést. Az előzetes verziójú telepítés nem frissíthető.

A bétaverziójú, előzetes verziójú vagy másként még általánosan nem elérhető Azure-szolgáltatások jogi feltételeit lásd: Kiegészítő használati feltételek a Microsoft Azure előzetes verziójú termékeihez.

Az MQTT-közvetítő több hitelesítési módszert is támogat az ügyfelek számára, és konfigurálhatja az egyes figyelők számára, hogy saját hitelesítési rendszerük legyen BrokerAuthentication-erőforrásokkal. Az elérhető beállítások listáját a Broker Authentication API-referencia tartalmazza.

A BrokerListener és a BrokerAuthentication közötti kapcsolatra a következő szabályok vonatkoznak:

  • Minden BrokerListener több portot is tartalmazhat. Minden port csatolható BrokerAuthentication-erőforráshoz.
  • Minden BrokerAuthentication egyszerre több hitelesítési módszert is támogat.

A BrokerListener és a BrokerAuthentication erőforrás összekapcsolásához adja meg a authenticationRef ports BrokerListener erőforrás beállításának mezőjét. További információ: BrokerListener erőforrás.

Alapértelmezett BrokerAuthentication erőforrás

Az Azure IoT Operations Preview üzembe helyez egy alapértelmezett BrokerAuthentication-erőforrást , amely default a névtér alapértelmezett figyelőjével azure-iot-operations van társítva. Úgy van konfigurálva, hogy csak Kubernetes-szolgáltatásfiók-jogkivonatokat (SAT-okat) használjon a hitelesítéshez.

Fontos

Az alapértelmezett BrokerAuthentication erőforrás szolgáltatásfiók-jogkivonatának (SAT) hitelesítési módszere szükséges ahhoz, hogy az Azure IoT-műveletek összetevői megfelelően működjenek. Kerülje az alapértelmezett BrokerAuthentication erőforrás frissítését vagy törlését .

  1. Az Azure Portalon keresse meg az IoT Operations-példányt.

  2. Az Azure IoT Operations-erőforrások között válassza az MQTT Broker lehetőséget.

  3. Válassza a Hitelesítés lapot.

  4. A hitelesítési házirendek listájában válassza ki az alapértelmezett házirendnevet.

    Képernyőkép az Azure Portalról az alapértelmezett MQTT-közvetítő hitelesítési szabályzatának megtekintéséhez.

Új hitelesítési módszerek hozzáadásához válassza a Metódus hozzáadása lehetőséget.

Hitelesítési folyamat

A tömb hitelesítési módszereinek sorrendje határozza meg, hogy az MQTT-közvetítő hogyan hitelesíti az ügyfeleket. Az MQTT-közvetítő megpróbálja hitelesíteni az ügyfél hitelesítő adatait az első megadott módszerrel, és végigvezeti a tömbön, amíg egyezést nem talál, vagy el nem éri a végét.

Az MQTT-közvetítő minden metódus esetében először ellenőrzi, hogy az ügyfél hitelesítő adatai relevánsak-e az adott metódushoz. A SAT-hitelesítéshez például egy felhasználónévre K8S-SATvan szükség, az X.509-hitelesítéshez pedig ügyféltanúsítvány szükséges. Ha az ügyfél hitelesítő adatai relevánsak, az MQTT-közvetítő ellenőrzi, hogy érvényesek-e. További információ: A hitelesítési módszer konfigurálása szakasz.

Egyéni hitelesítés esetén az MQTT-közvetítő az egyéni hitelesítési kiszolgálóval való kommunikáció sikertelenségét nem releváns hitelesítő adatokként kezeli. Ez a viselkedés lehetővé teszi, hogy az MQTT-közvetítő visszaessen más módszerekre, ha az egyéni kiszolgáló nem érhető el.

A hitelesítési folyamat a következő esetekben fejeződik be:

  • Az alábbi feltételek egyike igaz:
    • Az ügyfél hitelesítő adatai relevánsak és érvényesek az egyik metódushoz.
    • Az ügyfél hitelesítő adatai egyik módszerhez sem relevánsak.
    • Az ügyfél hitelesítő adatai relevánsak, de bármelyik metódus esetében érvénytelenek.
  • Az MQTT-közvetítő a hitelesítési folyamat eredménye alapján engedélyezi vagy tagadja az ügyfélhez való hozzáférést.

Több hitelesítési módszer esetén az MQTT-közvetítő tartalék mechanizmussal rendelkezik. Példa:

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:
        # ...

A korábbi példa egyéni és SAT értékeket határoz meg. Amikor egy ügyfél csatlakozik, az MQTT-közvetítő megkísérli hitelesíteni az ügyfelet az adott rendelésben megadott egyéni, majd SAT metódusokkal.

  1. Az MQTT-közvetítő ellenőrzi, hogy az ügyfél hitelesítő adatai érvényesek-e az egyéni hitelesítésre. Mivel az egyéni hitelesítés egy külső kiszolgálóra támaszkodik a hitelesítő adatok érvényességének meghatározásához, a közvetítő az egyéni hitelesítés szempontjából releváns összes hitelesítő adatot figyelembe veszi, és továbbítja azokat az egyéni hitelesítési kiszolgálónak.
  2. Ha az egyéni hitelesítési kiszolgáló válaszul vagy Fail eredménnyel Pass válaszol, a hitelesítési folyamat véget ér. Ha azonban az egyéni hitelesítési kiszolgáló nem érhető el, akkor az MQTT-közvetítő visszaesik a többi megadott metódusra, és a SAT lesz a következő.
  3. Az MQTT-közvetítő SAT-hitelesítő adatokként próbálja hitelesíteni a hitelesítő adatokat. Ha az MQTT felhasználónév a következővel K8S-SATkezdődik, az MQTT-közvetítő SAT-ként értékeli ki az MQTT-jelszót.

Ha az egyéni hitelesítési kiszolgáló nem érhető el, és az összes további módszer megállapította, hogy a megadott hitelesítő adatok nem relevánsak, akkor a közvetítő tagadja az ügyfélkapcsolatot.

Hitelesítési módszer konfigurálása

Hitelesítési módszereket, például X.509, SAT vagy egyéni hitelesítési szabályzatokat adhat hozzá.

Hitelesítési módszer hozzáadása szabályzathoz:

  1. Az Azure Portalon keresse meg az IoT Operations-példányt.

  2. Az Azure IoT Operations-erőforrások között válassza az MQTT Broker lehetőséget.

  3. Válassza a Hitelesítés lapot.

  4. Válasszon ki egy meglévő hitelesítési szabályzatot, vagy hozzon létre egy újat.

  5. Adjon hozzá egy új metódust a Metódus hozzáadása gombra kattintva.

  6. Válassza ki a metódus típusát a legördülő listából, majd válassza a Részletek hozzáadása lehetőséget a metódus konfigurálásához.

    Képernyőkép az Azure Portalról egy MQTT-közvetítő hitelesítési szabályzatának hozzáadásához.

Ha többet szeretne megtudni az egyes hitelesítési lehetőségekről, tekintse meg az egyes metódusok következő szakaszait.

A biztonságos beállítások Azure Key Vault konfigurálásával és a számítási feladatok identitásainak engedélyezésével történő engedélyezésével kapcsolatos további információkért lásd : Biztonságos beállítások engedélyezése az Azure IoT Operations előzetes verziójában.

X.509

Az ügyféltanúsítvány érvényesítéséhez megbízható legfelső szintű hitelesítésszolgáltatói tanúsítvány szükséges. A hitelesítéshez az ügyféltanúsítványokat ebben a hitelesítésszolgáltatóban kell létrehozni. Az EC és az RSA kulcsok is támogatottak, de a lánc összes tanúsítványának ugyanazt a kulcsalgoritmust kell használnia. Ha saját hitelesítésszolgáltatói tanúsítványokat importál, győződjön meg arról, hogy az ügyféltanúsítvány ugyanazt a kulcsalgoritmust használja, mint a hitelesítésszolgáltatók. Az ügyféltanúsítványok ellenőrzésére használható főtanúsítvány importálásához importálja a PEM tanúsítványt konfigurációtérképként a kulcs client_ca.pemalatt. Példa:

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

A legfelső szintű hitelesítésszolgáltatói tanúsítvány megfelelő importálásának ellenőrzéséhez futtassa a következőt kubectl describe configmap: Az eredmény a PEM-tanúsítványfájl ugyanazzal a base64 kódolásával jelenik meg.

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
====

Miután importálta a megbízható ügyfél legfelső szintű hitelesítésszolgáltatói tanúsítványát és a tanúsítvány–attribútum megfeleltetést, engedélyezze az X.509-ügyfélhitelesítést úgy, hogy hozzáadja az egyik hitelesítési módszerként egy TLS-kompatibilis figyelőhöz társított BrokerAuthentication-erőforrás részeként.

Tanúsítványattribútumok az engedélyezéshez

Az X.509-attribútumok megadhatók a BrokerAuthentication erőforrásban, és a tanúsítványtulajdonságuk alapján engedélyezik az ügyfeleket. Az attribútumok a authorizationAttributes mezőben vannak definiálva.

  1. Az Azure Portalon keresse meg az IoT Operations-példányt.

  2. Az Azure IoT Operations-erőforrások között válassza az MQTT Broker lehetőséget.

  3. Válassza a Hitelesítés lapot.

  4. Válasszon ki egy meglévő hitelesítési szabályzatot, vagy hozzon létre egy újat.

  5. Adjon hozzá egy új metódust a Metódus hozzáadása gombra kattintva.

  6. Válassza ki az X.509 metódustípust a legördülő listából, majd válassza a Részletek hozzáadása lehetőséget a metódus konfigurálásához.

    Képernyőkép az Azure Portalról az MQTT Broker X.509 hitelesítési módszer beállításához.

Ebben a példában minden ügyfél, amelynek tanúsítványát a legfelső szintű hitelesítésszolgáltató vagy egy köztes hitelesítésszolgáltató CN = Contoso Root CA Cert, OU = Engineering, C = US CN = Contoso Intermediate CA állította ki, megkapja a felsorolt attribútumokat. Emellett az intelligens ventilátor a hozzá tartozó attribútumokat is megkapja.

Az attribútumok egyeztetése mindig a levélügyfél tanúsítványából indul ki, majd végighalad a láncon. Az attribútum-hozzárendelés az első egyezés után leáll. Az előző példában még akkor sem kapja meg a társított attribútumokat, ha smart-fan a köztes tanúsítvánnyal CN = Contoso Intermediate CArendelkezik.

Az engedélyezési szabályok X.509-tanúsítványokat használó ügyfelekre alkalmazhatók ezekkel az attribútumokkal. További információ: X.509-hitelesítést használó ügyfelek engedélyezése.

Mosquitto-ügyfél csatlakoztatása az MQTT-közvetítőhöz X.509 ügyféltanúsítvánnyal

Egy olyan ügyfélnek, mint a mosquitto, három fájlra van szüksége ahhoz, hogy TLS-lel és X.509-ügyfélhitelesítéssel tudjon csatlakozni az MQTT-közvetítőhöz. Példa:

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

A példában:

  • A --cert paraméter az ügyféltanúsítvány PEM-fájljának megadása.
  • A --key paraméter az ügyfél titkos kulcsú PEM-fájljának megadására használható.
  • A harmadik paraméter --cafile a legösszetettebb: a megbízható tanúsítványadatbázis, amelyet két célra használnak:
    • Amikor a mosquitto-ügyfél TLS-en keresztül csatlakozik az MQTT-közvetítőhöz, ellenőrzi a kiszolgálótanúsítványt. Az adatbázisban főtanúsítványokat keres, hogy megbízható láncot hozzon létre a kiszolgálótanúsítványhoz. Emiatt a kiszolgáló főtanúsítványát ebbe a fájlba kell másolni.
    • Amikor az MQTT-közvetítő ügyféltanúsítványt kér a mosquitto-ügyféltől, érvényes tanúsítványláncot is igényel a kiszolgálónak való küldéshez. A --cert paraméter jelzi a mosquitto számára, hogy melyik tanúsítványt küldje el, de ez nem elég. Az MQTT-közvetítő nem tudja egyedül ellenőrizni ezt a tanúsítványt, mert a köztes tanúsítványra is szüksége van. A Mosquitto az adatbázisfájl használatával hozza létre a szükséges tanúsítványláncot. Ennek támogatásához a cafile köztes és a főtanúsítványt is tartalmaznia kell.

Az MQTT Broker X.509 ügyfélhitelesítési folyamatának ismertetése

Az X.509-ügyfélhitelesítési folyamat ábrája.

Az ügyfél-hitelesítési folyamat lépései a következők:

  1. Ha az X.509-ügyfélhitelesítés be van kapcsolva, a csatlakozó ügyfeleknek be kell mutatniuk az ügyféltanúsítványukat és a köztes tanúsítványokat, hogy az MQTT-közvetítő létrehozhassa az egyik konfigurált megbízható tanúsítványához gyökerező tanúsítványláncot.
  2. A terheléselosztó irányítja a kommunikációt az egyik előtérbeli közvetítő felé.
  3. Miután az előtérbeli közvetítő megkapta az ügyféltanúsítványt, megpróbál létrehozni egy tanúsítványláncot, amely az egyik konfigurált tanúsítványhoz gyökerezik. A tanúsítvány TLS-kézfogáshoz szükséges. Ha az előtérbeli közvetítő sikeresen létrehozott egy láncot, és a bemutatott lánc ellenőrzése megtörtént, befejezi a TLS-kézfogást. A csatlakozó ügyfél képes MQTT-csomagokat küldeni az előtérbe a beépített TLS-csatornán keresztül.
  4. A TLS-csatorna nyitva van, de az ügyfélhitelesítés vagy -engedélyezés még nem fejeződött be.
  5. Az ügyfél ezután egy CONNECT-csomagot küld az MQTT-közvetítőnek.
  6. A CONNECT-csomag ismét egy előtérbe kerül.
  7. Az előtér összegyűjti az ügyfél által eddig bemutatott összes hitelesítő adatot, például a felhasználónév- és jelszómezőket, a CONNECT-csomag hitelesítési adatait és a TLS-kézfogás során bemutatott ügyféltanúsítvány-láncot.
  8. Az előtér elküldi ezeket a hitelesítő adatokat a hitelesítési szolgáltatásnak. A hitelesítési szolgáltatás ismét ellenőrzi a tanúsítványláncot, és összegyűjti a lánc összes tanúsítványának tulajdonosnevét.
  9. A hitelesítési szolgáltatás a konfigurált engedélyezési szabályok alapján határozza meg, hogy a csatlakozó ügyfelek milyen attribútumokkal rendelkeznek. Ezek az attribútumok határozzák meg, hogy az ügyfél milyen műveleteket hajthat végre, beleértve magát a CONNECT-csomagot is.
  10. A hitelesítési szolgáltatás visszaadja a döntést az előtérbeli közvetítőnek.
  11. Az előtérbeli közvetítő ismeri az ügyfélattribútumokat, és hogy engedélyezve van-e a csatlakozás. Ha igen, akkor az MQTT-kapcsolat befejeződött, és az ügyfél továbbra is küldhet és fogadhat az engedélyezési szabályok által meghatározott MQTT-csomagokat.

Kubernetes-szolgáltatásfiók jogkivonatai

A Kubernetes-szolgáltatásfiók-jogkivonatok (SAT-k) a Kubernetes-szolgáltatásfiókokhoz társított JSON-webjogkivonatok. Az ügyfelek saT-okat mutatnak be az MQTT-közvetítőnek a hitelesítéshez.

Az MQTT-közvetítő kötött szolgáltatásfiók-jogkivonatokat használ, amelyeket a GKE-felhasználóknak tudniuk kell a Kubernetes új szolgáltatásfiók-jogkivonatainak bejegyzéséről. Íme a bejegyzés salient funkciói:

A Kubernetes 1.13-ban indított, és az 1.21-ben alapértelmezett formátummá vált kötött jogkivonatok az örökölt jogkivonatok összes korlátozott funkcióját kezelik, és így tovább:

  • A jogkivonatokat nehezebb ellopni és visszaélni; időhöz kötöttek, célközönséghez kötöttek és objektumhoz kötöttek.
  • Szabványos formátumot alkalmaznak: OpenID Connect (OIDC) teljes OIDC-felderítéssel, így a szolgáltatók könnyebben fogadhatják el őket.
  • A podok biztonságosabban vannak elosztva egy új Kubelet-előrejelzett kötettípussal.

A közvetítő a Kubernetes Token Review API használatával ellenőrzi a jogkivonatokat. Engedélyezze a Kubernetes-funkció TokenRequestProjection megadását audiences (alapértelmezett 1.21 óta). Ha ez a funkció nincs engedélyezve, az SAT-k nem használhatók.

Szolgáltatásfiók létrehozása

SaT-k létrehozásához először hozzon létre egy szolgáltatásfiókot. Az alábbi parancs létrehoz egy .mqtt-client

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

Attribútumok hozzáadása engedélyezéshez

A SAT-on keresztüli ügyfélhitelesítés opcionálisan az egyéni engedélyezési szabályzatokhoz használandó attribútumokkal ellátott SAT-okat is tartalmazhat. További információ: Kubernetes-szolgáltatásfiók-jogkivonatokat használó ügyfelek engedélyezése.

Szolgáltatásfiók-jogkivonat (SAT) hitelesítésének engedélyezése

Módosítsa a authenticationMethods BrokerAuthentication-erőforrás beállításait úgy, hogy érvényes hitelesítési módszerként adja megServiceAccountToken. A audiences jogkivonatok érvényes célközönségeinek listáját adja meg. Válassza ki az MQTT-közvetítő szolgáltatást azonosító egyedi értékeket. Meg kell adnia legalább egy célközönséget, és az összes SAT-nak meg kell egyeznie a megadott célközönségek egyikével.

  1. Az Azure Portalon keresse meg az IoT Operations-példányt.
  2. Az Azure IoT Operations-erőforrások között válassza az MQTT Broker lehetőséget.
  3. Válassza a Hitelesítés lapot.
  4. Válasszon ki egy meglévő hitelesítési szabályzatot, vagy hozzon létre egy újat.
  5. Adjon hozzá egy új metódust a Metódus hozzáadása gombra kattintva.
  6. Válassza ki a kubernetes SAT metódustípust a legördülő listából, majd válassza a Részletek hozzáadása lehetőséget a metódus konfigurálásához.

Képernyőkép az Azure Portalról az MQTT-közvetítő SAT hitelesítési módszerének beállításához.

SAT-hitelesítés tesztelése

A SAT-hitelesítést az MQTT-közvetítővel azonos fürtben lévő ügyféltől kell használni. Csak továbbfejlesztett hitelesítési mezők engedélyezettek. Állítsa be a hitelesítési módszert, K8S-SAT és állítsa be az adatokat a jogkivonatra.

Az alábbi parancs egy podot határoz meg, amely rendelkezik a mosquitto-ügyfélrel, és csatlakoztatja az előző lépésekben létrehozott SAT-t a podhoz.

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

Itt a serviceAccountName podkonfiguráció mezőjének meg kell egyeznie a használt jogkivonathoz társított szolgáltatásfiókkal. Emellett serviceAccountToken.audience a podkonfiguráció mezőjének a audiences BrokerAuthentication erőforrás egyik konfigurált mezőjének kell lennie.

A pod létrehozása után indítsa el a rendszerhéjat a podban:

kubectl exec --stdin --tty mqtt-client -n azure-iot-operations -- sh

A pod héján belül futtassa a következő parancsot, hogy közzétegye az üzenetet a közvetítőnek:

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)

A kimenetnek a következőképpen kell kinéznie:

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

A mosquitto-ügyfél a csatlakoztatott szolgáltatásfiók-jogkivonatot /var/run/secrets/tokens/broker-sat használja a közvetítővel való hitelesítéshez. A jogkivonat 24 órán át érvényes. Az ügyfél az alapértelmezett legfelső szintű hitelesítésszolgáltatói tanúsítványt /var/run/certs/ca.crt is használja a közvetítő TLS-tanúsítványláncának ellenőrzéséhez.

Szolgáltatásfiók jogkivonatainak frissítése

A szolgáltatásfiók jogkivonatai korlátozott ideig érvényesek, és konfigurálva vannak a következővel expirationSeconds: . A Kubernetes azonban a lejárat előtt automatikusan frissíti a jogkivonatot. A jogkivonat a háttérben frissül, és az ügyfélnek nem kell mást tennie, mint újra lekérnie.

Ha például az ügyfél egy pod, amely kötetként csatlakoztatott jogkivonatot használ, például a teszt SAT hitelesítési példában, akkor a legújabb jogkivonat ugyanazon az útvonalon /var/run/secrets/tokens/mqtt-client-tokenérhető el. Új kapcsolat létrehozásakor az ügyfél lekérheti a legújabb jogkivonatot, és hitelesítheti azt. Az ügyfélnek rendelkeznie kell egy mechanizmussal az MQTT jogosulatlan hibáinak kezelésére a legújabb jogkivonat beolvasásával és a kapcsolat újrapróbálkozásával.

Egyéni hitelesítés

Az ügyfél-hitelesítés kiterjesztése a megadott hitelesítési módszereken túlra egyéni hitelesítéssel. Csatlakoztatható, mivel a szolgáltatás bármi lehet, amíg megfelel az API-nak.

Ha egy ügyfél csatlakozik az MQTT-közvetítőhöz, és az egyéni hitelesítés engedélyezve van, az MQTT-közvetítő az ügyfél hitelesítő adatainak ellenőrzését egy egyéni hitelesítési kiszolgálóra delegálja EGY HTTP-kéréssel, valamint az ügyfél által megadott összes hitelesítő adattal együtt. Az egyéni hitelesítési kiszolgáló az ügyfél jóváhagyásával vagy elutasításával válaszol az ügyfél engedélyezési attribútumaival.

Egyéni hitelesítési szolgáltatás létrehozása

Az egyéni hitelesítési kiszolgáló az MQTT-közvetítőtől külön van implementálva és üzembe helyezve.

Egy egyéni hitelesítési mintakiszolgáló és utasítások érhetők el a GitHubon. Ezt a mintát sablonként használhatja, és kiindulópontként használhatja saját egyéni hitelesítési logikájának implementálásához.

API

Az MQTT-közvetítő és az egyéni hitelesítési kiszolgáló közötti API az egyéni hitelesítés API-specifikációját követi. Az OpenAPI-specifikáció elérhető a GitHubon.

TLS-titkosítással rendelkező HTTPS-t kell használni

Az MQTT-közvetítő bizalmas ügyfél-hitelesítő adatokat tartalmazó kéréseket küld az egyéni hitelesítési kiszolgálónak. A hitelesítő adatok védelméhez az MQTT-közvetítő és az egyéni hitelesítési kiszolgáló közötti kommunikációt TLS-lel kell titkosítani.

Az egyéni hitelesítési kiszolgálónak kiszolgálótanúsítványt kell bemutatnia, az MQTT-közvetítőnek pedig megbízható legfelső szintű hitelesítésszolgáltatói tanúsítvánnyal kell rendelkeznie a kiszolgálótanúsítvány érvényesítéséhez. Az egyéni hitelesítési kiszolgáló megkövetelheti, hogy az MQTT-közvetítő egy ügyféltanúsítványt mutasson be a hitelesítéshez.

Egyéni hitelesítés engedélyezése figyelőhöz

Módosítsa a authenticationMethods BrokerAuthentication-erőforrás beállításait úgy, hogy érvényes hitelesítési módszerként adja megCustom. Ezután adja meg az egyéni hitelesítési kiszolgálóval való kommunikációhoz szükséges paramétereket.

Ez a példa az összes lehetséges paramétert mutatja be. A szükséges pontos paraméterek az egyes egyéni kiszolgálók követelményeitől függnek.

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

Hitelesítés letiltása

A teszteléshez letilthatja a hitelesítést egy közvetítő figyelőportjához. Éles környezetekben nem ajánlott letiltani a hitelesítést.

  1. Az Azure Portalon keresse meg az IoT Operations-példányt.
  2. Az Azure IoT Operations-erőforrások között válassza az MQTT Broker lehetőséget.
  3. Válassza ki a listából a szerkeszteni kívánt közvetítőfigyelőt.
  4. A hitelesítés letiltásához használt porton válassza a Nincs lehetőséget a hitelesítés legördülő listában.

Az ügyfél kapcsolatának megszakadása a hitelesítő adatok lejárata után

Az MQTT-közvetítő leválasztja az ügyfeleket, amikor lejárnak a hitelesítő adataik. A hitelesítő adatok lejárata utáni kapcsolat bontása az MQTT-közvetítő előtérrendszeréhez csatlakozó összes ügyfélre vonatkozik, beleértve a következőket:

  • Az SAT-kkal hitelesített ügyfelek le lesznek választva a SAT lejáratakor
  • Az X.509-kapcsolattal hitelesített ügyfelek leválasztása az ügyféltanúsítvány lejáratakor
  • Az egyéni hitelesítéssel hitelesített ügyfelek leválasztása az egyéni hitelesítési kiszolgálóról visszaadott lejárati idő alapján.

Kapcsolat bontása esetén az ügyfél hálózati kapcsolata lezárul. Az ügyfél nem kap MQTT DISCONNECT csomagot, de a közvetítő naplózza azt az üzenetet, hogy leválasztotta az ügyfelet.

Az SAT-kkal és egyéni hitelesítéssel hitelesített MQTT v5-ügyfelek új hitelesítő adatokkal újrahitelesíthetik magukat, mielőtt a kezdeti hitelesítő adatok lejárnak. Az X.509-ügyfelek nem tudják újrahitelesíteni a kapcsolatot, és újra létre kell hozniuk a kapcsolatot, mivel a hitelesítés a TLS-rétegben történik.

Az ügyfelek egy MQTT v5 AUTH-csomag elküldésével újrahitelesíthetik azokat.

A SAT-ügyfelek a mezőket method: K8S-SATtartalmazó AUTH-ügyfelet küldenek. data: <token> Az egyéni hitelesítési ügyfelek az egyéni hitelesítési kiszolgáló által megkövetelt módon és adatmezővel adhatók meg.

A sikeres újrahitelesítés frissíti az ügyfél hitelesítő adatainak lejárati idejét az új hitelesítő adatok lejárati idejével, és a közvetítő egy sikeres AUTH-csomaggal válaszol. Átmeneti problémák miatt meghiúsult hitelesítés miatt a közvetítő egy ContinueAuthentication AUTH-csomaggal válaszol. Az egyéni hitelesítési kiszolgáló például nem érhető el. Az ügyfél később újra próbálkozhat. Más hitelesítési hibák miatt a közvetítő egy DISCONNECT-csomagot küld, és bezárja az ügyfél hálózati kapcsolatát.

Kapcsolódó tartalom