Udzielanie tożsamości roboczej 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 jednostce nauczysz się, jak autoryzować tożsamości robocze do wdrażania i konfigurowania zasobów platformy Azure, jednocześnie unikając nadawania niepotrzebnych uprawnień.

Autoryzacja tożsamości obciążenia pracą

Do tej pory skupiliśmy się na tożsamościach procesów roboczych i sposobach ich użycia do potwierdzenia tożsamości przepływu pracy wdrożeniowego wobec Microsoft Entra ID. To wszystko dotyczy uwierzytelniania .

Po uwierzytelnieniu tożsamości zadania przez Microsoft Entra ID następnym pytaniem jest: co może zrobić ta tożsamość zadania? 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 użytkownika zasobów dostępu do określonej grupy zasobów, subskrypcji lub grupy zarządzania.

Notatka

Wszystkie działania, które podejmujesz tutaj, wykorzystują system Azure RBAC do przyznawania dostępu w celu tworzenia i zarządzania zasobami platformy Azure, takimi jak konta magazynu, plan usługi Azure App Service oraz sieci wirtualne. Microsoft Entra ID ma również swój własny system ról, którego czasami nazywa się rolami katalogu . Te role służą do udzielania uprawnień tożsamościom roboczym do zarządzania Microsoft Entra ID. W tym module nie omówiono szczegółowo tego tematu, ale należy pamiętać, że termin rola jest używany 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ę (przypisanie), co mogą zrobić (rola ) i do którego zasobu lub zasobów ma zastosowanie przypisanie roli (zakres ).

Cesjonariusza

Podczas pracy z tożsamością zadania przypisujesz jej role. Aby przypisać rolę, musisz najpierw utworzyć jednostki 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 polecenia az ad sp create i określ identyfikator rejestracji aplikacji.

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

Aby utworzyć jednostkę usługi, użyj polecenia cmdlet New-AzADServicePrincipal i określ identyfikator 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 użytkownikowi odczytywanie informacji o zasobach, ale nie modyfikowanie ani usuwanie ich.
  • Współautor: umożliwia przypisanemu tworzenie zasobów oraz odczytywanie i modyfikowanie istniejących zasobów. Jednak współtwórcy nie mogą udzielać innym podmiotom dostępu do zasobów.
  • Właściciel: umożliwia pełną kontrolę nad zasobami, w tym udzielanie dostępu innym podmiotom.

Ostrożność

Przyznaj tożsamościom roboczym tylko minimalne uprawnienia potrzebne do wykonywania ich zadań. 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ą niestandardową definicję roli, aby określić dokładną listę uprawnień, które chcesz przypisać.

Notatka

Definicje ról niestandardowych mogą być potężnym sposobem udzielania uprawnień dla zasobów platformy Azure, ale mogą być trudne w użyciu. 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.

Zakres

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 procesów wdrażania.
  • subskrypcji: 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 pobłażliwe dla przepływu pracy wdrażania. Zamiast tego należy rozważyć ograniczenie przypisań ról do grup zasobów, chyba że przepływ pracy wdrożeniowego wymaga tworzenia grup 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ściciela.

  • Użyj najwęższego zakresu, który możesz. Większość przepływów pracy wymaga wdrażania zasobów jedynie w grupach zasobów, więc nie powinny mieć przypisanych ról na poziomie subskrypcji.

  • W przypadku wielu przepływów pracy dobrą opcją domyślną dla przypisania roli jest rola współtwórcy w obrębie zakresu 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 wdrażania witryny internetowej i przyznanie uprawnień tylko usłudze App Service i usłudze Application Insights. W przyszłym miesiącu może zaistnieć potrzeba dodania konta Azure Cosmos DB do pliku Bicep, ale rola niestandardowa zablokuje tworzenie zasobów 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 zarządzania dotyczące dozwolonych usług, SKU i lokalizacji.

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

Mieszanie i dopasowywanie przydziałów ról

Można utworzyć wiele przypisań ról, które zapewniają różne uprawnienia w różnych zakresach. Możesz na przykład nadać tożsamości roboczej rolę Czytelnika dla całej subskrypcji. Możesz oddzielnie przypisać tę samą tożsamość obciążenia pracy roli Kontrybutora 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 roboczej minimalny zestaw uprawnień, które są potrzebne do jej 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 polecenia az role assignment create. Musisz określić osobę odpowiedzialną, 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 polecenia cmdlet New-AzRoleAssignment. Określ osobę odpowiedzialną, 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 dla tożsamości zadania.
  • -RoleDefinitionName określa nazwę wbudowanej roli. Jeśli używasz niestandardowej definicji roli, to zamiast tego określ pełny identyfikator definicji roli, korzystając z 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 zwyczajem jest uzasadnienie przypisywania ról poprzez podanie opisu. Opis pomaga każdemu, kto później przegląda przypisania ról, zrozumieć ich przeznaczenie oraz sposób, w jaki został wybrany przypisany, rola i zakres.

Nota

Aktywacja przypisania ról może zająć kilka minut.

Uzyskaj dostęp 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 funkcji guid() w środowisku Bicep w celu utworzenia identyfikatora GUID. Aby upewnić się, że tworzysz nazwę unikatową dla każdego przypisania roli, użyj identyfikatora podmiotu, identyfikatora definicji roli i zakresu jako argumentów wejściowych funkcji.

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

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

    Na przykład rola współpracownika ma identyfikator definicji roli b24988ac-6180-42a0-ab88-20f7382dd24c. Gdy określasz to w pliku Bicep, używasz 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 głównego 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.