Dela via


Självstudie: TLS, X.509-klientautentisering och auktorisering för attributbaserad åtkomstkontroll (ABAC) med Azure IoT Operations MQTT Broker

Den här självstudien vägleder dig genom att konfigurera Azure IoT Operations MQTT-asynkronisering med TLS-kryptering och X.509-klientautentisering. Den innehåller stegvisa instruktioner och skript för att skapa certifikat för både koordinatorn och klienterna. I självstudien beskrivs hur du konfigurerar MQTT-koordinatorn med olika rotcertifikatutfärdare (CA) för klienten och asynkron meddelandekö. Det omfattar även att konfigurera en auktoriseringsprincip för attributbaserad åtkomstkontroll (ABAC) baserat på klientcertifikatkedjan. Slutligen använder självstudien Mosquito-klienten för att testa olika scenarier för att säkerställa att installationen fungerar korrekt.

Självstudien simulerar en miljö där Azure IoT Operations installeras i en Contoso-fabrik med enheter som tillverkas av Fabrikam. Så här gör du för att TLS- och X.509-autentisering ska fungera:

  • Azure IoT Operations MQTT-asynkron, installerad i en Contoso-fabrik, måste lita på Fabrikam-rotcertifikatutfärdare
  • Fabrikam-sensorer, till exempel termostater, måste lita på Contosos rotcertifikatutfärdare
  • Varje entitet måste ha ett eget lövcertifikat utfärdat av rätt rotcertifikatutfärdare

Diagram som visar förtroenderelationen för certifikatutfärdarrötterna på server- och klientsidan.

Förutsättningar

Om du vill följa den här självstudien behöver du:

  • Ett Kubernetes-kluster med portvidarebefordring aktiverat för port 8883.
  • Azure IoT Operations distribueras utan en befintlig lyssnare för lastbalanserare.
  • Kubectl-åtkomst till klustret för att skapa Kubernetes-hemligheter och konfigurationskartor.
  • Mosquitto-klienten publicerar och prenumererar på MQTT-meddelanden som körs på samma dator som Kubernetes-klustret för localhost åtkomst. Om du inte vill använda läser localhostdu Valfritt: Använd ett riktigt värdnamn eller EN IP-adress i stället localhost för avsnittet .
  • Steg CLI för att skapa certifikat.

Dricks

Om du vill uppfylla dessa krav använder du snabbstartskodområdet. Snabbstartskodområdet förenklar konfigurationsprocessen genom att tillhandahålla dessa komponenter direkt.

Dessutom är kunskaper om kryptering av offentliga nycklar och termer som rotcertifikatutfärdare, privat nyckel och mellanliggande certifikat användbara.

Valfritt: Använd ett verkligt värdnamn eller EN IP-adress i stället för localhost

För att hålla den här självstudien enkel använder localhost vi för att komma åt MQTT-koordinatorn. Den här metoden säkerställer att mäklarens servercertifikat har ett alternativt ämnesnamn (SAN) som matchar värdnamnet som används för att komma åt asynkron meddelandekö. Med hjälp av localhost förenklas konfigurationen eftersom SAN redan har angetts korrekt.

I ett verkligt scenario använder du värdnamnet eller den externa IP-adressen för asynkron meddelandekö i stället för localhost och ansluter till den från en annan enhet i nätverket. I det här fallet måste du fastställa rätt värdnamn eller IP-adress och använda den som SAN när du skapar servercertifikatet:

  • Om värdnamnet eller IP-adressen redan är känd (till exempel via en DNS-post eller statisk IP-adress) använder du den som SAN när du skapar servercertifikatet. Anslut sedan till asynkron meddelandekö med hjälp av värdnamnet eller IP-adressen i stället localhostför .
  • Om värdnamnet eller IP-adressen inte redan är känd kan du använda en platshållartjänst för att fastställa den externa IP-adressen:
    1. Skapa LoadBalancer-tjänsten på en port som inte används (till exempel 8080):
      kubectl create service loadbalancer placeholder-service --tcp=8080:8080
      
    2. Hämta den externa IP-adressen:
      kubectl get svc placeholder-service
      
    3. Om den externa IP-adressen:
      • Visar ett värde som 192.168.X.X – använd ip-adressen som SAN när du skapar servercertifikatet och hemligheten. Anslut sedan till asynkron meddelandekö med den IP-adressen i stället localhostför .
      • Visar <pending> – Kubernetes-distributionen som du använder kanske inte stöder automatisk tilldelning av en extern IP-adress. Följ stegen i Kubernetes-dokumentationen för din distributions- och värdmiljö för att hitta den externa IP-adressen. Du kan också behöva konfigurera portvidarebefordring eller ett VPN beroende på nätverkskonfigurationen.
    4. När du har fastställt den externa IP-adressen tar du bort platshållartjänsten:
      kubectl delete svc placeholder-service
      

