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

Создание ресурсов Azure RBAC с помощью Bicep

  • Статья

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

Если явно не указать область, 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://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'
  }
}

Субъект

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

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

Совет

При создании назначения роли в Bicep важно настроить свойство principalType. Иначе могут возникнуть ошибки, вызывающие прерывания в развертывании, особенно при работе с субъектами-службами и управляемыми экземплярами.

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

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 рекомендуется удалить все назначения ролей. Они не удаляются автоматически.

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

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

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

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

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

Примечание.

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