Поделиться через

Используйте Bicep для создания ресурсов ролевого управления доступом в Azure (Azure RBAC)

  • Статья

Azure имеет мощную систему управления доступом на основе ролей (RBAC). Дополнительные сведения об Azure RBAC см. в статье "Что такое управление доступом на основе ролей Azure" (Azure RBAC)? С помощью Bicep можно программно определить назначения ролей RBAC и определения ролей.

Назначения ролей

Назначения ролей позволяют предоставить субъекту, например пользователю, группе или субъекту-службе доступ к конкретному ресурсу Azure.

Чтобы определить назначение ролей, создайте ресурс с типом Microsoft.Authorization/roleAssignments. Определение роли содержит несколько свойств, включая область, имя, идентификатор определения роли, идентификатор субъекта и тип субъекта.

Область действия

Назначения ролей применяются в определенной области, которая определяет ресурс или набор ресурсов, к которым вы предоставляете доступ. Дополнительные сведения см. в Описание области действия для Azure RBAC.

Назначения ролей — это ресурсы расширения, то есть они применяются к другому ресурсу. В следующем примере показано, как создать учетную запись хранения и назначение ролей, ограниченное этой учетной записью хранения:

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

Если вы явно не укажете область, Bicep будет использовать параметр файла targetScope. В следующем примере свойство scope не указано, поэтому назначение роли распространяется на подписку.

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

Подсказка

Используйте наименьшую область, чтобы удовлетворять вашим требованиям.

Например, если необходимо предоставить доступ управляемой идентичности к одной учетной записи хранения, рекомендуется назначить роль в рамках учетной записи хранения, а не на уровне группы ресурсов или подписки.

Имя

Имя ресурса назначенной роли должно быть глобально уникальным идентификатором (GUID).

Названия ресурсов назначения ролей должны быть уникальными в клиенте Microsoft Entra, даже если область использования более узкая.

Чтобы развертывание Bicep было воспроизводимым, важно, чтобы имя было детерминированным. Т. е. используйте одно и то же имя при каждом развертывании. Целесообразно создать GUID, используя область, идентификатор субъекта и идентификатор роли вместе. Рекомендуется использовать функцию guid(), чтобы создать детерминированный GUID для имен назначений ролей, как в этом примере:

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

Идентификатор определения роли

Назначенная роль может быть встроенным определением ролей или пользовательским определением роли. Чтобы использовать встроенное определение роли, найдите соответствующий идентификатор определения роли. Например, роль участника имеет идентификатор роли b24988ac-6180-42a0-ab88-20f7382dd24c.

При создании ресурса назначения ролей необходимо указать полный идентификатор ресурса. Встроенные идентификаторы определений ролей — это ресурсы, ограниченные подпиской. Рекомендуется использовать existing для ссылки на встроенную роль и использовать .id для доступа к его полностью квалифицированному идентификатору ресурса.

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

Директор

Свойство principalId должно быть установлено в значение GUID, который представляет идентификатор Microsoft Entra для основного объекта. В идентификаторе Microsoft Entra это иногда называется идентификатором объекта.

Свойство principalType указывает, является ли субъект пользователем, группой или субъектом-службой. Управляемые удостоверения — это форма служебного принципала.

Подсказка

Важно установить свойство principalType, когда вы создаёте назначение роли в Bicep. В противном случае могут возникнуть интервалные ошибки развертывания, особенно при работе со служебными принципалами и управляемыми идентификаторами.

В следующем примере показано, как создать управляемое удостоверение, назначаемое пользователем, и назначение роли:

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

Поведение при удалении ресурсов

При удалении пользователя, группы, служебного принципала или управляемого удостоверения из Microsoft Entra ID рекомендуется удалить все назначения ролей. Они не удаляются автоматически.

Все назначения ролей, которые ссылаются на удаленный идентификатор участника, становятся недействительными. Если попытаться использовать имя назначения роли снова для другого назначения, развертывание не удастся. Чтобы обойти это поведение, необходимо либо удалить старое назначение ролей, прежде чем повторно создать его, либо убедиться, что при развертывании нового назначения роли используется уникальное имя. В этом шаблоне краткого руководства показано, как определить назначение ролей в модуле Bicep и использовать идентификатор субъекта в качестве начального значения для имени назначения роли.

Пользовательские определения ролей

Пользовательские определения ролей позволяют задать набор разрешений, которые затем можно назначить участнику с помощью назначения роли. Дополнительные сведения об определениях ролей см. в статье "Общие сведения об определениях ролей Azure".

Чтобы создать определение пользовательской роли, определите ресурс типа Microsoft.Authorization/roleDefinitions. См. пример в кратком руководстве по созданию нового определения роли через развертывание на уровне подписки.

Имена ресурсов определения ролей должны быть уникальными в тенанте Microsoft Entra, даже если области назначения являются более узкими.

Примечание.

Некоторые службы управляют собственными определениями ролей и назначениями. Например, Azure Cosmos DB поддерживает такие собственные ресурсы, как Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments и Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions. Дополнительные сведения см. в документации конкретной службы.