Den här metoden säkerställer att servercertifikatet matchar den externa IP-adressen, vilket ger säker åtkomst till MQTT-koordinatorn.

Förbereda certifikat på serversidan och fullständig kedja

Skapa först en rotcertifikatutfärdare på serversidan. Den här ca:en är separat från rotcertifikatutfärdarcertifikatutfärdarna på klientsidan som skapas senare. För att hålla separationen tydlig namnger vi allt på serversidan "Contoso". För att göra senare steg enklare hoppar vi över lösenordet för kryptering av den privata nyckeln. Den här metoden är endast acceptabel i en självstudieinställning.

step certificate create "Contoso Root CA" \
contoso_root_ca.crt contoso_root_ca.key \
--profile root-ca \
--no-password --insecure

Skapa sedan en mellanliggande ca som signerats av den här rotcertifikatutfärdarcertifikatutfärdarna.

step certificate create "Contoso Intermediate CA 1" \
contoso_intermediate_ca.crt contoso_intermediate_ca.key \
--profile intermediate-ca \
--ca ./contoso_root_ca.crt --ca-key ./contoso_root_ca.key \
--no-password --insecure

Slutligen använder du den här mellanliggande certifikatutfärdare för att signera ett servercertifikat för MQTT-mäklarens klientdel. localhost Här är det alternativa ämnesnamnet (SAN) som används för självstudien.

step certificate create mqtts-endpoint \
mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--ca ./contoso_intermediate_ca.crt --ca-key ./contoso_intermediate_ca.key \
--bundle \
--san localhost \
--not-after 2400h --no-password --insecure

--bundle Med flaggan paketeras servercertifikatet med det mellanliggande signeringscertifikatet. TLS-handskakning kräver att paketet verifierar hela kedjan.

Förbereda certifikat på klientsidan och fullständig kedja

På samma sätt skapar du rotcertifikatutfärdarcertifikatutfärdarna för Fabrikam och den mellanliggande CA:en.

step certificate create --profile root-ca "Fabrikam Root CA" \
fabrikam_root_ca.crt fabrikam_root_ca.key \
--no-password --insecure
step certificate create "Fabrikam Intermediate CA 1" \
fabrikam_intermediate_ca.crt fabrikam_intermediate_ca.key \
--profile intermediate-ca \
--ca ./fabrikam_root_ca.crt --ca-key ./fabrikam_root_ca.key \
--no-password --insecure

Generera sedan klientcertifikat för en termostat, hygrometer, värmare och glödlampa.

# Create a client certificate for the thermostat
step certificate create thermostat thermostat.crt thermostat.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure

# Create a client certificate for the hygrometer
step certificate create hygrometer hygrometer.crt hygrometer.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure

# Create a client certificate for the heater
step certificate create heater heater.crt heater.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure

# Create a client certificate for the lightbulb
step certificate create lightbulb lightbulb.crt lightbulb.key \
--ca ./fabrikam_intermediate_ca.crt --ca-key ./fabrikam_intermediate_ca.key --bundle \
--not-after 2400h --no-password --insecure

Konfigurera Kubernetes

Importera det nyligen genererade servercertifikatet och den privata nyckeln till en Kubernetes-hemlighet. Den här hemligheten används för att konfigurera en TLS-lyssnare för MQTT-koordinator senare.

kubectl create secret tls broker-server-cert -n azure-iot-operations \
--cert mqtts-endpoint.crt \
--key mqtts-endpoint.key

