Condividi tramite

Configurare l'autorizzazione dell'anteprima mq di Azure IoT

  • Articolo

Importante

Anteprima delle operazioni di Azure IoT: abilitata da Azure Arc è attualmente disponibile in ANTEPRIMA. Non è consigliabile usare questo software di anteprima negli ambienti di produzione.

Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

I criteri di autorizzazione determinano le azioni che i client possono eseguire sul broker, ad esempio connettersi, pubblicare o sottoscrivere argomenti. Configurare l'anteprima mq di Azure IoT per l'uso di uno o più criteri di autorizzazione con la risorsa BrokerAuthorization .

È possibile impostare su un brokerAuthorization per ogni listener. Ogni risorsa BrokerAuthorization contiene un elenco di regole che specificano le entità e le risorse per i criteri di autorizzazione.

Importante

Per fare in modo che la configurazione brokerAuthorization si applichi a un listener, almeno un BrokerAuthentication deve essere collegato anche a tale listener.

Configurare BrokerAuthorization per i listener

La specifica di una risorsa BrokerAuthorization include i campi seguenti:

Nome campo Richiesto Descrizione
listenerRef Sì Nomi delle risorse BrokerListener applicabili a questo criterio di autorizzazione. Questo campo è obbligatorio e deve corrispondere a una risorsa BrokerListener esistente nello stesso spazio dei nomi.
authorizationPolicies Sì Questo campo definisce le impostazioni per i criteri di autorizzazione, ad esempio enableCache e le regole.
enableCache No Se abilitare la memorizzazione nella cache per i criteri di autorizzazione. Se impostato su true, il broker memorizza nella cache i risultati dell'autorizzazione per ogni combinazione di client e argomenti per migliorare le prestazioni e ridurre la latenza. Se impostato su false, il broker valuta i criteri di autorizzazione per ogni richiesta client e argomento, per garantire coerenza e accuratezza. Questo campo è facoltativo e il valore predefinito è false.
regole No Elenco di regole che specificano le entità di sicurezza e le risorse per i criteri di autorizzazione. Ogni regola include questi sottocampi: principals e brokerResources.
Entità Sì Questo sottocampo definisce le identità che rappresentano i client, ad esempio nomi utente, clientid e attributi.
Username No Elenco di nomi utente che corrispondono ai client. I nomi utente fanno distinzione tra maiuscole e minuscole e devono corrispondere ai nomi utente forniti dai client durante l'autenticazione.
clientid No Elenco di ID client che corrispondono ai client. Gli ID client fanno distinzione tra maiuscole e minuscole e devono corrispondere agli ID client forniti dai client durante la connessione.
Attributi No Elenco di coppie chiave-valore che corrispondono agli attributi dei client. Gli attributi fanno distinzione tra maiuscole e minuscole e devono corrispondere agli attributi forniti dai client durante l'autenticazione.
brokerResources Sì Questo sottocampo definisce gli oggetti che rappresentano le azioni o gli argomenti, ad esempio metodi e argomenti.
metodo Sì Tipo di azione che i client possono eseguire sul broker. Questo sottocampo è obbligatorio e può essere uno di questi valori: Connessione: questo valore indica che i client possono connettersi al broker. Pubblica: questo valore indica che i client possono pubblicare messaggi negli argomenti del broker. Sottoscrizione: questo valore indica che i client possono sottoscrivere argomenti nel broker.
topics No Elenco di argomenti o modelli di argomento che corrispondono agli argomenti che i client possono pubblicare o sottoscrivere. Questo sottocampo è obbligatorio se il metodo è Subscribe o Publish.

L'esempio seguente illustra come creare una risorsa BrokerAuthorization che definisce i criteri di autorizzazione per un listener denominato my-listener.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "my-listener" # change to match your listener name as needed
  authorizationPolicies:
    enableCache: true
    rules:
      - principals:
          usernames:
            - temperature-sensor
            - humidity-sensor
          attributes:
            - city: "seattle"
              organization: "contoso"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "/telemetry/{principal.username}"
              - "/telemetry/{principal.attributes.organization}"
          - method: Subscribe
            topics:
              - "/commands/{principal.attributes.organization}"

Questa autorizzazione broker consente ai client con nomi utente temperature-sensor o humidity-sensor, o client con attributi organization con valore e city con valore contososeattle, per:

  • Connessione al broker.
  • Pubblicare messaggi negli argomenti di telemetria con i nomi utente e l'organizzazione. Ad esempio:
    • temperature-sensor può pubblicare in /telemetry/temperature-sensor e /telemetry/contoso.
    • humidity-sensor può pubblicare in /telemetry/humidity-sensor e /telemetry/contoso.
    • some-other-username può pubblicare in /telemetry/contoso.
  • Sottoscrivere gli argomenti relativi ai comandi con ambito dell'organizzazione. Ad esempio:
    • temperature-sensor può sottoscrivere /commands/contoso.
    • some-other-username può sottoscrivere /commands/contoso.

Per creare questa risorsa BrokerAuthorization, applicare il manifesto YAML al cluster Kubernetes.

Autorizzare i client che usano l'autenticazione X.509

