Udzielanie tożsamości obciążenia dostępu do platformy Azure

  • 6 min

Sama tożsamość obciążenia nie może wykonywać żadnych czynności w środowisku platformy Azure, podobnie jak w jaki sposób użytkownik nie może pracować z zasobami platformy Azure, chyba że ma uprawnienia do tego. W tej lekcji dowiesz się, jak autoryzować tożsamości obciążeń do wdrażania i konfigurowania zasobów platformy Azure przy jednoczesnym unikaniu udzielania niepotrzebnych uprawnień.

Autoryzacja tożsamości obciążenia

Do tej pory skupiliśmy się na tożsamościach obciążeń i sposobach ich użycia w celu potwierdzenia tożsamości przepływu pracy wdrażania do identyfikatora Entra firmy Microsoft. Chodzi o uwierzytelnianie.

Po uwierzytelnieniu tożsamości obciążenia przez identyfikator entra firmy Microsoft następnym pytaniem staje się: co może zrobić ta tożsamość obciążenia? Jest to koncepcja autoryzacji. Jest to odpowiedzialność systemu kontroli dostępu opartej na rolach (RBAC) platformy Azure, czasami nazywanego zarządzaniem tożsamościami i dostępem (IAM). Za pomocą kontroli dostępu opartej na rolach platformy Azure można udzielić tożsamości obciążenia dostępu do określonej grupy zasobów, subskrypcji lub grupy zarządzania.

Uwaga

Wszystko, co robisz, korzysta z systemu kontroli dostępu opartej na rolach platformy Azure w celu udzielenia dostępu do tworzenia zasobów platformy Azure, takich jak konta magazynu, plan usługi aplikacja systemu Azure i sieci wirtualne. Identyfikator Entra firmy Microsoft ma również swój własny system ról, który jest czasami nazywany rolami katalogu. Te role służą do udzielania uprawnień tożsamości obciążeń do zarządzania identyfikatorem Entra firmy Microsoft. W tym module nie omówiono szczegółowo tego tematu, ale należy pamiętać, że termin rola jest używana w obu sytuacjach w niektórych dokumentach.

Wybieranie odpowiedniego przypisania roli dla przepływu pracy

Przypisanie roli ma trzy kluczowe części: do kogo przypisano rolę ( przypisaną), co może zrobić ( rola) oraz do którego zasobu lub zasobów ma zastosowanie przypisanie roli ( zakres).

Cesjonariusza

Podczas pracy z tożsamością obciążenia przypisujesz dla niej role. Aby przypisać rolę, musisz najpierw utworzyć jednostkę usługi, która umożliwia przyznawanie ról aplikacji na platformie Azure. Po utworzeniu jednostki usługi możesz kontynuować pracę z identyfikatorem aplikacji rejestracji aplikacji.

Aby utworzyć jednostkę usługi, użyj az ad sp create polecenia i określ identyfikator aplikacji rejestracji aplikacji:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Aby utworzyć jednostkę usługi, użyj New-AzADServicePrincipal polecenia cmdlet i określ identyfikator aplikacji rejestracji aplikacji:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Rola

Może to być nieco więcej pracy, aby dowiedzieć się, która rola ma zostać przypisana. Na platformie Azure istnieje kilka typowych ról:

  • Czytelnik: umożliwia przypisywaniu odczytywanie informacji o zasobach, ale nie modyfikowanie ich ani usuwanie.
  • Współautor: umożliwia przypisywaniu tworzenie zasobów oraz odczytywanie i modyfikowanie istniejących zasobów. Jednak współautorzy nie mogą udzielać innym podmiotom zabezpieczeń dostępu do zasobów.
  • Właściciel: umożliwia pełną kontrolę nad zasobami, w tym udzielanie dostępu innym podmiotom zabezpieczeń.

Uwaga

Przyznaj tożsamościom obciążeń tylko minimalne uprawnienia, które muszą wykonywać swoje zadania. W większości przypadków rola właściciel jest zbyt permisywna dla przepływu pracy wdrażania.

Istnieje również wiele określonych ról, które zapewniają dostęp do podzbioru funkcji. Możesz nawet utworzyć własną definicję roli niestandardowej, aby określić dokładną listę uprawnień, które chcesz przypisać.

Uwaga