Skapa också en konfigurationskarta som innehåller rotcertifikatutfärdare för Fabrikam (klientsidan). Den här konfigurationskartan krävs för att MQTT-koordinatorn ska kunna lita på den för X.509-autentisering.

kubectl create configmap fabrikam-ca -n azure-iot-operations \
--from-file=client_ca.pem=fabrikam_root_ca.crt

Konfigurera MQTT-koordinator

Nästa steg konfigurerar MQTT-asynkronisering med TLS-kryptering och X.509-klientautentisering. I självstudien används Azure Portal för att konfigurera MQTT-koordinatorn.

Autentisering

Om du vill tillåta klienter att autentisera med X.509-certifikat som utfärdats av Fabrikam-rotcertifikatutfärdare skapar du en autentiseringsprincip som litar på Fabrikam-rotcertifikatutfärdarcertifikatet och mappar klientcertifikaten till auktoriseringsattribut för ABAC.

  1. I Azure Portal navigerar du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

  3. Markera fliken autentisering.

  4. Välj Skapa autentiseringsprincip.

  5. Som Principnamn anger du x509-auth.

  6. Lägg till en ny metod genom att välja Lägg till metod.

  7. Välj metodtypen X.509 i listrutan och välj sedan Lägg till information för att konfigurera metoden.

  8. I fönstret X.509-autentiseringsinformation anger du ConfigMap-namnet fabrikam-ca för Fabrikam-certifikatet och attributen.

    {
      "trustedClientCaCert": "fabrikam-ca",
      "authorizationAttributes": {
        "thermostat": {
          "subject": "CN = thermostat",
          "attributes": {
            "group": "thermostat_group"
          }
        },
        "hygrometer": {
          "subject": "CN = hygrometer",
          "attributes": {
            "group": "hygrometer_group"
          }
        },
        "intermediate": {
          "subject": "CN = Fabrikam Intermediate CA 1",
          "attributes": {
            "manufacturer": "fabrikam"
          }
        }
      }
    }
    
  9. Välj Använd och sedan Lägg till för att spara ändringarna.

Skärmbild som visar hur du använder Azure Portal för att skapa en X.509-autentiseringsmetod för MQTT-koordinator.

Lyssnare

När autentiseringsprincipen är på plats skapar du en lyssnare som använder X.509-autentiseringsprincipen. Eftersom X.509-autentisering kräver TLS konfigurerar du lyssnaren att använda Contoso-servercertifikatet och den privata nyckel som skapades tidigare.

  1. I Azure Portal navigerar du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

  3. Välj MQTT-koordinatorlyssnare för LoadBalancer>Create. Ange följande inställningar:

    Inställning Description
    Name Ange mqtts-endpoint.
    Servicenamn Namnet på Kubernetes-tjänsten. Lämna tomt om du vill använda lyssnarnamnet mqtts-endpoint som tjänstnamn.
    Typ av tjänst LoadBalancer har redan valts.
  4. Under Portar anger du följande inställningar för den första porten:

    Inställning beskrivning
    Port Ange 8883
    Autentisering Välj x509-auth
    Auktorisering Välj Ingen
    Protokoll Välj MQTT
    TLS Markera Lägga till
  5. I TLS-konfigurationsfönstret anger du följande inställningar:

    Inställning beskrivning
    TLS-läge Välj Manuell
    Utfärdarens namn Ange broker-server-cert
  6. Välj Använd och Skapa lyssnare.

Skärmbild som visar Azure Portal metod för att ange en lyssnare med TLS-port.

Efter en minut eller två mqtts-endpoint skapas LoadBalancer-tjänsten.

$ kubectl get service mqtts-endpoint -n azure-iot-operations
NAME             TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
mqtts-endpoint   LoadBalancer   10.43.28.140   XXX.XX.X.X    8883:30988/TCP   104s

I stället för att använda den externa IP-adressen använder localhost vi för självstudien.

Dricks

Kodområdeskonfigurationen konfigurerar automatiskt portvidarebefordring för 8883. Information om hur du konfigurerar andra miljöer finns i Använda portvidarebefordring.

Använda en enda Mosquito-klient för att publicera meddelanden via TLS

