Concedere a un'identità dei carichi di lavoro l'accesso ad Azure

Completato

Un'identità dei carichi di lavoro, di per sé, non può eseguire alcuna operazione nell'ambiente Azure, esattamente come un utente non può usare le risorse di Azure senza autorizzazione. In questa unità verrà illustrato come autorizzare le identità dei carichi di lavoro a distribuire e configurare le risorse di Azure, evitando di concedere autorizzazioni non necessarie.

Autorizzazione dell'identità del carico di lavoro

Fino a questo momento si è posta l'attenzione su che cosa sono le identità dei carichi di lavoro e su come usarle per dimostrare l'identità di un flusso di lavoro di distribuzione a Microsoft Entra ID. Tutto questo riguarda l'autenticazione.

Dopo che Microsoft Entra ID ha autenticato un'identità del carico di lavoro, la domanda successiva è: che cosa può fare l'identità del carico di lavoro? Si tratta del concetto di autorizzazione. È responsabilità del sistema di controllo degli accessi in base al ruolo di Azure, talvolta denominato IAM (Identity and Access Management, gestione delle identità e degli accessi). Usando il controllo degli accessi in base al ruolo di Azure, è possibile concedere a un'identità del carico di lavoro l'accesso a un gruppo di risorse, una sottoscrizione o un gruppo di gestione specifico.

Nota

Ciò che si sta facendo qui è usare il sistema di controllo degli accessi in base al ruolo di Azure per concedere l'accesso per la creazione e la gestione delle risorse di Azure, ad esempio gli account di archiviazione, il piano Servizio app di Azure e le reti virtuali. Microsoft Entra ID ha anche un proprio sistema di ruoli, a volte chiamato ruoli della directory. Questi ruoli consentono di concedere alle identità dei carichi di lavoro le autorizzazioni per la gestione di Microsoft Entra ID. Questo argomento non viene trattato in modo approfondito in questo modulo, ma è importante tenere presente che il termine ruolo viene usato per entrambe le situazioni in questa documentazione.

Selezionare l'assegnazione di ruolo appropriata per il flusso di lavoro

Un'assegnazione di ruolo ha tre parti principali: la persona a cui viene assegnato il ruolo (assegnatario), ciò che può fare (ruolo) e la risorsa o le risorse a cui si applica l'assegnazione di ruolo (ambito).

Assegnatario

Quando si usa un'identità del carico di lavoro, si assegnano i ruoli per tale identità. Per assegnare un ruolo, è prima necessario creare un'entità servizio, che consente di concedere i ruoli dell'applicazione in Azure. Dopo aver creato l'entità servizio, è possibile continuare a usare l'ID applicazione della registrazione dell'applicazione.

Per creare un'entità servizio, usare il comando az ad sp create e specificare l'ID app della registrazione dell'applicazione:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Per creare un'entità servizio, usare il cmdlet New-AzADServicePrincipal e specificare l'ID app della registrazione dell'applicazione:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Ruolo

Determinare il ruolo da assegnare può essere un po' più complesso. In Azure esistono alcuni ruoli comuni:

• Lettore: Consente all'assegnatario di leggere le informazioni sulle risorse, ma non di modificarle o eliminarle.
• Collaboratore: Consente all'assegnatario di creare le risorse, nonché di leggere e modificare le risorse esistenti. I collaboratori non possono tuttavia concedere ad altre entità l'accesso alle risorse.
• Proprietario: consente il controllo completo sulle risorse, inclusa la possibilità di concedere l'accesso ad altre entità.

Attenzione

Concedere alle identità dei carichi di lavoro solo le autorizzazioni minime necessarie per svolgere il lavoro. Nella maggior parte dei casi, il ruolo Proprietario è troppo permissivo per un flusso di lavoro di distribuzione.

Ci sono anche diversi ruoli specifici che consentono l'accesso a un subset di funzionalità. È persino possibile creare una definizione del ruolo personalizzata per specificare l'elenco esatto di autorizzazioni da assegnare.

Nota

Le definizioni dei ruoli personalizzate possono essere un metodo efficace per concedere le autorizzazioni per le risorse di Azure, ma possono essere difficili da usare. Non è sempre facile determinare esattamente quali autorizzazioni è necessario aggiungere a una definizione di ruolo personalizzata. È possibile che le definizioni dei ruoli diventino accidentalmente troppo restrittive o troppo permissive.

