Udostępnij za pośrednictwem

Tworzenie zasobów RBAC platformy Azure przy użyciu Bicep

  • Artykuł

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 jednostce (takiej 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 zabezpieczeń i typ podmiotu zabezpieczeń.

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 Omówienie zakresu kontroli dostępu opartej na rolach platformy Azure.

Przypisania ról to zasoby rozszerzenia, co oznacza, że mają zastosowanie do innego zasobu. W poniższym przykładzie pokazano, jak utworzyć konto magazynu i przypisanie roli ograniczone do tego konta magazynu:

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

Jeśli nie określisz jawnie zakresu, Bicep używa pliku targetScope. W poniższym przykładzie nie scope określono żadnej właściwości, 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'
  }
}

Napiwek

Użyj najmniejszego zakresu, który musisz spełnić wymagania.

Jeśli na przykład musisz udzielić tożsamości zarządzanej dostępu do pojedynczego konta magazynu, dobrym rozwiązaniem jest utworzenie przypisania roli w zakresie konta magazynu, a nie w grupie zasobów lub zakresie subskrypcji.

Nazwisko

Nazwa zasobu przypisania roli musi być unikatowym identyfikatorem globalnym (GUID).

Nazwy zasobów przypisania roli muszą być unikatowe w dzierżawie firmy Microsoft Entra, nawet jeśli zakres jest węższy.

Aby wdrożenie Bicep było powtarzalne, ważne jest, aby nazwa była deterministyczna — innymi słowy, używać tej samej nazwy za każdym razem, gdy wdrażasz. Dobrym rozwiązaniem jest utworzenie identyfikatora GUID, który używa razem zakresu, identyfikatora podmiotu zabezpieczeń i identyfikatora roli. Warto użyć guid() funkcji , aby ułatwić tworzenie deterministycznego identyfikatora GUID dla nazw przypisań ról, jak w tym przykładzie:

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

Identyfikator definicji roli

Przypisywana rola może być wbudowaną definicją roli lub niestandardową definicją roli. Aby użyć wbudowanej definicji roli, znajdź odpowiedni identyfikator definicji roli. Na przykład rola Współautor ma identyfikator b24988ac-6180-42a0-ab88-20f7382dd24cdefinicji roli .

Podczas tworzenia zasobu przypisania roli należy określić w pełni kwalifikowany identyfikator zasobu. Wbudowane identyfikatory definicji roli to zasoby w zakresie subskrypcji. Dobrym rozwiązaniem existing jest użycie zasobu w celu odwoływania się do wbudowanej roli i uzyskiwania dostępu do w pełni kwalifikowanego identyfikatora .id zasobu przy użyciu właściwości :

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

Główne

Właściwość musi być ustawiona principalId na identyfikator GUID reprezentujący identyfikator Entra firmy Microsoft dla podmiotu zabezpieczeń. 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. Tożsamości zarządzane są formą jednostki usługi.

Napiwek

Ważne jest, aby ustawić principalType właściwość podczas tworzenia przypisania roli w Bicep. W przeciwnym razie mogą wystąpić sporadyczne błędy wdrażania, szczególnie w przypadku pracy z jednostkami usługi i tożsamościami zarządzanymi.

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 usuwania zasobów

Po usunięciu użytkownika, grupy, jednostki usługi lub tożsamości zarządzanej z identyfikatora Entra firmy Microsoft dobrym rozwiązaniem jest usunięcie wszelkich przypisań ról. Nie są one usuwane automatycznie.

Wszystkie przypisania ról odwołujące się do usuniętego identyfikatora podmiotu zabezpieczeń 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. W tym szablonie szybkiego startu pokazano, jak można zdefiniować przypisanie roli w module Bicep i użyć identyfikatora podmiotu zabezpieczeń jako wartości inicjatora dla nazwy przypisania roli.

Definicje ról niestandardowych

Definicje ról niestandardowych umożliwiają zdefiniowanie zestawu uprawnień, które następnie można przypisać do podmiotu zabezpieczeń przy użyciu przypisania 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. Aby zapoznać się z przykładem, zobacz Szybki start Tworzenie nowej roli za pośrednictwem przewodnika Szybki start dotyczącego wdrażania na poziomie subskrypcji.

Nazwy zasobów definicji roli muszą być unikatowe w dzierżawie firmy Microsoft Entra, nawet jeśli zakresy, które można przypisać, są węższe.

Uwaga

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