Concedere a un'entità servizio l'accesso ad Azure

Completato

Di per sé, un'entità servizio non può eseguire alcuna operazione nell'ambiente Azure. È proprio come un utente che non può usare le risorse di Azure a meno che non sia autorizzato a farlo. In questa unità verrà illustrato come autorizzare le entità servizio a distribuire e configurare le risorse di Azure, evitando di concedere autorizzazioni non necessarie.

Nota

I comandi riportati in questa unità vengono illustrati per spiegare i concetti. Non eseguire ancora i comandi. Presto sarà possibile provare quanto appreso.

Autorizzazione delle entità servizio

Fino a questo momento si è posta l'attenzione su che cosa sono le entità servizio e su come usarle per dimostrare l'identità di una pipeline a Microsoft Entra ID. Tutto questo riguarda l'autenticazione.

Dopo che Microsoft Entra ID ha autenticato un'entità servizio, la domanda successiva è: che cosa può fare l'entità servizio? 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'entità servizio 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 di servizio app 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 entità servizio 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 può essere usato per entrambe le situazioni in questa documentazione.

Selezionare l'assegnazione di ruolo appropriata per la pipeline

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'entità servizio, si assegnano i ruoli per tale entità servizio, Per identificare l'entità servizio corretta per l'assegnatario, è possibile usare l'ID applicazione dell'entità servizio.

Ruolo

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

• Lettore, che consente all'assegnatario di leggere le informazioni sulle risorse, ma non di modificarle o eliminarle.
• Collaboratore, che 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, che consente il controllo completo sulle risorse, inclusa la possibilità di concedere l'accesso ad altre entità.

Attenzione

È consigliabile concedere alle entità servizio solo le autorizzazioni minime necessarie per svolgere il lavoro. Nella maggior parte dei casi, il ruolo Proprietario è troppo permissivo per una pipeline di distribuzione.

Ci sono anche diversi ruoli specifici che consentono l'accesso solo a un subset di funzionalità. Inoltre, è 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 del ruolo personalizzata e si potrebbero accidentalmente rendere troppo restrittive o troppo permissive le definizioni dei ruoli. 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, Ciò influisce sul numero di risorse che l'entità servizio può modificare. Gli ambiti comuni includono:

• Risorsa singola: è possibile concedere l'accesso solo a una risorsa specifica. In genere le pipeline di distribuzione non usano questo ambito perché una pipeline 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 molte pipeline 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 una pipeline di distribuzione. È invece consigliabile limitare l'ambito delle assegnazioni di ruolo ai gruppi di risorse, a meno che lo stesso 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 avrà 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 la pipeline serve solo per distribuire modelli Bicep di base e non gestirà le assegnazioni di ruolo, non usare il ruolo Proprietario.
• Usare l'ambito più ristretto possibile. La maggior parte delle pipeline deve solo distribuire le risorse in un gruppo di risorse, quindi non necessita di assegnazioni dei ruoli con ambito di sottoscrizione.
• Per molte pipeline, 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 attualmente dalla pipeline e tutte le eventuali attività future. È ad esempio possibile valutare l'opportunità di creare una definizione del ruolo personalizzata per la pipeline di distribuzione del sito Web e concedere solo le autorizzazioni 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 la pipeline 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 possibile assegnare a un'entità servizio il ruolo Lettore con l'intera sottoscrizione come ambito e quindi assegnare separatamente alla stessa entità servizio il ruolo Collaboratore per un gruppo di risorse specifico. Quando l'entità servizio 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.

È consigliabile creare entità servizio separate per ogni ambiente e concedere a ogni entità servizio il set minimo di autorizzazioni necessarie per le distribuzioni. Prestare particolare attenzione per evitare di combinare le autorizzazioni per le distribuzioni di produzione con quelle per le distribuzioni in ambienti non di produzione.

Creare un'assegnazione di ruolo per un'entità servizio

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

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline 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'entità servizio. Per evitare ambiguità, è consigliabile usare l'ID applicazione.
• --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'entità servizio, usare il cmdlet New-AzRoleAssignment. È necessario specificare l'assegnatario, il ruolo e l'ambito:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline 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 della registrazione dell'applicazione dell'entità servizio.
• -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.

Creare un'entità servizio e un'assegnazione di ruolo in un'unica operazione

È anche possibile creare un'assegnazione di ruolo durante la creazione di un'entità servizio. Questo codice è analogo al comando usato per creare un'entità servizio nelle unità precedenti, ma con alcuni argomenti aggiuntivi:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

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 e quindi si distribuiscono le risorse nel gruppo di risorse usando un'entità servizio. Di seguito è riportato un esempio di definizione Bicep per l'assegnazione di ruolo precedente:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline 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 per l'assegnazione di ruolo. Deve avere il formato di un identificatore univoco globale (GUID). È consigliabile usare la funzione guid() in Bicep per creare un GUID e usare l'ID dell'entità, l'ID della definizione del ruolo e l'ambito come argomenti di inizializzazione per la funzione per assicurarsi di creare un nome univoco per ogni assegnazione di ruolo.
• principalType deve essere impostato su ServicePrincipal.
• roleDefinitionId è l'ID della risorsa completo per la definizione del ruolo che si sta assegnando. Principalmente si useranno ruoli predefiniti, e 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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.