I client che usano certificati X.509 per l'autenticazione possono essere autorizzati ad accedere alle risorse in base alle proprietà X.509 presenti nel certificato o ai certificati emessi fino alla catena.

Con le proprietà della catena di certificati che usano attributi

Per creare regole in base alle proprietà del certificato di un client, alla CA radice o all'autorità di certificazione intermedia, è necessario un file TOML di mapping tra certificati e attributi. Ad esempio:

[root]
subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"

[root.attributes]
organization = "contoso"

[intermediate]
subject = "CN = Contoso Intermediate CA"

[intermediate.attributes]
city = "seattle"
foo = "bar"

[smart-fan]
subject = "CN = smart-fan"

[smart-fan.attributes]
building = "17"

In questo esempio, ogni client con un certificato emesso dalla CA CN = Contoso Root CA Cert, OU = Engineering, C = US radice o da una CA CN = Contoso Intermediate CA intermedia riceve gli attributi elencati. Inoltre, la ventola intelligente riceve attributi specifici.

La corrispondenza per gli attributi inizia sempre dal certificato client foglia e quindi va lungo la catena. L'assegnazione dell'attributo viene arrestata dopo la prima corrispondenza. Nell'esempio precedente, anche se smart-fan ha il certificato CN = Contoso Intermediate CAintermedio , non ottiene gli attributi associati.

Per applicare il mapping, creare un file TOML di mapping da certificato a attributo come segreto Kubernetes e farvi authenticationMethods.x509.attributes riferimento per la risorsa BrokerAuthentication.

È quindi possibile applicare le regole di autorizzazione ai client usando certificati X.509 con questi attributi.

Con il nome comune dell'oggetto del certificato client come nome utente

Per creare criteri di autorizzazione basati solo sul nome comune del soggetto del certificato client , creare regole basate sul cn.

Ad esempio, se un client ha un certificato con soggetto CN = smart-lock, il nome utente è smart-lock. Da qui creare i criteri di autorizzazione come di consueto.

Autorizzare i client che usano i token dell'account del servizio Kubernetes

Gli attributi di autorizzazione per le regole di sicurezza vengono impostati come parte delle annotazioni dell'account del servizio. Ad esempio, per aggiungere un attributo di autorizzazione denominato group con valore authz-sat, eseguire il comando :

kubectl annotate serviceaccount mqtt-client aio-mq-broker-auth/group=authz-sat

Le annotazioni degli attributi devono iniziare con aio-mq-broker-auth/ per distinguerle da altre annotazioni.

Poiché l'applicazione ha un attributo di autorizzazione denominato authz-sat, non è necessario fornire un clientId oggetto o username. La risorsa BrokerAuthorization corrispondente usa questo attributo come entità, ad esempio:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerAuthorization
metadata:
  name: "my-authz-policies"
  namespace: azure-iot-operations
spec:
  listenerRef:
    - "az-mqtt-non-tls-listener"
  authorizationPolicies:
    enableCache: false
    rules:
      - principals:
          attributes:
            - group: "authz-sat"
        brokerResources:
          - method: Connect
          - method: Publish
            topics:
              - "odd-numbered-orders"
          - method: Subscribe
            topics:
              - "orders"

Per altre informazioni con un esempio, vedere Configurare i criteri di autorizzazione con dapr Client.

Archivio stati distribuito

Azure IoT MQ Broker fornisce un archivio stati distribuito (DSS) che i client possono usare per archiviare lo stato. Il DSS può anche essere configurato per essere a disponibilità elevata.

Per configurare l'autorizzazione per i client che usano DSS, fornire le autorizzazioni seguenti:

  • Autorizzazione per la pubblicazione nell'argomento dell'archivio $services/statestore/_any_/command/invoke/request dei valori della chiave di sistema
  • Autorizzazione per sottoscrivere l'argomento response(impostato durante la pubblicazione iniziale come parametro) <response_topic>/#

Aggiornare l'autorizzazione

Le risorse di autorizzazione broker possono essere aggiornate in fase di esecuzione senza riavviare. Tutti i client connessi al momento dell'aggiornamento dei criteri vengono disconnessi. È supportata anche la modifica del tipo di criterio.

kubectl edit brokerauthorization my-authz-policies

Disabilitare l'autorizzazione

Per disabilitare l'autorizzazione, impostare authorizationEnabled: false nella risorsa BrokerListener. Quando i criteri sono impostati per consentire a tutti i client, tutti i client autenticati possono accedere a tutte le operazioni.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: BrokerListener
metadata:
  name: "my-listener"
  namespace: azure-iot-operations
spec:
  brokerRef: "my-broker"
  authenticationEnabled: false
  authorizationEnabled: false
  port: 1883

Pubblicazione non autorizzata in MQTT 3.1.1

Con MQTT 3.1.1, quando viene negata una pubblicazione, il client riceve puBACK senza errori perché la versione del protocollo non supporta la restituzione del codice di errore. MQTTv5 restituisce PUBACK con codice motivo 135 (non autorizzato) quando la pubblicazione viene negata.

Contenuto correlato