Se non si è sicuri di come procedere, è meglio usare una delle definizioni di ruolo predefinite. Le definizioni di ruolo personalizzate esulano dall'ambito di questo modulo.

Ambito

È necessario determinare la portata del ruolo assegnato, Questa decisione influisce sul numero di risorse che l'identità del carico di lavoro può modificare. Gli ambiti comuni includono:

• Risorsa singola: è possibile concedere l'accesso a una risorsa specifica. In genere i flussi di lavoro di distribuzione non usano questo ambito perché un flusso di lavoro crea risorse che ancora non esistono o riconfigura più risorse.
• Gruppo di risorse: è possibile concedere l'accesso a tutte le risorse di un gruppo di risorse. Collaboratori e proprietari possono anche creare risorse all'interno del gruppo. È un'opzione valida per molti flussi di lavoro di distribuzione.
• Sottoscrizione: è possibile concedere l'accesso a tutte le risorse all'interno di una sottoscrizione. Se si hanno più applicazioni, carichi di lavoro o ambienti in una singola sottoscrizione, è possibile concedere le autorizzazioni per l'ambito della sottoscrizione. Questa impostazione, tuttavia, è in genere troppo permissiva per un flusso di lavoro di distribuzione. È invece consigliabile limitare l'ambito delle assegnazioni di ruolo ai gruppi di risorse, a meno che il flusso di lavoro di distribuzione non debba creare gruppi di risorse.

Tenere presente che le assegnazioni dei ruoli vengono ereditate. Se si assegna un ruolo a livello di sottoscrizione, l'assegnatario ha accesso a ogni gruppo di risorse e a ogni risorsa all'interno di tale sottoscrizione.

Scelta dell'assegnazione di ruolo appropriata

Ora che si conoscono i componenti di un'assegnazione di ruolo, è possibile decidere i valori appropriati per gli scenari. Ecco alcune linee guida generali da tenere in considerazione:

• Usare il ruolo meno permissivo possibile. Se il flusso di lavoro serve solo per distribuire file Bicep di base e non gestirà le assegnazioni di ruolo, non usare il ruolo Proprietario.

• Usare l'ambito più ristretto possibile. La maggior parte dei flussi di lavoro deve solo distribuire le risorse in un gruppo di risorse, quindi non necessita di assegnazioni di ruolo con ambito sottoscrizione.

• Per molti flussi di lavoro, una valida opzione predefinita per un'assegnazione di ruolo è il ruolo Collaboratore per l'ambito del gruppo di risorse.

• Prendere in considerazione tutte le attività eseguite dal flusso di lavoro e tutte le eventuali attività future. È ad esempio possibile valutare l'opportunità di creare una definizione del ruolo personalizzata per il flusso di lavoro di distribuzione del sito Web e concedere le autorizzazioni solo per Servizio app e Application Insights. Tra un mese potrebbe essere necessario aggiungere un account Azure Cosmos DB al file Bicep, ma il ruolo personalizzato impedirà la creazione delle risorse di Azure Cosmos DB.

  Spesso è invece meglio usare un ruolo predefinito o una combinazione di ruoli predefiniti per evitare di dover modificare ripetutamente le definizioni dei ruoli. Valutare l'opportunità di usare Criteri di Azure per applicare i requisiti di governance per servizi, SKU e località consentiti.

• Testare il flusso di lavoro per verificare il funzionamento dell'assegnazione di ruolo.

Combinazione di assegnazioni di ruolo

È possibile creare più assegnazioni di ruolo che forniscono autorizzazioni diverse in ambiti diversi. Ad esempio, si potrebbe assegnare un'identità del carico di lavoro al ruolo Lettore con l'intera sottoscrizione come ambito. È possibile assegnare separatamente la stessa identità del carico di lavoro al ruolo Collaboratore per un gruppo di risorse specifico. Quando l'identità del carico di lavoro prova a usare il gruppo di risorse, viene applicata l'assegnazione più permissiva.

Uso di più ambienti