Definicje ról niestandardowych mogą być zaawansowanym sposobem udzielania uprawnień dla zasobów platformy Azure, ale mogą być trudne do pracy. Nie zawsze łatwo jest określić, które uprawnienia należy dodać do niestandardowej definicji roli. Definicje ról mogą być przypadkowo zbyt restrykcyjne lub zbyt permissywne.

Jeśli nie masz pewności, co zrobić, najlepiej użyć jednej z wbudowanych definicji ról. Definicje ról niestandardowych wykraczają poza zakres tego modułu.

Scope

Musisz określić, jak szeroko przypisujesz rolę. Ta decyzja ma wpływ na liczbę zasobów, które tożsamość obciążenia może modyfikować. Typowe zakresy obejmują:

  • Pojedynczy zasób: możesz udzielić dostępu do określonego zasobu. Zazwyczaj przepływy pracy wdrażania nie korzystają z tego zakresu, ponieważ przepływ pracy tworzy zasoby, które jeszcze nie istnieją lub ponownie konfiguruje wiele zasobów.
  • Grupa zasobów: możesz udzielić dostępu do wszystkich zasobów w grupie zasobów. Współautorzy i właściciele mogą również tworzyć zasoby w grupie. Jest to dobra opcja dla wielu przepływów pracy wdrażania.
  • Subskrypcja: możesz udzielić dostępu do wszystkich zasobów w ramach subskrypcji. Jeśli masz wiele aplikacji, obciążeń lub środowisk w jednej subskrypcji, możesz udzielić uprawnień do zakresu subskrypcji. Zwykle jest to zbyt uciążliwe dla przepływu pracy wdrażania. Zamiast tego należy rozważyć określenie zakresu przypisań ról do grup zasobów, chyba że przepływ pracy wdrażania musi tworzyć grupy zasobów.

Pamiętaj, że przypisania ról są dziedziczone. Jeśli przypiszesz rolę w subskrypcji, osoba przypisana ma dostęp do każdej grupy zasobów i zasobu w ramach tej subskrypcji.

Wybieranie odpowiedniego przypisania roli

Teraz, gdy rozumiesz składniki przypisania roli, możesz zdecydować o odpowiednich wartościach dla Twoich scenariuszy. Poniżej przedstawiono kilka ogólnych wytycznych, które należy wziąć pod uwagę:

  • Użyj najmniej permissywnej roli, którą możesz. Jeśli przepływ pracy będzie wdrażać tylko podstawowe pliki Bicep i nie będzie zarządzać przypisaniami ról, nie używaj roli Właściciel.

  • Użyj najwęższego zakresu, który możesz. Większość przepływów pracy musi wdrażać zasoby tylko w grupie zasobów, więc nie powinny mieć przypisanych ról w zakresie subskrypcji.

  • W przypadku wielu przepływów pracy dobrą opcją domyślną dla przypisania roli jest rola Współautor w zakresie grupy zasobów.

  • Rozważ wszystko, co robi twój przepływ pracy i wszystko, co może zrobić w przyszłości. Możesz na przykład rozważyć utworzenie niestandardowej definicji roli dla przepływu pracy wdrożenia witryny internetowej i przyznanie uprawnień tylko usłudze App Service i aplikacji Szczegółowe informacje. W przyszłym miesiącu może być konieczne dodanie konta usługi Azure Cosmos DB do pliku Bicep, ale rola niestandardowa zablokuje tworzenie zasobów usługi Azure Cosmos DB.

    Zamiast tego często lepiej używać wbudowanej roli lub kombinacji wbudowanych ról, aby uniknąć konieczności wielokrotnego zmieniania definicji ról. Rozważ użycie usługi Azure Policy, aby wymusić wymagania dotyczące ładu dla dozwolonych usług, jednostek SKU i lokalizacji.

  • Przetestuj przepływ pracy, aby sprawdzić, czy przypisanie roli działa.

Mieszanie i dopasowywanie przypisań ról

Można utworzyć wiele przypisań ról, które zapewniają różne uprawnienia w różnych zakresach. Możesz na przykład przypisać tożsamość obciążenia rolę Czytelnik z zakresem całej subskrypcji. Możesz oddzielnie przypisać tę samą tożsamość obciążenia rolę Współautor dla określonej grupy zasobów. Gdy tożsamość obciążenia próbuje pracować z grupą zasobów, stosowana jest większa wartość przypisania.

Praca z wieloma środowiskami

Prawdopodobnie pracujesz z wieloma środowiskami, takimi jak środowiska programistyczne, testowe i produkcyjne dla aplikacji. Zasoby dla każdego środowiska powinny być wdrażane w różnych grupach zasobów lub subskrypcjach.

