MQTT-brokerverificatie configureren
Belangrijk
Deze pagina bevat instructies voor het beheren van Azure IoT Operations-onderdelen met behulp van Kubernetes-implementatiemanifesten, die in preview zijn. Deze functie is voorzien van verschillende beperkingen en mag niet worden gebruikt voor productieworkloads.
Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.
Een MQTT-broker ondersteunt meerdere verificatiemethoden voor clients. U kunt elke listenerpoort configureren voor eigen verificatie-instellingen met een BrokerAuthentication-resource. Zie de naslaginformatie over de Broker Authentication-API voor een lijst met de beschikbare instellingen.
Link BrokerListener en BrokerAuthentication
De volgende regels zijn van toepassing op de relatie tussen BrokerListener- en BrokerAuthentication-resources:
- Elke BrokerListener-resource kan meerdere poorten hebben. U kunt elke poort koppelen aan een BrokerAuthentication-resource.
- Elke BrokerAuthentication-resource kan meerdere verificatiemethoden tegelijk ondersteunen.
- Poorten die geen BrokerAuthentication-resource koppelen, hebben verificatie uitgeschakeld.
Als u een BrokerListener-poort wilt koppelen aan een BrokerAuthentication-resource, geeft u het authenticationRef veld op in de ports instelling van de BrokerListener-resource. Zie de BrokerListener-resource voor meer informatie.
Default BrokerAuthentication-resource
Azure IoT Operations implementeert een standaard-BrokerAuthentication-resource die is gekoppeld default aan de standaardlistener in de azure-iot-operations naamruimte. Er worden alleen Kubernetes-serviceaccounttokens (SAT's) gebruikt voor verificatie.
Belangrijk
De SAT-verificatiemethode in de standaardresource BrokerAuthentication is vereist voor onderdelen in IoT-bewerkingen om correct te functioneren. Vermijd het bijwerken of verwijderen van de standaard BrokerAuthentication-resource.
Ga in Azure Portal naar uw IoT Operations-exemplaar.
Selecteer onder Onderdelen de optie MQTT Broker.
Selecteer het tabblad Verificatie.
Selecteer in de lijst met verificatiebeleid de standaardbeleidsnaam .
Als u nieuwe verificatiemethoden wilt toevoegen, selecteert u Methode Toevoegen.
Verificatiestroom
De volgorde van de opgegeven verificatiemethoden bepaalt hoe de MQTT-broker clients verifieert. De MQTT-broker probeert de referenties van de client te verifiëren met behulp van de eerste opgegeven methode en doorloopt de opgegeven methoden totdat er een overeenkomst wordt gevonden of het einde bereikt.
Voor elke methode controleert de MQTT-broker eerst of de referenties van de client relevant zijn voor die methode. Voor SAT-verificatie is bijvoorbeeld een gebruikersnaam vereist die begint met K8S-SATen X.509-verificatie vereist een clientcertificaat. Als de referenties van de client relevant zijn, controleert de MQTT-broker of deze geldig zijn. Zie de sectie Verificatiemethode configureren voor meer informatie.
Voor aangepaste verificatie behandelt de MQTT-broker het niet communiceren met de aangepaste verificatieserver als referenties die niet relevant zijn. Met dit gedrag kan de MQTT-broker terugvallen op andere methoden als de aangepaste verificatieserver onbereikbaar is.
De verificatiestroom eindigt wanneer:
- Een van deze voorwaarden is waar:
- De referenties van de client zijn relevant en geldig voor een van de methoden.
- De referenties van de client zijn niet relevant voor een van de methoden.
- De referenties van de client zijn relevant, maar ongeldig voor een van de methoden.
- De MQTT-broker verleent of weigert toegang tot de client op basis van het resultaat van de verificatiestroom.
Voorbeeld:
apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
name: default
namespace: azure-iot-operations
spec:
authenticationMethods:
- method: Custom
customSettings:
# ...
- method: ServiceAccountToken
serviceAccountTokenSettings:
# ...
In het eerdere voorbeeld wordt opgegeven custom en SAT. Wanneer een client verbinding maakt, probeert de MQTT-broker de client te verifiëren met behulp van de opgegeven methoden in de volgorde custom en vervolgens SAT.
- De MQTT-broker controleert of de referenties van de client geldig zijn voor aangepaste verificatie. Omdat aangepaste verificatie afhankelijk is van een externe server om de geldigheid van referenties te bepalen, beschouwt de broker alle referenties die relevant zijn voor aangepaste verificatie en stuurt deze door naar de aangepaste verificatieserver.
- Als de aangepaste verificatieserver reageert met een
PassofFaileen resultaat, eindigt de verificatiestroom. Als de aangepaste verificatieserver niet beschikbaar is, valt de MQTT-broker terug op de resterende opgegeven methoden, waarbij SAT de volgende is. - De MQTT-broker probeert de referenties te verifiëren als SAT-referenties.
Als de aangepaste verificatieserver niet beschikbaar is en alle volgende methoden bepalen dat de opgegeven referenties niet relevant zijn, weigert de broker de clientverbinding.
Verificatiemethode configureren
U kunt verificatiemethoden zoals X.509, SAT of aangepast toevoegen aan verificatiebeleid.
Een verificatiemethode toevoegen aan een beleid:
Ga in Azure Portal naar uw IoT Operations-exemplaar.
Selecteer onder Onderdelen de optie MQTT Broker.
Selecteer het tabblad Verificatie.
Kies een bestaand verificatiebeleid of maak een nieuw beleid.
Voeg een nieuwe methode toe door de methode Toevoegen te selecteren.
Kies het methodetype in de vervolgkeuzelijst en selecteer vervolgens Details toevoegen om de methode te configureren.
Zie de volgende secties voor elke methode voor meer informatie over elk van de verificatieopties.
Zie Veilige instellingen inschakelen in Azure IoT Operations-implementatie voor meer informatie over het inschakelen van beveiligde instellingen door een Azure Key Vault-exemplaar te configureren en workloadidentiteiten in te schakelen.
X.509
Tip
Voor een end-to-end voorbeeld van het configureren van X.509-verificatie raadpleegt u zelfstudie: TLS, X.509-clientverificatie en ABAC-autorisatie (op kenmerken gebaseerd toegangsbeheer).
Bij X.509-verificatie gebruikt de MQTT-broker een vertrouwd CA-certificaat (Certificate Authority) om clientcertificaten te valideren. Deze vertrouwde CA kan een basis- of tussenliggende CA zijn. De broker controleert de clientcertificaatketen op basis van het vertrouwde CA-certificaat. Als de keten geldig is, wordt de client geverifieerd.
Als u X.509-verificatie wilt gebruiken met een vertrouwd CA-certificaat, moet u voldoen aan de volgende vereisten:
- TLS-protocol (Transport Layer Security): Omdat X.509 afhankelijk is van TLS-clientcertificaten, moet TLS zijn ingeschakeld voor poorten met X.509-verificatie.
- Sleutelalgoritmen: zowel EC- als RSA-sleutels worden ondersteund, maar alle certificaten in de keten moeten hetzelfde sleutelalgoritmen gebruiken.
- Indeling: Het CA-certificaat moet de PEM-indeling (Privacy-Enhanced Mail) hebben.
Tip
PEM-indeling is een algemene indeling voor certificaten en sleutels. PEM-bestanden zijn Base64-gecodeerde ASCII-bestanden met headers zoals -----BEGIN CERTIFICATE----- en -----BEGIN EC PRIVATE KEY-----.
Als u een certificaat in een andere indeling hebt, kunt u het converteren naar PEM met behulp van OpenSSL. Zie Een certificaat converteren naar de juiste indeling voor meer informatie.
Een vertrouwd CA-certificaat ophalen
In een productie-installatie wordt het CA-certificaat geleverd door de openbare-sleutelinfrastructuur (PKI) van een organisatie of een openbare certificeringsinstantie.
Maak voor testen een zelfondertekend CA-certificaat met OpenSSL. Voer bijvoorbeeld de volgende opdracht uit om een zelfondertekend CA-certificaat te genereren met een RSA-sleutel, een DN-naam CN=Contoso Root CA Certen een geldigheid van 365 dagen:
openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"
Dezelfde opdracht met de stap-CLI, een handig hulpprogramma voor het beheren van certificaten, is:
step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
--not-after 8760h
Met deze opdrachten maakt u een CA-certificaat, ca.pemen een persoonlijke sleutel, ca-key.pemin PEM-indeling. U kunt het CA-certificaat ca.pem importeren in de MQTT-broker voor X.509-verificatie.
Een vertrouwd CA-certificaat importeren
Als u wilt beginnen met X.509-verificatie, importeert u het vertrouwde CA-certificaat in een ConfigMap in de azure-iot-operations naamruimte. Als u een vertrouwd CA-certificaat ca.pem wilt importeren in een ConfigMap met de naam client-ca, voert u het volgende uit:
kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations
In dit voorbeeld wordt het CA-certificaat geïmporteerd onder de sleutel ca.pem. De MQTT-broker vertrouwt alle CA-certificaten in de ConfigMap, zodat u alles kunt gebruiken voor de naam van de sleutel.
Voer de opdracht uit kubectl describe configmapom te controleren of het basis-CA-certificaat juist is geïmporteerd. Het resultaat toont dezelfde Base64-codering van het PEM-certificaatbestand.
kubectl describe configmap client-ca -n azure-iot-operations
Name: client-ca
Namespace: azure-iot-operations
Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----
BinaryData
====
X.509-verificatiemethode configureren
Nadat het vertrouwde CA-certificaat is geïmporteerd, schakelt u X.509-clientverificatie in door het toe te voegen als verificatiemethode in een BrokerAuthentication-resource. Zorg ervoor dat deze resource is gekoppeld aan een tls-listenerpoort.
Ga in Azure Portal naar uw IoT Operations-exemplaar.
Selecteer onder Onderdelen de optie MQTT Broker.
Selecteer het tabblad Verificatie.
Kies een bestaand verificatiebeleid of maak een nieuw beleid.
Voeg een nieuwe methode toe door de methode Toevoegen te selecteren.
Kies het methodetype X.509 in de vervolgkeuzelijst. Selecteer vervolgens Details toevoegen om de methode te configureren.
Geef in het deelvenster X.509-verificatiedetails de naam van het vertrouwde CA-certificaat ConfigMap op met behulp van JSON-indeling.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Vervang
<TRUSTED_CA_CONFIGMAP>door de naam van de ConfigMap die het vertrouwde CA-certificaat bevat. Gebruik bijvoorbeeld"trustedClientCaCert": "client-ca".
U kunt eventueel autorisatiekenmerken voor clients toevoegen met behulp van X.509-certificaten. Zie Certificaatkenmerken voor autorisatie voor meer informatie.
Selecteer Toepassen om de wijzigingen op te slaan.
Optioneel: Certificaatkenmerken voor autorisatie
U kunt X.509-kenmerken opgeven in de BrokerAuthentication-resource voor het autoriseren van clients op basis van hun certificaateigenschappen. De kenmerken worden gedefinieerd in het authorizationAttributes veld.
Voorbeeld:
Wanneer u in Azure Portal de X.509-verificatiemethode configureert, voegt u de autorisatiekenmerken toe in het deelvenster X.509-verificatiedetails in JSON-indeling.
{
"trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
"authorizationAttributes": {
"root": {
"subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
"attributes": {
"organization": "contoso"
}
},
"intermediate": {
"subject": "CN = Contoso Intermediate CA",
"attributes": {
"city": "seattle",
"foo": "bar"
}
},
"smartfan": {
"subject": "CN = smart-fan",
"attributes": {
"building": "17"
}
}
}
}
In dit voorbeeld ontvangt elke client met een certificaat dat is uitgegeven door de basis-CA met een DN-naam CN = Contoso Root CA Cert, OU = Engineering, C = US of de tussenliggende CA met DN-naam CN = Contoso Intermediate CA de kenmerken die worden vermeld. Daarnaast ontvangt het smart-fan-clientcertificaat kenmerken die specifiek zijn voor het certificaat.
De overeenkomst voor kenmerken begint altijd vanaf het leaf-clientcertificaat en gaat vervolgens langs de keten. De kenmerktoewijzing stopt na de eerste overeenkomst. In het vorige voorbeeld, zelfs als smart-fan het tussenliggende certificaat CN = Contoso Intermediate CAis, worden de bijbehorende kenmerken niet opgehaald.
U kunt autorisatieregels toepassen op clients met behulp van X.509-certificaten met deze kenmerken. Zie Clients autoriseren die X.509-verificatie gebruiken voor meer informatie.
X.509-verificatie inschakelen voor een listenerpoort
Nadat u het vertrouwde CA-certificaat hebt geïmporteerd en de BrokerAuthentication-resource hebt geconfigureerd, koppelt u het aan een tls-listenerpoort. Deze stap is belangrijk omdat X.509-verificatie afhankelijk is van TLS voor validatie van clientcertificaten.
Als u een tls-listenerpoort wilt ophalen, raadpleegt u Handmatig TLS-certificaatbeheer inschakelen voor een poort en schakelt u automatisch TLS-certificaatbeheer in voor een poort.
Notitie
Het inschakelen van TLS op een broker-listenerpoort betekent dat de broker gebruikmaakt van een servercertificaat voor TLS-versleuteling. Wanneer clients verbinding maken met deze poort, moeten ze het servercertificaat vertrouwen door het CA-certificaat te hebben dat het heeft ondertekend in het vertrouwensarchief. Dit proces staat bekend als vertrouwensdistributie of vertrouwensbundeling. Het is belangrijk om inzicht te hebben in het verschil tussen clientvalidatie en servervalidatie:
-
Clientvalidatie: De MQTT-broker (server) controleert het clientcertificaat op basis van het vertrouwde CA-certificaat dat is opgegeven in het
trustedClientCaCertveld voor X.509-clientverificatie. -
Servervalidatie: Clients (zoals Mosquitto of MQTTX) controleren het servercertificaat van de MQTT-broker op basis van het vertrouwde CA-certificaat in hun vertrouwensarchief. Voor Mosquitto-clients gebruikt u de
--cafileparameter om het CA-certificaatbestand op te geven. Voor MQTTX voegt u het CA-certificaat toe aan het vertrouwensarchief in de instellingen.
Nadat u X.509-verificatie hebt ingeschakeld, moet u ervoor zorgen dat clients het servercertificaat van de broker vertrouwen door het CA-certificaat aan de serverzijde in hun vertrouwensarchief te hebben. Verwar het vertrouwen van het CA-certificaat aan de serverzijde niet met het CA-certificaat aan de clientzijde dat wordt gebruikt voor clientverificatie die is opgegeven in het trustedClientCaCert veld.
Zie zelfstudie: TLS, X.509-clientverificatie en ABAC-autorisatie (op kenmerken gebaseerd toegangsbeheer) voor een volledig voorbeeld.
Mosquitto-client verbinden met MQTT-broker met X.509-clientcertificaat
Een client zoals Mosquitto heeft twee bestanden nodig om verbinding te kunnen maken met de MQTT-broker met TLS- en X.509-clientverificatie:
- De
--certparameter geeft het PEM-bestand voor het clientcertificaat op. Dit bestand moet ook tussenliggende certificaten bevatten om de MQTT-broker te helpen bij het bouwen van de volledige certificaatketen. - De
--keyparameter geeft het PEM-bestand met de persoonlijke sleutel van de client op.
In gevallen waarin de MQTT-broker een zelfondertekend CA-certificaat gebruikt om het TLS-servercertificaat uit te geven, is de --cafile parameter nodig. Dit bestand bevat het CA-certificaat (ook wel vertrouwensbundel genoemd), dat de Mosquitto-client gebruikt om het servercertificaat van de broker te valideren wanneer het verbinding maakt via TLS. Als de verlener van het servercertificaat van de MQTT-broker deel uitmaakt van het basisarchief van het systeem (zoals bekende openbare CA's), kan de --cafile parameter worden weggelaten.
Voorbeeld:
mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem
Inzicht in MQTT Broker X.509-clientverificatiestroom
Volg deze stappen voor clientverificatie:
- Wanneer X.509-clientverificatie is ingeschakeld, moeten clients die verbinding maken een clientcertificaat en tussenliggende certificaten presenteren om de MQTT-broker een certificaatketen te laten bouwen die is geroot naar een van de geconfigureerde vertrouwde certificaten.
- De load balancer stuurt de communicatie naar een van de front-endbrokers.
- Nadat de front-endbroker het clientcertificaat heeft ontvangen, wordt geprobeerd een certificaatketen te bouwen die is geroot naar een van de geconfigureerde certificaten. Als de front-endbroker een keten bouwt en de gepresenteerde keten wordt geverifieerd, wordt de TLS-handshake voltooid. De verbindende client kan MQTT-pakketten verzenden naar de front-end via het TLS-kanaal.
- Het TLS-kanaal is geopend, maar de clientverificatie of -autorisatie is nog niet voltooid.
- De client verzendt vervolgens een CONNECT-pakket naar de MQTT-broker.
- Het CONNECT-pakket wordt opnieuw doorgestuurd naar een front-end.
- De front-end verzamelt alle referenties die de client tot nu toe heeft gepresenteerd, zoals verificatiegegevens van het CONNECT-pakket en de clientcertificaatketen die tijdens de TLS-handshake wordt gepresenteerd.
- De front-end verzendt deze referenties naar de verificatieservice. De verificatieservice controleert de certificaatketen opnieuw en verzamelt de onderwerpnamen van alle certificaten in de keten.
- De verificatieservice gebruikt de geconfigureerde autorisatieregels om te bepalen welke kenmerken de verbonden clients hebben. Deze kenmerken bepalen welke bewerkingen de client kan uitvoeren, inclusief het CONNECT-pakket zelf.
- De verificatieservice retourneert de beslissing naar de front-endbroker.
- De front-endbroker kent de clientkenmerken en als het is toegestaan verbinding te maken. Zo ja, dan wordt de MQTT-verbinding voltooid en kan de client MQTT-pakketten blijven verzenden en ontvangen zoals bepaald door de autorisatieregels.
Kubernetes-serviceaccounttokens
Kubernetes SAT's zijn JSON-webtokens die zijn gekoppeld aan Kubernetes-serviceaccounts. Clients presenteren SAT's aan de MQTT-broker om zichzelf te verifiëren.
De MQTT Broker maakt gebruik van afhankelijke serviceaccounttokens die worden beschreven in de post Wat GKE-gebruikers moeten weten over de nieuwe serviceaccounttokens van Kubernetes. Dit zijn de belangrijkste functies van het bericht:
Gebonden tokens die zijn gestart in Kubernetes 1.13 en de standaardindeling in 1.21 werden. Afhankelijke tokens hebben betrekking op alle beperkte functionaliteit van verouderde tokens en meer:
- De tokens zijn moeilijk te stelen en misbruiken. Ze zijn tijdsgebonden, doelgroepgebonden en objectgebonden.
- Ze gebruiken een gestandaardiseerde indeling. OpenID Connect (OIDC), met volledige OIDC Discovery, maakt het eenvoudiger voor serviceproviders om ze te accepteren.
- Ze worden veiliger gedistribueerd naar pods met behulp van een nieuw geprojecteerd Kubelet-volumetype.
De broker controleert tokens met behulp van de Kubernetes Token Review-API. Schakel de Kubernetes-functie TokenRequestProjection in om op te geven audiences (standaard sinds 1.21). Als deze functie niet is ingeschakeld, kunt u geen SAT's gebruiken.
Een serviceaccount maken
Als u SAT's wilt maken, maakt u eerst een serviceaccount. Met de volgende opdracht maakt u een serviceaccount met de naam mqtt-client:
kubectl create serviceaccount mqtt-client -n azure-iot-operations
Optioneel: Kenmerken voor autorisatie toevoegen
Clients die verificatie via SAT uitvoeren, kunnen optioneel hun serviceaccounts voorzien van kenmerken die moeten worden gebruikt met autorisatiebeleid. Als u deze aantekeningen van anderen wilt onderscheiden, beginnen ze met aio-broker-auth/ het voorvoegsel.
U kunt aantekeningen toevoegen aan een serviceaccount met behulp van kubectl annotate:
kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations
U kunt de aantekeningen ook toevoegen aan het manifestbestand van het serviceaccount:
apiVersion: v1
kind: ServiceAccount
metadata:
name: <SERVICE_ACCOUNT_NAME>
namespace: azure-iot-operations
annotations:
aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>
Zie Clients autoriseren die kubernetes-serviceaccounttokens gebruiken voor meer informatie.
SAT-verificatie inschakelen
Wijzig de authenticationMethods instelling in een BrokerAuthentication-resource om op te geven ServiceAccountToken als een geldige verificatiemethode. De audiences parameter geeft de lijst met geldige doelgroepen voor tokens op. Kies unieke waarden waarmee de MQTT-brokerservice wordt geïdentificeerd. U moet ten minste één doelgroep opgeven en alle SAT's moeten overeenkomen met een van de opgegeven doelgroepen.
- Ga in Azure Portal naar uw IoT Operations-exemplaar.
- Selecteer onder Onderdelen de optie MQTT Broker.
- Selecteer het tabblad Verificatie.
- Kies een bestaand verificatiebeleid of maak een nieuw beleid.
- Voeg een nieuwe methode toe door de methode Toevoegen te selecteren.
- Kies het methodetype Kubernetes SAT in de vervolgkeuzelijst. Selecteer vervolgens Details toevoegen om de methode te configureren.
SAT-verificatie testen
SAT-verificatie maakt gebruik van de verbeterde MQTT v5-verificatievelden. Een client moet de verbeterde verificatiemethode instellen op K8S-SAT en de verbeterde verificatiegegevens op het token.
Gebruik bijvoorbeeld Mosquitto (sommige velden die zijn weggelaten voor beknoptheid):
mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>
<TOKEN> Hier is het token voor het serviceaccount. Voer het volgende uit om een testtoken op te halen:
kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>
<SERVICE_ACCOUNT> Dit is de naam van het serviceaccount dat u hebt gemaakt en <AUDIENCE> is een van de doelgroepen die zijn geconfigureerd in de BrokerAuthentication-resource.
Zie Verbinding maken met de standaardlistener in het cluster voor een voorbeeld van het configureren van een Kubernetes-pod voor het gebruik van SAT-verificatie.
In de podconfiguratie moet het serviceAccountName veld overeenkomen met het serviceaccount dat is gekoppeld aan het token dat wordt gebruikt. Het serviceAccountToken.audience veld moet een van de audiences geconfigureerde velden zijn in de BrokerAuthentication-resource.
Serviceaccounttokens vernieuwen
Tokens voor serviceaccounts zijn gedurende een beperkte tijd geldig en geconfigureerd met expirationSeconds. Kubernetes vernieuwt het token echter automatisch voordat het verloopt. Het token wordt op de achtergrond vernieuwd en de client hoeft niets anders te doen dan het opnieuw ophalen.
Als de client bijvoorbeeld een pod is die het token gebruikt dat als volume is gekoppeld, zoals in het voorbeeld van de sat-verificatietest , is het meest recente token beschikbaar op hetzelfde pad /var/run/secrets/tokens/broker-sat. Wanneer de client een nieuwe verbinding maakt, kan de client het meest recente token ophalen en gebruiken om te verifiëren. De client moet ook een mechanisme hebben voor het afhandelen van niet-geautoriseerde MQTT-fouten door het meest recente token op te halen en de verbinding opnieuw uit te voeren.
Aangepaste verificatie
Breid clientverificatie uit buiten de opgegeven verificatiemethoden met aangepaste verificatie. Het is pluggable omdat de service alles kan zijn zolang deze voldoet aan de API.
Wanneer een client verbinding maakt met de MQTT-broker waarvoor aangepaste verificatie is ingeschakeld, verzendt de broker een HTTPS-aanvraag naar een aangepaste verificatieserver met de referenties van de client. De server reageert vervolgens met goedkeuring of weigering, inclusief de autorisatiekenmerken van de client.
Aangepaste verificatieservice maken
De aangepaste verificatieserver wordt afzonderlijk van de MQTT-broker geïmplementeerd en geïmplementeerd.
Er zijn een voorbeeld van een aangepaste verificatieserver en instructies beschikbaar op GitHub. Gebruik dit voorbeeld als sjabloon en een uitgangspunt voor het implementeren van uw eigen aangepaste verificatielogica.
API
De API tussen de MQTT-broker en de aangepaste verificatieserver volgt de API-specificatie voor aangepaste verificatie. De OpenAPI-specificatie is beschikbaar op GitHub.
HTTPS met TLS-versleuteling is vereist
De MQTT-broker verzendt aanvragen met gevoelige clientreferenties naar de aangepaste verificatieserver. Om deze referenties te beveiligen, moet de communicatie tussen de MQTT-broker en de aangepaste verificatieserver worden versleuteld met TLS.
De aangepaste verificatieserver moet een servercertificaat presenteren en de MQTT-broker moet een vertrouwd basis-CA-certificaat hebben voor het valideren van het servercertificaat. Optioneel vereist de aangepaste verificatieserver mogelijk dat de MQTT-broker een clientcertificaat presenteert om zichzelf te verifiëren.
Aangepaste verificatie inschakelen voor een listener
Wijzig de instelling verificatiemethoden in een BrokerAuthentication-resource om Aangepast op te geven als een geldige verificatiemethode. Geef vervolgens de parameters op die nodig zijn om te communiceren met een aangepaste verificatieserver.
Ga in Azure Portal naar uw IoT Operations-exemplaar.
Selecteer onder Onderdelen de optie MQTT Broker.
Selecteer het tabblad Verificatie.
Kies een bestaand verificatiebeleid of maak een nieuw beleid.
Voeg een nieuwe methode toe door de methode Toevoegen te selecteren.
Kies het methodetype Aangepast in de vervolgkeuzelijst. Selecteer vervolgens Details toevoegen om de methode te configureren.
Verificatie uitschakelen
Voor het testen kunt u verificatie uitschakelen voor een broker-listenerpoort. Het wordt afgeraden om verificatie voor productieomgevingen uit te schakelen.
- Ga in Azure Portal naar uw IoT Operations-exemplaar.
- Selecteer onder Onderdelen de optie MQTT Broker.
- Selecteer de brokerlistener die u wilt bewerken in de lijst.
- Selecteer Geen in de vervolgkeuzelijst verificatie op de poort waar u verificatie wilt uitschakelen.
Clients verbreken de verbinding nadat de referenties zijn verlopen
De MQTT-broker verbreekt clients wanneer hun referenties verlopen. Verbinding verbreken nadat de referenties zijn verlopen, is van toepassing op alle clients die verbinding maken met de MQTT-brokerfront-ends, zoals:
- Clients die zijn geverifieerd met SAT's, verbreken de verbinding wanneer hun SAT verloopt.
- Clients geverifieerd met X.509 verbreken de verbinding wanneer hun clientcertificaat verloopt.
- Clients die zijn geverifieerd met aangepaste verificatie, verbreken op basis van de verlooptijd die is geretourneerd door de aangepaste verificatieserver.
Bij de verbinding wordt de netwerkverbinding van de client gesloten. De client ontvangt geen MQTT DISCONNECT-pakket, maar de broker registreert een bericht dat de verbinding met de client is verbroken.
MQTT v5-clients die zijn geverifieerd met SAT's en aangepaste verificatie kunnen opnieuw worden geverifieerd met een nieuwe referentie voordat hun initiële referentie verloopt. X.509-clients kunnen de verbinding niet opnieuw verifiëren en moeten de verbinding herstellen omdat verificatie wordt uitgevoerd op de TLS-laag.
Clients kunnen opnieuw verifiëren door een MQTT v5 AUTH-pakket met reden ReAuthte verzenden.
SAT-clients verzenden een AUTH-client met de velden method: K8S-SAT en data: <token>. Aangepaste verificatieclients stellen de methode en het gegevensveld in zoals vereist door de aangepaste verificatieserver.
Met een geslaagde herverificatie wordt de vervaldatum van de referenties van de client bijgewerkt met de verlooptijd van de nieuwe referentie. De broker reageert met een Success AUTH-pakket. Verificatie is mislukt vanwege tijdelijke problemen, zoals de aangepaste verificatieserver die niet beschikbaar is, zorgt ervoor dat de broker reageert met een ContinueAuthentication AUTH-pakket. De client kan het later opnieuw proberen. Andere verificatiefouten zorgen ervoor dat de broker een DISCONNECT-pakket verzendt en de netwerkverbinding van de client sluit.