Udostępnij za pośrednictwem


Tworzenie zasobów kontroli dostępu na podstawie ról (RBAC) platformy Azure przy użyciu Bicep

Platforma Azure ma zaawansowany system kontroli dostępu opartej na rolach (RBAC). Aby uzyskać więcej informacji na temat kontroli dostępu opartej na rolach platformy Azure, zobacz Co to jest kontrola dostępu oparta na rolach platformy Azure (Azure RBAC)? Za pomocą Bicep można programowo definiować przypisania ról i definicji ról RBAC.

Przypisania ról

Przypisania ról umożliwiają przyznanie podmiotowi, takiemu jak użytkownik, grupa lub jednostka usługi, dostępu do określonego zasobu platformy Azure.

Aby zdefiniować przypisanie roli, utwórz zasób o typie Microsoft.Authorization/roleAssignments. Definicja roli ma wiele właściwości, w tym zakres, nazwę, identyfikator definicji roli, identyfikator podmiotu głównego i typ podmiotu głównego.

Zakres

Przypisania ról mają zastosowanie w określonym zakresie, który definiuje zasób lub zestaw zasobów, do których udzielasz dostępu. Aby uzyskać więcej informacji, zobacz Zrozumienie zakresu dla Azure RBAC.

Przypisania ról są zasobami rozszerzenia, co oznacza, że mają zastosowanie do innego zasobu. The following example shows how to create a storage account and a role assignment scoped to that storage account:

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

Jeśli nie określisz jawnie zakresu, Bicep używa pliku targetScope. W poniższym przykładzie nie określono właściwości scope, więc przypisanie roli jest ograniczone do subskrypcji:

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

Tip

Użyj najmniejszego zakresu, którego potrzebujesz, aby spełnić swoje wymagania.

For example, if you need to grant a managed identity access to a single storage account, it's good security practice to create the role assignment at the scope of the storage account and not at the resource group or subscription scope.

Nazwa

Nazwa zasobu przypisanego do roli musi być globalnie unikalnym identyfikatorem (GUID).

Role assignment resource names must be unique within the Microsoft Entra tenant, even if the scope is narrower.

Aby wdrożenie Bicep było powtarzalne, ważne jest, aby nazwa była deterministyczna, to znaczy używać tej samej nazwy za każdym razem, gdy dokonujesz wdrożenia. It's a good practice to create a GUID that uses the scope, principal ID, and role ID together. It's a good idea to use the guid() function to help you to create a deterministic GUID for your role assignment names, like in this example:

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

Role definition ID

Przypisywana rola może być wbudowaną definicją roli lub niestandardową definicją roli. Aby użyć wbudowanej definicji roli, znajdź odpowiedni identyfikator definicji roli. For example, the Contributor role has a role definition ID of b24988ac-6180-42a0-ab88-20f7382dd24c.

Podczas tworzenia zasobu przypisania roli należy określić w pełni kwalifikowany identyfikator zasobu. Wbudowane identyfikatory definicji ról są zasobami przypisanymi do subskrypcji. Zaleca się użycie zasobu existing do odwoływania się do wbudowanej roli oraz korzystanie z właściwości .id w celu uzyskania dostępu do w pełni kwalifikowanego identyfikatora zasobu.

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

Dyrektor

The principalId property must be set to a GUID that represents the Microsoft Entra identifier for the principal. W identyfikatorze Entra firmy Microsoft jest to czasami określane jako identyfikator obiektu.

Właściwość principalType określa, czy jednostka jest użytkownikiem, grupą, czy jednostką usługi. Zarządzane tożsamości to forma podmiotu usługi.

Tip

Ważne jest, aby ustawić właściwość principalType podczas tworzenia przypisania roli w Bicep. Otherwise, you might get intermittent deployment errors, especially when you work with service principals and managed identities.

W poniższym przykładzie pokazano, jak utworzyć tożsamość zarządzaną przypisaną przez użytkownika i przypisanie roli:

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

Zachowanie podczas usuwania zasobów

Podczas usuwania użytkownika, grupy, jednostki usługi lub tożsamości zarządzanej z Microsoft Entra ID, zaleca się usunięcie wszelkich przypisań ról. Nie są one usuwane automatycznie.

Wszystkie przypisania ról odwołujące się do usuniętego identyfikatora podmiotu stają się nieprawidłowe. Jeśli spróbujesz ponownie użyć nazwy przypisania roli dla innego przypisania roli, wdrożenie zakończy się niepowodzeniem. Aby obejść to zachowanie, należy usunąć stare przypisanie roli przed jego ponownym utworzeniem lub upewnić się, że używasz unikatowej nazwy podczas wdrażania nowego przypisania roli. This quickstart template illustrates how you can define a role assignment in a Bicep module and use a principal ID as a seed value for the role assignment name.

Definicje ról niestandardowych

Definicje ról niestandardowych umożliwiają zdefiniowanie zestawu uprawnień, które następnie można przypisać do głównego podmiotu poprzez przypisanie roli. Aby uzyskać więcej informacji na temat definicji ról, zobacz Omówienie definicji ról platformy Azure.

Aby utworzyć niestandardową definicję roli, zdefiniuj zasób typu Microsoft.Authorization/roleDefinitions. See the Create a new role def via a subscription-level deployment quickstart for an example.

Role definition resource names must be unique within the Microsoft Entra tenant, even if the assignable scopes are more narrow.

Uwaga

Niektóre usługi zarządzają własnymi definicjami ról i przypisaniami. Na przykład Azure Cosmos DB utrzymuje własne zasoby Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments i Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions. Aby uzyskać więcej informacji, zobacz dokumentację określonej usługi.