Należy utworzyć oddzielne tożsamości obciążeń dla każdego środowiska. Przyznaj każdej tożsamości obciążenia minimalny zestaw uprawnień, których potrzebuje dla swoich wdrożeń. Należy zachować szczególną ostrożność, aby uniknąć mieszania uprawnień dla wdrożeń produkcyjnych z uprawnieniami do wdrożeń w środowiskach nieprodukcyjnych.

Tworzenie przypisania roli dla tożsamości obciążenia

Aby utworzyć przypisanie roli dla tożsamości obciążenia, użyj az role assignment create polecenia . Musisz określić przypisanie, rolę i zakres:

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Przyjrzyjmy się każdemu argumentowi:

  • --assignee określa tożsamość obciążenia. Można to określić na kilka sposobów, ale użycie identyfikatora aplikacji jest dobrym rozwiązaniem, ponieważ pozwala uniknąć niejednoznaczności.
  • --role określa rolę. Jeśli używasz wbudowanej roli, możesz określić ją według nazwy. Jeśli używasz niestandardowej definicji roli, określ pełny identyfikator definicji roli.
  • --scope określa zakres. Zazwyczaj jest to identyfikator zasobu dla pojedynczego zasobu, grupy zasobów lub subskrypcji.
  • --description to czytelny dla człowieka opis przypisania roli.

Aby utworzyć przypisanie roli dla tożsamości obciążenia, użyj New-AzRoleAssignment polecenia cmdlet . Określ przypisanie, rolę i zakres:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Przyjrzyjmy się każdemu argumentowi:

  • -ApplicationId określa identyfikator rejestracji aplikacji tożsamości obciążenia.
  • -RoleDefinitionName określa nazwę wbudowanej roli. Jeśli używasz niestandardowej definicji roli, określ identyfikator pełnej definicji roli przy użyciu argumentu -RoleDefinitionId .
  • -Scope określa zakres. Zazwyczaj jest to identyfikator zasobu dla pojedynczego zasobu, grupy zasobów lub subskrypcji.
  • -Description to czytelny dla człowieka opis przypisania roli.

Napiwek

Dobrym rozwiązaniem jest przedstawienie uzasadnienia przypisań ról przez określenie opisu. Opis ułatwia każdemu, kto później przegląda przypisania ról, aby zrozumieć ich przeznaczenie oraz zrozumieć, w jaki sposób decydujesz się na przypisanie, rolę i zakres.

Uwaga

Aktywowanie przypisań ról może potrwać kilka minut.

Udzielanie dostępu przy użyciu Bicep

Przypisania ról to zasoby platformy Azure. Oznacza to, że można utworzyć przypisanie roli przy użyciu Bicep. Można to zrobić, jeśli zainicjujesz grupy zasobów przy użyciu Bicep, a następnie wdróż zasoby w grupie zasobów przy użyciu tożsamości obciążenia. Oto przykładowa definicja Bicep dla poprzedniego przypisania roli:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Przyjrzyjmy się każdemu argumentowi:

  • name jest unikatowym identyfikatorem globalnym (GUID) dla przypisania roli. Dobrym rozwiązaniem jest użycie guid() funkcji w aplikacji Bicep do utworzenia identyfikatora GUID. Aby upewnić się, że tworzysz nazwę unikatową dla każdego przypisania roli, użyj identyfikatora podmiotu zabezpieczeń, identyfikatora definicji roli i zakresu jako argumentów inicjatora funkcji.

  • principalType należy ustawić wartość ServicePrincipal.

  • roleDefinitionId to w pełni kwalifikowany identyfikator zasobu dla definicji roli, którą przypisujesz. W większości przypadków pracujesz z rolami wbudowanymi, aby znaleźć identyfikator definicji roli w dokumentacji ról wbudowanych platformy Azure.

    Na przykład rola Współautor ma identyfikator b24988ac-6180-42a0-ab88-20f7382dd24cdefinicji roli . Po określeniu go w pliku Bicep należy użyć w pełni kwalifikowanego identyfikatora zasobu, takiego jak /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.

  • principalId jest identyfikatorem obiektu jednostki usługi. Upewnij się, że nie używasz identyfikatora aplikacji ani identyfikatora obiektu rejestracji aplikacji.

  • description to czytelny dla człowieka opis przypisania roli.