Från samma mapp som certifikatfilerna: contoso_root_ca.crt, thermostat.crtoch thermostat.key, använder du Mosquito-klienten för att publicera ett meddelande. Flaggan --cafile contoso_root_ca.crt är till för att Mosquito ska utföra verifiering av servercertifikat.

mosquitto_pub -t "example/topic" -m "example temperature measurement" -i thermostat \
-q 1 -V mqttv5 -d \
-h localhost \
--key thermostat.key \
--cert thermostat.crt \
--cafile contoso_root_ca.crt

Publiceringen lyckas eftersom Mosquito använder ett klientcertifikat som är rotat i fabrikam_root_ca.crt. MQTT-mäklaren litar på det här certifikatet x509-auth eftersom autentiseringsprincipen som skapades tidigare. Dessutom tillåter MQTT-koordinatorn för närvarande autentiserade klienter att publicera till vilket ämne som helst.

Client thermostat sending CONNECT
Client thermostat received CONNACK (0)
Client thermostat sending PUBLISH (d0, q1, r0, m1, 'example/topic', ... (31 bytes))
Client thermostat received PUBACK (Mid: 1, RC:0)
Client thermostat sending DISCONNECT

Konfigurera auktorisering till MQTT-ämnen för flera klienter med X.509

Om du vill begränsa åtkomsten till MQTT-ämnen baserat på klientcertifikatattributen skapar du en auktoriseringsprincip som mappar klientcertifikatattributen till tillåtna åtgärder i specifika ämnen.

  1. I Azure Portal navigerar du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

  3. Välj fliken Auktorisering .

  4. Välj Skapa auktoriseringsprincip.

  5. Som Principnamn anger du abac-authz.

  6. Under Regler anger du följande regler:

    [
      {
        "principals": {
          "attributes": [
            {
              "group": "thermostat_group"
            }
          ]
        },
        "brokerResources": [
          {
            "method": "Connect"
          },
          {
            "method": "Publish",
            "topics": [
              "telemetry/temperature"
            ]
          }
        ]
      },
      {
        "principals": {
          "attributes": [
            {
              "group": "hygrometer_group"
            }
          ]
        },
        "brokerResources": [
          {
            "method": "Connect"
          },
          {
            "method": "Publish",
            "topics": [
              "telemetry/humidity"
            ]
          }
        ]
      },
      {
        "principals": {
          "attributes": [
            {
              "manufacturer": "fabrikam"
            }
          ]
        },
        "brokerResources": [
          {
            "method": "Connect"
          },
          {
            "method": "Publish",
            "topics": [
              "health/heartbeat"
            ]
          }
        ]
      },
      {
        "principals": {
          "usernames": [
            "heater"
          ]
        },
        "brokerResources": [
          {
            "method": "Connect"
          },
          {
            "method": "Subscribe",
            "topics": [
              "telemetry/temperature",
              "telemetry/humidity"
            ]
          }
        ]
      }
    ]
    
  7. Spara ändringarna genom att välja Lägg till.

Skärmbild som visar Azure Portal för att konfigurera en auktoriseringsprincip.

Uppdatera sedan MQTT-koordinatorlyssnaren så att den nya auktoriseringsprincipen används.

  1. Välj fliken Lyssnare .
  2. Välj lyssnaren mqtts-endpoint .
  3. Under Port>8883-auktorisering> väljer du abac-authz.
  4. Välj Spara.

Skärmbild som visar Azure Portal för att länka en port till en auktoriseringsprincip.

Publicera meddelanden till ett begränsat ämne

I det här avsnittet testar vi de nyligen tillämpade auktoriseringsprinciperna.

Först ansluter du till thermostat och försöker publicera i ämnet telemetry/humidity:

mosquitto_pub -t "telemetry/humidity" -m "example temperature measurement" -i thermostat \
-q 1 -V mqttv5 -d \
-h localhost \
--key thermostat.key \
--cert thermostat.crt \
--cafile contoso_root_ca.crt

Eftersom thermostat är en del av thermostat_group, som inte tillåts att publicera till fuktighetsavsnittet, misslyckas publiceringen.

