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.
MQTT Broker ondersteunt meerdere verificatiemethoden voor clients en u kunt elke listenerpoort configureren voor een 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 kan meerdere poorten hebben. Elke poort kan worden gekoppeld aan een BrokerAuthentication-resource .
- Elke BrokerAuthentication 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 wordt alleen gebruikgemaakt van Kubernetes Service Account Tokens (SAT's) voor verificatie.
Belangrijk
De verificatiemethode voor het serviceaccount (SAT) in de standaard-BrokerAuthentication-resource is vereist voor onderdelen in de Azure IoT-bewerkingen om correct te functioneren. Vermijd het bijwerken of verwijderen van de standaard BrokerAuthentication-resource .
Navigeer 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 MQTT Broker clients verifieert. 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 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 MQTT Broker of deze geldig zijn. Zie de sectie Verificatiemethode configureren voor meer informatie.
Voor aangepaste verificatie behandelt MQTT Broker het niet communiceren met de aangepaste verificatieserver als referenties die niet relevant zijn. Met dit gedrag kan 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.
- 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 worden aangepaste en SAT opgegeven. Wanneer een client verbinding maakt, probeert MQTT-broker de client te verifiëren met behulp van de opgegeven methoden in de aangepaste volgorde en vervolgens SAT.
- 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
PassofFailhet resultaat, eindigt de verificatiestroom. Als de aangepaste verificatieserver echter niet beschikbaar is, valt MQTT-broker terug op de resterende opgegeven methoden, waarbij SAT de volgende is. - 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:
Navigeer 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 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 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).
Met X.509-verificatie gebruikt de MQTT-broker een vertrouwd CA-certificaat 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 aan de volgende vereisten worden voldaan:
- TLS: 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 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 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.pem en een persoonlijke sleutel ca-key.pem in PEM-indeling. Het CA-certificaat ca.pem kan worden geïmporteerd 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. MQTT Broker vertrouwt alle CA-certificaten in de ConfigMap, zodat de naam van de sleutel alles kan zijn.
Als u wilt controleren of het basis-CA-certificaat juist is geïmporteerd, voert u de opdracht uit kubectl describe configmap. 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
Zodra 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.
Navigeer 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 en selecteer Details toevoegen om de methode te configureren.
Geef in het deelvenster X.509-verificatiedetails de naam van het vertrouwde CA-certificaat ConfigMap op met de JSON-indeling.
{ "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>" }Vervang
<TRUSTED_CA_CONFIGMAP>door de naam van de ConfigMap die het vertrouwde CA-certificaat bevat. Bijvoorbeeld:"trustedClientCaCert": "client-ca".
Voeg eventueel autorisatiekenmerken toe voor clients met X.509-certificaten. Zie Certificaatkenmerken voor autorisatie voor meer informatie.
Selecteer Toepassen om de wijzigingen op te slaan.
Optioneel: Certificaatkenmerken voor autorisatie
X.509-kenmerken kunnen worden opgegeven in de BrokerAuthentication-resource voor het autoriseren van clients op basis van hun certificaateigenschappen. De kenmerken worden gedefinieerd in het authorizationAttributes veld.
Voorbeeld:
Voeg in Azure Portal bij het configureren van de X.509-verificatiemethode 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.
Autorisatieregels kunnen worden toegepast 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 servervalidatie en clientvalidatie:
- 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 X.509-verificatie is 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 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 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 bij het maken van verbinding via TLS. Als de uitgever 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
Hier volgen de stappen voor clientverificatie:
- Wanneer X.509-clientverificatie is ingeschakeld, moeten clients een clientcertificaat en tussenliggende certificaten presenteren om MQTT-broker een certificaatketen te laten bouwen die is geroot op een van de geconfigureerde vertrouwde certificaten.
- De load balancer stuurt de communicatie naar een van de front-endbrokers.
- Zodra 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 heeft gebouwd en de gepresenteerde keten is 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 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.
- Verificatieservice retourneert beslissing naar 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 Service Account Tokens (SAT's) zijn JSON-webtokens die zijn gekoppeld aan Kubernetes-serviceaccounts. Clients presenteren SAT's aan de MQTT-broker om zichzelf te verifiëren.
MQTT Broker maakt gebruik van afhankelijke serviceaccounttokens die worden beschreven in de informatie die GKE-gebruikers nodig hebben over de nieuwe serviceaccounttokens van Kubernetes. Dit zijn de opvallende functies van het bericht:
Gestart in Kubernetes 1.13 en de standaardindeling in 1.21 worden, zijn afhankelijke tokens gericht op alle beperkte functionaliteit van verouderde tokens en meer:
- De tokens zelf zijn moeilijker te stelen en misbruiken; ze zijn tijdsgebonden, doelgroepgebonden en objectgebonden.
- Ze gebruiken een gestandaardiseerde indeling: OpenID Connect (OIDC), met volledige OIDC Discovery, waardoor serviceproviders ze gemakkelijker kunnen 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, kunnen SAT's niet worden gebruikt.
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 (Service Account Token) inschakelen
Wijzig de authenticationMethods instelling in een BrokerAuthentication-resource om op te geven ServiceAccountToken als een geldige verificatiemethode. Hiermee audiences geeft u 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.
- Navigeer 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 en selecteer 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 om kort te zijn):
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 in overeenkomen met het serviceaccount dat is gekoppeld aan het token dat wordt gebruikt en moet het serviceAccountToken.audience veld een van de audiences geconfigureerde velden in de BrokerAuthentication-resource zijn.
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 is gekoppeld als een volume, zoals in het voorbeeld van de sat-verificatietest , is het meest recente token beschikbaar op hetzelfde pad /var/run/secrets/tokens/broker-sat. Bij het maken van een nieuwe verbinding 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 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 beginpunt voor het implementeren van uw eigen aangepaste verificatielogica.
API
De API tussen 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
MQTT Broker verzendt aanvragen met gevoelige clientreferenties naar de aangepaste verificatieserver. Om deze referenties te beveiligen, moet communicatie tussen MQTT Broker en aangepaste verificatieserver worden versleuteld met TLS.
De aangepaste verificatieserver moet een servercertificaat presenteren en MQTT Broker moet een vertrouwd basis-CA-certificaat hebben voor het valideren van het servercertificaat. Optioneel vereist de aangepaste verificatieserver mogelijk MQTT Broker om een clientcertificaat te presenteren om zichzelf te verifiëren.
Aangepaste verificatie inschakelen voor een listener
Wijzig de authenticationMethods instelling in een BrokerAuthentication-resource om op te geven Custom als een geldige verificatiemethode. Geef vervolgens de parameters op die nodig zijn om te communiceren met een aangepaste verificatieserver.
Navigeer 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 en selecteer Details toevoegen om de methode te configureren.
Verificatie uitschakelen
Voor het testen kunt u verificatie uitschakelen voor een broker-listenerpoort. Het uitschakelen van verificatie wordt niet aanbevolen voor productieomgevingen.
- Navigeer 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 die u wilt uitschakelen.
Clients verbreken de verbinding nadat de referenties zijn verlopen
MQTT-broker verbreekt clients wanneer hun referenties verlopen. Verbinding verbreken na verloop van referenties is van toepassing op alle clients die verbinding maken met de MQTT-broker-front-ends, waaronder:
- Clients 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 niet opnieuw verifiëren en moeten de verbinding opnieuw tot stand brengen 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. 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 en reageert de broker met een Success AUTH-pakket. Verificatie is mislukt vanwege tijdelijke problemen, zoals de aangepaste verificatieserver die niet beschikbaar is, waardoor 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.