Udzielanie jednostce usługi dostępu do platformy Azure

  • 6 min

Sama jednostka usługi nie może wykonywać żadnych czynności w środowisku platformy Azure. Podobnie jak w przypadku, gdy użytkownik nie może pracować z zasobami platformy Azure, chyba że jest autoryzowany do tego celu. W tej lekcji dowiesz się, jak autoryzować jednostki usługi do wdrażania i konfigurowania zasobów platformy Azure, unikając jednocześnie udzielania niepotrzebnych uprawnień.

Uwaga

Polecenia w tej lekcji są wyświetlane w celu zilustrowania pojęć. Nie uruchamiaj jeszcze poleceń. Będziesz ćwiczyć to, czego nauczysz się tutaj wkrótce.

Autoryzacja jednostki usługi

Do tej pory skupiliśmy się na tym, czym są jednostki usługi i jak mogą być używane do udowodnienia tożsamości potoku do identyfikatora Entra firmy Microsoft. Chodzi o uwierzytelnianie.

Po uwierzytelnieniu jednostki usługi identyfikator entra firmy Microsoft następnym pytaniem staje się: co może zrobić ta jednostka usługi? 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ć jednostce usługi dostępu do określonej grupy zasobów, subskrypcji lub grupy zarządzania.

Uwaga

Wszystko, co robisz, korzysta z systemu RBAC platformy Azure, aby udzielić dostępu do tworzenia zasobów platformy Azure i zarządzania nimi, takich jak konta magazynu, plan usługi App Service 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ń jednostkom usługi do zarządzania identyfikatorem Entra firmy Microsoft. W tym module nie omówiono szczegółowo tego tematu, ale należy pamiętać, że termin roli może być używany w obu sytuacjach w dokumentacji.

Wybieranie odpowiedniego przypisania roli dla potoku

Przypisanie roli ma trzy kluczowe części: do kogo przypisano rolę ( przypisaną), co może zrobić ( rola) oraz jaki zasób lub zasoby ma zastosowanie przypisanie roli ( zakres).

Cesjonariusza

Podczas pracy z jednostką usługi przypisujesz role dla tej jednostki usługi. Identyfikator aplikacji jednostki usługi służy do identyfikowania prawidłowej jednostki usługi dla tego przypisania.

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, który umożliwia przypisywaniu odczytywanie informacji o zasobach, ale ich nie modyfikuje ani nie usuwa.
  • Współautor, który 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, który umożliwia pełną kontrolę nad zasobami, w tym udzielanie innym podmiotom zabezpieczeń dostępu.

Uwaga

Należy przyznać jednostkom usługi tylko minimalne uprawnienia, których potrzebują do wykonywania swoich zadań. W większości przypadków rola właściciela jest zbyt permisywna dla potoku wdrażania.

Istnieje również wiele określonych ról, które zapewniają dostęp tylko do podzbioru funkcji. Możesz również 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ć dokładnie, które uprawnienia należy dodać do niestandardowej definicji roli, a definicje ról mogą być przypadkowo zbyt restrykcyjne lub zbyt permisywne. Jeśli nie masz pewności, co należy 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 jednostka usługi może modyfikować. Typowe zakresy obejmują:

  • Pojedynczy zasób: możesz udzielić dostępu tylko do określonego zasobu. Zazwyczaj potoki wdrażania nie korzystają z tego zakresu, ponieważ potok 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 potoków 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 potoku wdrażania. Zamiast tego należy rozważyć określenie zakresu przypisań ról do grup zasobów, chyba że sam 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 będzie miała 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 potok będzie wdrażać tylko podstawowe szablony 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ść potoków musi wdrażać zasoby tylko w grupie zasobów, więc nie powinny mieć przypisanych ról w zakresie subskrypcji.
  • W przypadku wielu potoków dobrą opcją domyślną dla przypisania roli jest rola Współautor w zakresie grupy zasobów.
  • Rozważ wszystkie działania potoku i wszystko, co może zrobić w przyszłości. Możesz na przykład rozważyć utworzenie niestandardowej definicji roli dla potoku wdrażania witryny internetowej i przyznać uprawnienia tylko dla usług App Service i Application Insights. 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 potok, 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ć jednostkę usługi rolę Czytelnik z zakresem całej subskrypcji, a następnie oddzielnie przypisać tę samą jednostkę usługi rolę Współautor dla określonej grupy zasobów. Gdy jednostka usługi 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 jednostki usługi dla każdego środowiska i przyznać każdej jednostce usługi minimalny zestaw uprawnień potrzebnych do wdrożenia. Należy zachować szczególną ostrożność, aby uniknąć mieszania uprawnień do wdrożeń produkcyjnych z wdrożeniami w środowiskach nieprodukcyjnych.

Tworzenie przypisania roli dla jednostki usługi

Aby utworzyć przypisanie roli dla jednostki usługi, użyj az role assignment create polecenia . Musisz określić przypisanie, rolę i zakres:

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Przyjrzyjmy się każdemu argumentowi:

  • --assignee określa jednostkę usługi. Aby uniknąć niejednoznaczności, dobrym rozwiązaniem jest użycie identyfikatora aplikacji.
  • --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 jednostki usługi, użyj New-AzRoleAssignment polecenia cmdlet . Musisz określić przypisanie, rolę i zakres:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline 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 jednostki usługi.
  • -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.

Tworzenie jednostki usługi i przypisania roli w jednej operacji

Możesz również utworzyć przypisanie roli w tym samym czasie, w którym tworzysz jednostkę usługi. Kod jest podobny do polecenia użytego do utworzenia jednostki usługi w poprzednich lekcjach, ale z kilkoma dodatkowymi argumentami:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

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 wdrożysz zasoby w grupie zasobów przy użyciu jednostki usługi. Oto przykładowa definicja Bicep dla przypisania roli powyżej:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline 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 przypisania roli. Musi to być w postaci globalnie unikatowego identyfikatora (GUID). Dobrym rozwiązaniem jest użycie guid() funkcji w Bicep w celu utworzenia identyfikatora GUID i użycia identyfikatora podmiotu zabezpieczeń, identyfikatora definicji roli i zakresu jako argumentów inicjatora funkcji, aby upewnić się, że utworzysz nazwę unikatową dla każdego przypisania roli.
  • principalType należy ustawić wartość ServicePrincipal.
  • roleDefinitionId to w pełni kwalifikowany identyfikator zasobu dla przypisywanej definicji roli. Głównie będziesz pracować z wbudowanymi rolami i znajdziesz 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 wyrazić to przy użyciu w pełni kwalifikowanego identyfikatora zasobu, takiego jak /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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.