Client thermostat sending CONNECT
Client thermostat received CONNACK (0)
Client thermostat sending PUBLISH (d0, q1, r0, m1, 'telemetry/humidity', ... (6 bytes))
Client thermostat received PUBACK (Mid: 1, RC:135)
Warning: Publish 1 failed: Not authorized.

Ändra till publicera till telemetry/temperature, vilket tillåts och publiceringen lyckas. Låt kommandot vara igång.

mosquitto_pub -t "telemetry/temperature" -m "example temperature measurement" -i thermostat \
-q 1 -V mqttv5 -d \
-h localhost \
--repeat 10000 \
--repeat-delay 3 \
--key thermostat.key \
--cert thermostat.crt \
--cafile contoso_root_ca.crt

Prenumerera på meddelanden om begränsade ämnen

I en separat terminalsession ansluter du med heater för att health/heartbeatprenumerera på .

mosquitto_sub -q 1 -t "health/heartbeat" -d -V mqttv5 \
-i heater \
-h localhost \
--key heater.key \
--cert heater.crt \
--cafile contoso_root_ca.crt

Eftersom heater inte har behörighet att prenumerera på pulsslagsämnet misslyckas prenumerationen. Här innebär kod 135 att den inte är auktoriserad.

Client heater sending CONNECT
Client heater received CONNACK (0)
Client heater sending SUBSCRIBE (Mid: 1, Topic: health/heartbeat, QoS: 1, Options: 0x00)
Client heater received SUBACK
Subscribed (mid: 1): 135

Växla prenumerationsavsnittet till telemetry/temperature, som thermostat fortfarande skickar meddelanden till.

mosquitto_sub -q 1 -t "telemetry/temperature" -d -V mqttv5 \
-i heater \
-h localhost \
--key heater.key \
--cert heater.crt \
--cafile contoso_root_ca.crt

Nu heater börjar ta emot meddelanden eftersom det är auktoriserat med sitt användarnamn.

I en annan separat terminalsession publicerar du meddelanden till health/heartbeat med lightbulb:

mosquitto_pub -q 1 -t "health/heartbeat" -m "example heartbeat" -d -V mqttv5 \
-i lightbulb \
-h localhost \
--repeat 100 \
--repeat-delay 3 \
--key lightbulb.key \
--cert lightbulb.crt \
--cafile contoso_root_ca.crt

Publiceringen lyckas eftersom lightbulb har ett mellanliggande certifikat med CN = Fabrikam Intermediate CA 1, som mappas till attributet manufacturer=fabrikam. Klienter med det attributet kan publicera på health/heartbeat. När klienten börjar skicka meddelanden heater tar den tidigare igång ingenting.

Rensa resurser

Ta bort lyssnaren och autentiserings- och auktoriseringsprinciperna för att rensa resurserna som skapades i den här självstudien.

  1. I Azure Portal navigerar du till din IoT Operations-instans.
  2. Under Komponenter väljer du MQTT Broker.
  3. Välj fliken Lyssnare .
  4. Markera kryssrutan bredvid lyssnaren mqtts-endpoint .
  5. Välj Ta bort.
  6. Bekräfta borttagningen.
  7. Markera fliken autentisering.
  8. Markera kryssrutan bredvid x509-auth.
  9. Välj Ta bort.
  10. Bekräfta borttagningen.
  11. Välj fliken Auktorisering .
  12. Markera kryssrutan bredvid abac-authz.
  13. Välj Ta bort.
  14. Bekräfta borttagningen.

Ta också bort Kubernetes-hemligheten och konfigurationskartan.

kubectl delete secret broker-server-cert -n azure-iot-operations
kubectl delete configmap fabrikam-ca -n azure-iot-operations

Ta slutligen bort de certifikat och nycklar som genererades tidigare.

rm contoso_root_ca.crt contoso_root_ca.key contoso_intermediate_ca.crt contoso_intermediate_ca.key mqtts-endpoint.crt mqtts-endpoint.key
rm fabrikam_root_ca.crt fabrikam_root_ca.key fabrikam_intermediate_ca.crt fabrikam_intermediate_ca.key thermostat.crt thermostat.key hygrometer.crt hygrometer.key heater.crt heater.key lightbulb.crt lightbulb.key