Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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.
Recursos relacionados
- Documentación de recursos
- Recursos de extensión
- Ámbitos
- Plantillas de inicio rápido
- Creación de una nueva definición de roles a través de una implementación de nivel de suscripción
- Asignar un rol en el ámbito de la suscripción
- Asignación de un rol en el ámbito del inquilino
- Crear un grupo de recursos, aplicar un bloqueo y RBAC
- Crear almacén de claves, identidad administrada y asignación de roles
- Entradas de blog de la comunidad
- Creación de asignaciones de roles para distintos ámbitos con Bicep, de Barbara Forbes