Compartir a través de

Utilice Bicep para crear recursos de control de acceso basado en roles de Azure (Azure RBAC)

Azure tiene un potente sistema de control de acceso basado en rol (RBAC). Para más información sobre RBAC de Azure, consulte ¿Qué es el control de acceso basado en rol de Azure (RBAC de Azure)? Mediante Bicep, puede definir mediante programación las asignaciones de roles de RBAC y las definiciones de roles.

Asignaciones de roles

Las asignaciones de roles permiten conceder a un principal, como un usuario, un grupo o una entidad de servicio, acceso a un recurso específico de Azure.

Para definir una asignación de roles, cree un recurso con el tipo Microsoft.Authorization/roleAssignments. Una definición de rol tiene varias propiedades, incluido un ámbito, un nombre, un id. de definición de rol, un id. de entidad de seguridad y un tipo de entidad de seguridad.

Ámbito

Las asignaciones de roles se aplican en un ámbito específico, que define el recurso o el conjunto de recursos a los que se concede acceso. Para obtener más información, vea Descripción del ámbito de Azure RBAC.

Las asignaciones de roles son recursos de extensión, lo que significa que se aplican a otro recurso. En el ejemplo siguiente se muestra cómo crear una cuenta de almacenamiento y una asignación de roles en el ámbito de esa cuenta de almacenamiento:

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-05-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 el ámbito no especifica de forma explícita, Bicep usa el valor targetScope del archivo. En el ejemplo siguiente, no se especifica ninguna scope propiedad, por lo que la asignación de roles se limita a la suscripción:

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

Sugerencia

Use el ámbito más pequeño que necesita para cumplir sus requisitos.

Por ejemplo, si necesita conceder a una identidad administrada acceso a una única cuenta de almacenamiento, un procedimiento recomendado de seguridad consiste en crear la asignación de roles en el ámbito de la cuenta de almacenamiento, no en el del grupo de recursos ni el de la suscripción.

Nombre

El nombre del recurso en una asignación de roles debe ser un identificador único global (GUID, por sus siglas en inglés).

Los nombres de recursos de asignación de roles deben ser únicos dentro del inquilino de Microsoft Entra, incluso si el ámbito es más reducido.

Para que la implementación de Bicep se pueda repetir, es importante que el nombre sea determinista, es decir, que se use el mismo nombre cada vez que se implementa. Es una buena práctica crear un GUID que use de manera conjunta el ámbito, el identificador principal y el identificador de rol. Se aconseja usar la función guid() para ayudarle a crear un GUID determinista para los nombres de asignación de roles, como en este ejemplo:

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

Id. de definición de roles

El rol que asigne puede ser una definición de roles integrada o una definición de rol personalizada. Para usar una definición de roles integrada, busque el identificador de definición de rol adecuado. Por ejemplo, el rol Colaborador tiene un identificador de definición de rol de b24988ac-6180-42a0-ab88-20f7382dd24c.

Cuando crea el recurso de asignación de roles, debe especificar un ID de recurso completamente calificado. Los identificadores de definición de roles integrados son recursos con ámbito de suscripción. Se recomienda usar un existing recurso para hacer referencia al rol integrado y usar la .id propiedad para acceder a su identificador de recurso completo:

param principalId string

@description('This is the built-in Contributor role. See https://learn.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 propiedad principalId se debe establecer en un GUID que represente el identificador de Microsoft Entra de la entidad de seguridad. En Microsoft Entra ID, esto a veces se denomina el ID de objeto.

La propiedad principalType especifica si la entidad de seguridad es un usuario, un grupo o una entidad de servicio. Las identidades administradas son una forma de entidad de servicio.

Sugerencia

Es importante establecer la principalType propiedad al crear una asignación de roles en Bicep. De lo contrario, es posible que reciba errores de implementación intermitentes, especialmente cuando trabaja con entidades de servicio e identidades administradas.

En el ejemplo siguiente se muestra cómo crear una identidad administrada asignada por el usuario y una asignación de roles:

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

Comportamiento de la eliminación de recursos

Al eliminar un usuario, un grupo, una entidad de servicio o una identidad administrada de Microsoft Entra ID, se recomienda eliminar las asignaciones de roles. ya que no se eliminan automáticamente.

Las asignaciones de roles que hacen referencia a un identificador de entidad de seguridad eliminado no son válidas. Si intenta reutilizar el nombre de una asignación de roles para otra asignación, se producirá un error en la implementación. Para solucionar este comportamiento, debe eliminar la asignación de roles anterior antes de volver a crearla o asegurarse de que usa un nombre único al implementar una nueva asignación de roles. En esta plantilla de inicio rápido se indica cómo definir una asignación de roles en un módulo de Bicep y usar un identificador de entidad de seguridad como valor de inicialización para el nombre de la asignación de roles.

Definiciones de roles personalizados

Las definiciones de roles personalizados permiten definir un conjunto de permisos que luego se pueden asignar a una entidad de seguridad mediante una asignación de roles. Para más información sobre las definiciones de roles, consulte Descripción de las definiciones de roles de Azure.

Para crear una definición de rol personalizada, defina un recurso de tipo Microsoft.Authorization/roleDefinitions. Consulte la guía de inicio rápido Crear una nueva definición de rol mediante una implementación a nivel de suscripción para obtener un ejemplo.

Los nombres de los recursos de definición de roles deben ser únicos dentro del tenant de Microsoft Entra, incluso si los ámbitos asignables son más limitados.

Nota:

Algunos servicios administran sus propias definiciones y asignaciones de roles. Por ejemplo, Azure Cosmos DB mantiene sus propios recursos Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments y Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions. Para más información, consulte la documentación del servicio específico.