È probabile che si usino diversi ambienti, ad esempio un ambiente di sviluppo, uno di test e uno di produzione, per le applicazioni. Le risorse per ogni ambiente devono essere distribuite in sottoscrizioni o gruppi di risorse diversi.

È necessario creare identità dei carichi di lavoro separate per ogni ambiente. Concedere a ogni identità del carico di lavoro il set minimo di autorizzazioni necessarie per le distribuzioni. Prestare particolare attenzione a evitare di combinare le autorizzazioni per le distribuzioni di produzione con le autorizzazioni per le distribuzioni in ambienti non di produzione.

Creare un'assegnazione di ruolo per un'identità del carico di lavoro

Per creare un'assegnazione di ruolo per un'identità del carico di lavoro, usare il comando az role assignment create. È necessario specificare l'assegnatario, il ruolo e l'ambito:

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Di seguito viene esaminato ogni argomento:

• --assignee specifica l'identità del carico di lavoro. È possibile specificarla in diversi modi, ma l'uso dell'ID applicazione è una procedura consigliata perché evita ambiguità.
• --role specifica il ruolo. Se si usa un ruolo predefinito, è possibile specificarlo per nome. Se si usa una definizione del ruolo personalizzata, specificare l'ID completo della definizione di ruolo.
• --scope specifica l'ambito. Si tratta in genere dell'ID di una singola risorsa, gruppo di risorse o sottoscrizione.
• --description è una descrizione in formato leggibile dell'assegnazione di ruolo.

Per creare un'assegnazione di ruolo per un'identità del carico di lavoro, usare il cmdlet New-AzRoleAssignment. Specificare l'assegnatario, il ruolo e l'ambito:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Di seguito viene esaminato ogni argomento:

• -ApplicationId specifica l'ID di registrazione dell'applicazione dell'identità del carico di lavoro.
• -RoleDefinitionName specifica il nome di un ruolo predefinito. Se si usa una definizione del ruolo personalizzata, specificare invece l'ID completo della definizione di ruolo usando l'argomento -RoleDefinitionId.
• -Scope specifica l'ambito. Si tratta in genere dell'ID di una singola risorsa, gruppo di risorse o sottoscrizione.
• -Description è una descrizione in formato leggibile dell'assegnazione di ruolo.

Suggerimento

È consigliabile fornire una giustificazione per le assegnazioni dei ruoli specificando una descrizione. Una descrizione aiuta chiunque esamini le assegnazioni di ruolo in un secondo momento a comprendere il relativo scopo e come sono stati decisi l'assegnatario, il ruolo e l'ambito.

Nota

L'attivazione delle assegnazioni dei ruoli può richiedere alcuni minuti.

Concedere l'accesso usando Bicep

Le assegnazioni di ruolo sono risorse di Azure. Ciò significa che è possibile creare un'assegnazione di ruolo usando Bicep. È possibile eseguire questa operazione se si inizializzano i gruppi di risorse con Bicep, quindi si distribuiscono le risorse nel gruppo di risorse usando un'identità del carico di lavoro. Di seguito è riportato un esempio di definizione Bicep per l'assegnazione di ruolo precedente:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Di seguito viene esaminato ogni argomento:

• name è un identificatore univoco globale (GUID) per l'assegnazione di ruolo. È consigliabile usare la funzione guid() in Bicep per creare un GUID. Per assicurarsi di creare un nome univoco per ogni assegnazione di ruolo, usare l'ID di entità, l'ID di definizione del ruolo e l'ambito come argomenti di inizializzazione per la funzione.

• principalType deve essere impostato su ServicePrincipal.

• roleDefinitionId è l'ID della risorsa completo per la definizione del ruolo che si sta assegnando. Si usano principalmente ruoli predefiniti, quindi l'ID della definizione del ruolo è disponibile nella documentazione relativa ai ruoli predefiniti di Azure.

  Il ruolo Collaboratore ha ad esempio l'ID della definizione del ruolo b24988ac-6180-42a0-ab88-20f7382dd24c. Quando lo si specifica nel file Bicep, si usa un ID risorsa completo, ad esempio /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.

• principalId è l'ID oggetto dell'entità servizio. Assicurarsi di non usare l'ID applicazione o l'ID oggetto della registrazione dell'applicazione.

• description è una descrizione in formato leggibile dell'assegnazione di ruolo.