Compartir por

Creación recursos de RBAC de Azure con Bicep

  • Artigo

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

Asignaciones de roles

Las asignaciones de roles permiten conceder a una entidad de seguridad (como un usuario, un grupo o una entidad de servicio) acceso a un recurso de Azure concreto.

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 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-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 el ámbito no especifica de forma explícita, Bicep usa el valor targetScope del archivo. En el ejemplo siguiente, no se especifica ninguna propiedad scope, por lo que el ámbito de la asignación de roles es 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 de una asignación de roles debe ser un identificador único global (GUID).

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. Un procedimiento recomendado consiste en crear un GUID que use conjuntamente el ámbito, el id. principal y el id. 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 rol integrada o una definición de rol personalizada. Para usar una definición de rol integrada, busque el id. de definición de rol adecuado. Por ejemplo, el rol Colaborador tiene una definición de rol de b24988ac-6180-42a0-ab88-20f7382dd24c.

Al crear el recurso de asignación de roles, debe especificar un id. de recurso completo. Los identificadores de definición de roles integrados son recursos con ámbito de suscripción. Un procedimiento recomendado consiste en usar un recurso existing para hacer referencia al rol integrado y acceder a su id. de recurso completo mediante la propiedad .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 propiedad principalId se debe establecer en un GUID que represente el identificador de Microsoft Entra de la entidad de seguridad. En Microsoft Entra ID, en ocasiones este parámetro se denomina identificador 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 propiedad principalType 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 también cualquier asignación 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 la definición de roles, consulte Descripción de definiciones de roles de Azure.

Para crear una definición de rol personalizada, defina un recurso de tipo Microsoft.Authorization/roleDefinitions. Vea el inicio rápido Creación de una definición de rol mediante una implementación de nivel de suscripción para obtener un ejemplo.

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

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, vea la documentación del servicio específico.