Creare risorse RBAC di Azure con Bicep

  • Articolo

Azure dispone di un potente sistema di controllo degli accessi in base al ruolo. Per ulteriori informazioni sul controllo degli accessi in base al ruolo di Azure, vedere Che cos'è il controllo degli accessi in base al ruolo di Azure? Usando Bicep, è possibile definire a livello di codice le assegnazioni di ruolo e le definizioni di ruolo RBAC.

Assegnazioni di ruolo

Le assegnazioni di ruolo consentono di concedere a un'entità (ad esempio un utente, un gruppo o un'entità servizio) l'accesso a una risorsa specifica di Azure.

Per definire un'assegnazione di ruolo, creare una risorsa con tipo Microsoft.Authorization/roleAssignments. Una definizione di ruolo ha più proprietà, tra cui un ambito, un nome, un ID definizione di ruolo, un ID entità e un tipo di entità.

Ambito

Le assegnazioni di ruolo si applicano a un ambito specifico, che definisce la risorsa o il set di risorse a cui si concede l'accesso. Per altre informazioni, vedere Informazioni sull'ambito per il controllo degli accessi in base al ruolo di Azure.

Le assegnazioni di ruolo sono risorse di estensione, ovvero si applicano a un'altra risorsa. L'esempio seguente illustra come creare un account di archiviazione e un'assegnazione di ruolo con ambito a tale account di archiviazione:

param location string = resourceGroup().location
param storageAccountName string = 'stor${uniqueString(resourceGroup().id)}'
param storageSkuName string = 'Standard_LRS'
param roleDefinitionResourceId string
param principalId string

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
   name: storageSkuName
  }
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: storageAccount
  name: guid(storageAccount.id, principalId, roleDefinitionResourceId)
  properties: {
    roleDefinitionId: roleDefinitionResourceId
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

Se non si specifica in modo esplicito l'ambito, Bicep usa il file targetScope. Nell'esempio seguente non viene specificata alcuna proprietà scope, pertanto l'assegnazione di ruolo ha come ambito la sottoscrizione:

param roleDefinitionResourceId string
param principalId string

targetScope = 'subscription'

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(subscription().id, principalId, roleDefinitionResourceId)
  properties: {
    roleDefinitionId: roleDefinitionResourceId
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

Suggerimento

Usare l'ambito più piccolo necessario per soddisfare i requisiti.

Ad esempio, se è necessario concedere a un'identità gestita l'accesso a un singolo account di archiviazione, è consigliabile creare l'assegnazione di ruolo nell'ambito dell'account di archiviazione, non nell'ambito del gruppo di risorse o della sottoscrizione.

Nome

Il nome della risorsa di un'assegnazione di ruolo deve essere un identificatore univoco globale (GUID).

I nomi delle risorse di assegnazione di ruolo devono essere univoci all'interno del tenant di Microsoft Entra, anche se l'ambito è più ristretto.

Affinché la distribuzione Bicep sia ripetibile, è importante che il nome sia deterministico, in altre parole, usare lo stesso nome ogni volta che si distribuisce. È consigliabile creare un GUID che usi l'ambito, l'ID entità e l'ID ruolo insieme. È consigliabile usare la funzione guid() per creare un GUID deterministico per i nomi delle assegnazioni di ruolo, come in questo esempio:

name: guid(subscription().id, principalId, roleDefinitionResourceId)

Un ID di definizione del ruolo

Il ruolo assegnato può essere una definizione di ruolo predefinita o una definizione di ruolo personalizzata. Per usare una definizione di ruolo predefinita, trovare l'ID di definizione del ruolo appropriato. Ad esempio, il ruolo Collaboratore ha un ID definizione di ruolo di b24988ac-6180-42a0-ab88-20f7382dd24c.

Quando si crea la risorsa di assegnazione di ruolo, è necessario specificare un ID risorsa completo. Gli ID di definizione del ruolo predefiniti sono risorse con ambito sottoscrizione. È consigliabile usare una risorsa existing per fare riferimento al ruolo predefinito e accedere al relativo ID risorsa completo usando la proprietà .id:

param principalId string

@description('This is the built-in Contributor role. See https://docs.microsoft.com/azure/role-based-access-control/built-in-roles#contributor')
resource contributorRoleDefinition 'Microsoft.Authorization/roleDefinitions@2018-01-01-preview' existing = {
  scope: subscription()
  name: 'b24988ac-6180-42a0-ab88-20f7382dd24c'
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, principalId, contributorRoleDefinition.id)
  properties: {
    roleDefinitionId: contributorRoleDefinition.id
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

Entità di sicurezza

La proprietà principalId deve essere impostata su un GUID che rappresenta l'identificatore Microsoft Entra per l'entità. In Microsoft Entra ID, a volte viene definito ID oggetto.

La proprietà principalType specifica se l'entità è un utente, un gruppo o un'entità servizio. Le identità gestite sono una forma di entità servizio.

Suggerimento

È importante impostare la proprietà principalType quando si crea un'assegnazione di ruolo in Bicep. In caso contrario, è possibile che si verifichino errori di distribuzione intermittenti, soprattutto quando si lavora con entità servizio e identità gestite.

L'esempio seguente illustra come creare un'identità gestita assegnata dall'utente e un'assegnazione di ruolo:

param location string = resourceGroup().location
param roleDefinitionResourceId string

var managedIdentityName = 'MyManagedIdentity'

resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: managedIdentityName
  location: location
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, managedIdentity.id, roleDefinitionResourceId)
  properties: {
    roleDefinitionId: roleDefinitionResourceId
    principalId: managedIdentity.properties.principalId
    principalType: 'ServicePrincipal'
  }
}

Comportamento di eliminazione delle risorse

Quando si elimina un utente, un gruppo, un'entità servizio o un'identità gestita dall'ID Microsoft Entra, è consigliabile eliminare eventuali assegnazioni di ruolo. Non vengono eliminati automaticamente.

Tutte le assegnazioni di ruolo che fanno riferimento a un ID entità eliminato non sono valide. Se si tenta di riutilizzare il nome di un'assegnazione di ruolo per un'altra assegnazione di ruolo, la distribuzione avrà esito negativo. Per ovviare a questo comportamento, è necessario rimuovere l'assegnazione di ruolo precedente prima di ricrearla oppure assicurarsi di usare un nome univoco quando si distribuisce una nuova assegnazione di ruolo. Questo modello di avvio rapido illustra come definire un'assegnazione di ruolo in un modulo Bicep e usare un ID entità come valore di inizializzazione per il nome dell'assegnazione di ruolo.

Definizioni di ruolo personalizzate

Le definizioni di ruolo personalizzate consentono di definire un set di autorizzazioni che possono quindi essere assegnate a un'entità usando un'assegnazione di ruolo. Per altre informazioni sulle definizioni dei ruoli, vedere Informazioni sulle definizioni dei ruoli di Azure.

Per creare una definizione di ruolo personalizzata, definire una risorsa di tipo Microsoft.Authorization/roleDefinitions. Per un esempio, vedere l'argomento di avvio rapido Creare un nuovo ruolo tramite una distribuzione a livello di sottoscrizione.

I nomi delle risorse di definizione del ruolo devono essere univoci all'interno del tenant di Microsoft Entra, anche se gli ambiti assegnabili sono più stretti.

Nota

Alcuni servizi gestiscono definizioni di ruolo e assegnazioni personalizzate. Ad esempio, Azure Cosmos DB gestisce le proprie risorse Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments e Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions. Per altre informazioni, vedere la documentazione specifica del servizio.