Partager via

Créer des ressources RBAC Azure en Bicep

  • Article

Azure dispose d’un système puissant de contrôle d’accès en fonction du rôle (RBAC). Pour plus d’informations sur Azure RBAC, consultez Présentation du contrôle d’accès en fonction du rôle Azure (Azure RBAC) En utilisant Bicep, vous pouvez définir programmatiquement vos attributions de rôles RBAC et vos définitions de rôles.

Affectations de rôles

Les attributions de rôles permettent d’autoriser l’accès à une ressource Azure spécifique à un principal (comme un utilisateur, un groupe ou un principal de service).

Pour définir une attribution de rôle, créez une ressource de type Microsoft.Authorization/roleAssignments. Une définition de rôle possède plusieurs propriétés, notamment une étendue, un nom, un ID de définition de rôle, un ID de principal et un type de principal.

Étendue

Les attributions de rôles s’appliquent à une étendue spécifique, qui définit la ressource ou l’ensemble de ressources auxquelles vous accordez l’accès. Pour plus d’informations, consultez Comprendre l’étendue du contrôle d’accès en fonction du rôle (RBAC).

Les attributions de rôle sont des ressources d’extension,ce qui signifie qu’elles s’appliquent à une autre ressource. L’exemple suivant montre comment créer un compte de stockage et une attribution de rôle étendue à ce compte de stockage :

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@2023-04-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'
  }
}

Si vous ne spécifiez pas explicitement l’étendue, Bicep utilise la propriété targetScope du fichier. Dans l’exemple suivant, aucune propriété scope n’est spécifiée, l’attribution de rôle s’applique donc à l’abonnement :

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'
  }
}

Conseil

Utilisez la plus petite étendue dont vous avez besoin pour répondre à vos exigences.

Par exemple, si vous devez accorder à une identité managée l’accès à un seul compte de stockage, une bonne pratique de sécurité consiste à créer l’attribution de rôle dans l’étendue du compte de stockage, et non dans l’étendue du groupe de ressources ou de l’abonnement.

Nom

Le nom de ressource d’une attribution de rôle doit être un identificateur unique au niveau mondial (GUID).

Les noms des ressources d’attribution de rôle doivent être uniques dans le locataire Microsoft Entra, même si l’étendue est plus restreinte.

Pour que votre déploiement Bicep soit reproductible, il est important que le nom soit déterministe. En d’autres termes, vous devez utiliser le même nom à chaque fois que vous effectuez le déploiement. Une bonne pratique consiste à créer un GUID qui utilise l’étendue, l’ID du principal et l’ID du rôle ensemble. Il est judicieux d’utiliser la fonction guid() pour vous aider à créer un GUID déterministe pour vos noms d’attributions de rôle, comme dans cet exemple :

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

ID de définition de rôle

Le rôle que vous attribuez peut être une définition de rôle intégrée ou une définition de rôle personnalisée. Pour utiliser une définition de rôle intégrée, recherchez l’ID de définition de rôle approprié. Par exemple, le rôle Contributeur a l’ID de définition de rôle b24988ac-6180-42a0-ab88-20f7382dd24c.

Lorsque vous créez la ressource d’attribution de rôle, vous devez spécifier un ID de ressource complet. Les ID de définition de rôle intégrée sont des ressources étendues à l’abonnement. Il est recommandé d’utiliser une ressource existing pour faire référence au rôle intégré et d’accéder à son ID de ressource complet en utilisant la propriété .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@2022-04-01' 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'
  }
}

Principal

La propriété principalId doit être définie sur un GUID qui représente l’identificateur Microsoft Entra du principal. Dans Microsoft Entra ID, il s’agit parfois de l’ID de l’objet.

La propriété principalType indique si le principal est un utilisateur, un groupe ou un principal de service. Les identités managées sont une forme de principal de service.

Conseil

Il est important de définir la propriété principalType lorsque vous créez une attribution de rôle en Bicep. Sinon, vous risquez d’obtenir des erreurs de déploiement intermittentes, en particulier lorsque vous travaillez avec des principaux de service et des identités managées.

L’exemple suivant montre comment créer une identité managée affectée par l’utilisateur et une attribution de rôle :

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'
  }
}

Comportement de suppression des ressources

Quand vous supprimez un utilisateur, un groupe, un principal de service ou une identité managée de Microsoft Entra ID, il est recommandé de supprimer toutes les attributions de rôles. Elles ne sont pas supprimées automatiquement.

Toutes les attributions de rôles qui font référence à un ID de principal supprimé ne sont plus valides. Si vous essayez de réutiliser le nom d’une attribution de rôle pour une autre attribution de rôle, le déploiement échoue. Pour contourner ce comportement, vous devez soit supprimer l’ancienne attribution de rôle avant de la recréer, soit vérifier que vous utilisez un nom unique quand vous déployez une nouvelle attribution de rôle. Ce modèle de démarrage rapide montre comment définir une attribution de rôle dans un module Bicep, et comment utiliser un ID de principal en tant que valeur de départ pour le nom d’attribution de rôle.

Définitions de rôles personnalisées

Les définitions de rôle personnalisées vous permettent de définir un ensemble d’autorisations qui peuvent ensuite être affectées à un principal à l’aide d’une attribution de rôle. Pour plus d’informations sur les définitions de rôle, consultez Comprendre les définitions de rôle Azure.

Pour créer une définition de rôle personnalisée, définissez une ressource de type Microsoft.Authorization/roleDefinitions. Pour obtenir un exemple, consultez le démarrage rapide Créer une nouvelle définition de rôle via un déploiement au niveau de l’abonnement.

Les noms des ressources d’attribution de rôle doivent être uniques au sein du locataire Microsoft Entra, même si les étendues assignables sont plus restreintes.

Remarque

Certains services gèrent leurs propres définitions et attributions de rôle. Par exemple, Azure Cosmos DB gère ses propres ressources Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments et Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions. Pour plus d’informations, consultez la documentation du service concerné.