Kompleksowe zarządzanie kompleksowe na platformie Azure przy użyciu CI/CD

Podczas tworzenia modelu ładu dla organizacji należy pamiętać, że usługa Azure Resource Manager jest tylko jednym ze sposobów zarządzania zasobami. Usługa Azure DevOps oraz automatyzacja ciągłej integracji i ciągłego dostarczania (CI/CD) mogą stanowić niezamierzone tylnie wejście do bezpieczeństwa, jeśli nie są właściwie zabezpieczone. Te zasoby powinny być chronione przez dublowanie modelu kontroli dostępu opartej na rolach (RBAC) używanego dla usługi Resource Manager.

Kompleksowe zarządzanie jest niezależne od dostawców. Implementacja opisana w tym miejscu korzysta z usługi Azure DevOps, ale alternatywy są również krótko wymienione.

Potencjalne przypadki użycia

Ta implementacja referencyjna i pokaz są typu open source i mają być używane jako narzędzie do nauczania dla organizacji, które są nowe w usłudze DevOps i muszą utworzyć model ładu na potrzeby wdrażania na platformie Azure. Przeczytaj ten scenariusz dokładnie, aby zrozumieć decyzje dotyczące modelu używanego w tym przykładowym repozytorium.

Każdy model zapewniania ładu musi być powiązany z regułami biznesowymi organizacji, które są odzwierciedlane w dowolnej implementacji technicznej mechanizmów kontroli dostępu. W tym przykładowym modelu użyto fikcyjnej firmy z następującym typowym scenariuszem (z wymaganiami biznesowymi):

• Grupy Microsoft Entra, które są zgodne z domenami biznesowymi i modelami uprawnień
  Organizacja ma wiele pionowych domen biznesowych, takich jak "owoce" i "warzywa", które działają w dużej mierze niezależnie. W każdej domenie biznesowej istnieją dwa poziomy lub uprawnienia, które są przypisane do odrębnych grup Microsoft Entra. Dzięki temu deweloperzy mogą być precyzyjnie określeni podczas konfigurowania uprawnień w chmurze.

• Środowiska wdrażania
  Każdy zespół ma dwa środowiska:

  • Produkcja. Tylko administratorzy mają podwyższone uprawnienia.
  • Nieprodukcyjny. Wszyscy deweloperzy mają podwyższone uprawnienia (aby zachęcić do eksperymentowania i innowacji).

• Cele automatyzacji
  Każda aplikacja powinna implementować usługę Azure DevOps nie tylko na potrzeby ciągłej integracji, ale także ciągłego wdrażania (CD). Na przykład wdrożenia mogą być wyzwalane automatycznie przez zmiany w repozytorium Git.

• Dotychczasowa podróż w chmurze
  Organizacja rozpoczęła pracę z izolowanym modelem projektu, aby przyspieszyć podróż do chmury. Ale teraz badają opcje, aby złamać silosy i zachęcić do współpracy, tworząc projekty "współpracy" i "supermarketu".

Ten uproszczony diagram pokazuje mapowanie gałęzi w repozytorium Git na środowiska programistyczne, testowe i produkcyjne:

Pobierz plik SVG tego diagramu.

Architecture

Na tym diagramie pokazano, jak łączenie z usługi Resource Manager i ciągłej integracji/ciągłego wdrażania z Microsoft Entra ID jest kluczem do posiadania kompleksowego modelu zarządzania.

Pobierz plik SVG tej architektury.

Workflow

Numerowanie odzwierciedla kolejność, w jakiej administratorzy IT i architekci przedsiębiorstwa myślą i konfigurują swoje zasoby w chmurze.

1. Microsoft Entra ID

   Integrujemy usługę Azure DevOps z identyfikatorem Entra firmy Microsoft , aby mieć jedną płaszczyznę tożsamości. Oznacza to, że deweloper korzysta z tego samego konta Microsoft Entra zarówno dla usługi Azure DevOps, jak i usługi Resource Manager. Użytkownicy nie są dodawani indywidualnie. Zamiast tego członkostwo jest przypisywane przez grupy entra firmy Microsoft, abyśmy mogli usunąć dostęp dewelopera do zasobów w jednym kroku — usuwając ich członkostwo w grupie Microsoft Entra. Dla każdej domeny tworzymy:

   • Grupy firmy Microsoft Entra. Dwie grupy na domenę (opisane w kroku 4 i 5 w dalszej części tego artykułu).
   • Podmioty usługi Jedna jawna jednostka usługi na środowisko.

2. Środowisko produkcyjne

   Aby uprościć wdrażanie, ta implementacja referencyjna używa grupy zasobów do reprezentowania środowiska produkcyjnego. W praktyce należy użyć innej subskrypcji.

   Uprzywilejowany dostęp do tego środowiska jest ograniczony tylko do administratorów.

3. środowisko deweloperskie

   Aby uprościć wdrażanie, ta implementacja referencyjna używa grupy zasobów do reprezentowania środowiska deweloperskiego. W praktyce należy użyć innej subskrypcji.

4. Przypisania ról w usłudze Resource Manager

   Mimo że nazwy grup Entra firmy Microsoft oznaczają rolę, kontrole dostępu nie są stosowane do momentu skonfigurowania przypisania roli . Spowoduje to przypisanie roli do podmiotu Entra firmy Microsoft dla określonego zakresu. Na przykład deweloperzy mają rolę Współtwórca w środowisku produkcyjnym.

   Microsoft Entra główny podmiot	Środowisko deweloperskie (Resource Manager)	Środowisko produkcyjne (Menedżer zasobów)
   veggies-devs-group	Owner	Czytelnik
   veggies-admins-group	Właściciel	Właściciel
   veggies-ci-dev-sp	Rola niestandardowa *	–
   veggies-ci-prod-sp	–	Rola niestandardowa *

   * Aby uprościć wdrażanie, ta implementacja referencyjna przypisuje rolę Owner głównym usługom. Jednak w środowisku produkcyjnym należy utworzyć rolę niestandardową, która uniemożliwia podmiotowi usługi usunięcie wszelkich blokad zarządzania, które zostały umieszczone na twoich zasobach. Pomaga to chronić zasoby przed przypadkowymi uszkodzeniami, takimi jak usunięcie bazy danych.

   Aby zrozumieć przyczyny poszczególnych przypisań ról, zapoznaj się z sekcją dotyczącą zagadnień w dalszej części tego artykułu.

5. Przypisania grup zabezpieczeń w usłudze Azure DevOps

   Grupy zabezpieczeń działają jak role w usłudze Resource Manager. Korzystaj z wbudowanych ról, a dla deweloperów domyślnie wybieraj rolę Contributor. Administratorzy uzyskują przypisanie do grupy zabezpieczeń Administrator projektu w celu uzyskania podwyższonych uprawnień, co pozwala im skonfigurować uprawnienia zabezpieczeń.

   Pamiętaj, że usługi Azure DevOps i Resource Manager mają różne modele uprawnień:

   • Usługa Azure Resource Manager używa modelu uprawnień addytywnego .
   • Usługa Azure DevOps używa modelu najmniejszych uprawnień .

   Z tego powodu członkostwo w grupach -admins i -devs musi być wzajemnie wykluczające się. W przeciwnym razie osoby, których dotyczy problem, będą miały mniejszy dostęp niż oczekiwano w usłudze Azure DevOps.

   Nazwa grupy	Rola usługi Resource Manager	Rola usługi Azure DevOps
   fruits-all	–	–
   fruits-devs	Contributor	Contributor
   fruits-admins	Właściciel	Administratorzy projektu
   veggies-all	–	–
   veggies-devs	Contributor	Contributor
   veggies-admins	Właściciel	Administratorzy projektu
   infra-all	–	–
   infra-devs	Contributor	Contributor
   infra-admins	Właściciel	Administratorzy projektu

   W scenariuszu ograniczonej współpracy, takiej jak zespół ds. owoców zapraszający zespół ds. warzyw do współpracy nad pojedynczym repozytorium, korzysta z veggies-all grupy.

   Aby zrozumieć przyczyny poszczególnych przypisań ról, zapoznaj się z sekcją dotyczącą zagadnień w dalszej części tego artykułu.

6. Połączenia z usługami

   W usłudze Azure DevOps Połączenie usługi to ogólna otoczka wokół poświadczeń. Tworzymy połączenie usługi, które przechowuje identyfikator klienta jednostki usługi i klucz tajny klienta. Administratorzy projektu mogą skonfigurować dostęp do tego chronionego zasobu w razie potrzeby, na przykład w przypadku wymagania zatwierdzenia przez człowieka przed wdrożeniem. Ta architektura referencyjna ma dwa minimalne zabezpieczenia połączenia z usługą.

   • Administratorzy muszą skonfigurować uprawnienia potoku, aby kontrolować dostęp potoków do poświadczeń.
   • Administratorzy muszą również skonfigurować kontrolę gałęzi aby tylko projekty uruchomione w kontekście production gałęzi mogły używać elementu prod-connection.

7. Repozytoria Git

   Ponieważ nasze połączenia z usługą są powiązane z gałęziami za pośrednictwem kontrolek gałęzi, niezwykle ważne jest skonfigurowanie uprawnień do repozytoriów Git i zastosowanie zasad gałęzi. Oprócz wymagania, aby kompilacje CI przechodziły, wymagamy również, aby pull requesty miały co najmniej dwóch zatwierdzających.

Components

• Azure DevOps
• Microsoft Entra ID
• Menedżer Zasobów Azure
• Azure Repos
• Azure Pipelines

Alternatives

Koncepcja zarządzania end-to-end jest niezależna od dostawcy. Chociaż ten artykuł koncentruje się na usłudze Azure DevOps, serwer Usługi Azure DevOps może być używany jako lokalny zamiennik. Alternatywnie można również użyć zestawu technologii dla open-source'owego pipeline'u CI/CD, korzystając z opcji, takich jak Jenkins i GitLab.

Zarówno usługi Azure Repos, jak i GitHub to platformy, które są tworzone w celu korzystania z systemu kontroli wersji git typu open source. Chociaż ich zestawy funkcji są nieco inne, oba można zintegrować z globalnymi modelami zarządzania procesów ciągłej integracji/ciągłego wdrażania. GitLab to kolejna platforma oparta na usłudze Git, która zapewnia niezawodne funkcje ciągłej integracji/ciągłego wdrażania.

W tym scenariuszu narzędzie Terraform jest używane jako narzędzie infrastruktury jako kodu (IaC). Alternatywy to Jenkins, Ansible i Chef.

Rozważania

Aby osiągnąć kompleksowe zarządzanie na platformie Azure, ważne jest, aby zrozumieć profil zabezpieczeń i uprawnień ścieżki z komputera dewelopera do środowiska produkcyjnego. Na poniższym diagramie ilustruje podstawowy przepływ pracy ciągłej integracji (CI) i ciągłego wdrażania (CD) w usłudze Azure DevOps. Ikona czerwonej blokady wskazuje uprawnienia zabezpieczeń, które muszą być skonfigurowane przez użytkownika. Niekonfigurowanie lub błędna konfiguracja uprawnień sprawi, że obciążenia będą podatne na zagrożenia.

Pobierz plik SVG tego przepływu pracy.

Aby pomyślnie zabezpieczyć obciążenia, należy użyć połączenia konfiguracji uprawnień zabezpieczeń i ludzkiej kontroli w przepływie pracy. Ważne jest, aby każdy model RBAC obejmował zarówno potoki, jak i kod. Te procesy często działają z uprzywilejowanymi tożsamościami i zniszczą obciążenia, jeżeli otrzymają taką instrukcję. Aby temu zapobiec, należy skonfigurować zasady gałęzi w repozytorium, aby wymagać manualnej akceptacji przed zaakceptowaniem zmian uruchamiających potoki automatyzacji.

Podczas projektowania modelu ładu należy wziąć pod uwagę następujące pojęcia i pytania. Należy pamiętać o potencjalnych przypadkach użycia tej przykładowej organizacji.

Zabezpiecz swoje środowiska za pomocą polityk gałęzi

Ponieważ kod źródłowy definiuje wdrożenia i wyzwala je, pierwszym wierszem obrony jest zabezpieczenie repozytorium zarządzania kodem źródłowym (SCM). W praktyce jest to osiągane przy użyciu workflow Pull Request w połączeniu z politykami gałęzi, które definiują kontrole i wymagania przed zaakceptowaniem kodu.

Podczas planowania kompleksowego modelu zapewniania ładu uprzywilejowani użytkownicy (veggies-admins) będą odpowiedzialni za konfigurowanie ochrony gałęzi. Typowe kontrole ochrony gałęzi używane do zabezpieczania wdrożeń obejmują:

• Wymagaj pomyślnego zakończenia kompilacji CI. Przydatne do ustanawiania jakości kodu bazowego, takich jak linting kodu, testy jednostkowe, a nawet testy bezpieczeństwa, takie jak skanowanie wirusów i poświadczeń.

• Wymagaj przeglądu równorzędnego Niech inny człowiek dokładnie sprawdzi, czy kod działa zgodnie z założeniami. Podczas wprowadzania zmian w kodzie potoku należy zachować szczególną ostrożność. Połącz z kompilacjami ciągłej integracji, aby przeglądy kodu były mniej uciążliwe.

Co się stanie, jeśli deweloper spróbuje zdeployować bezpośrednio do środowiska produkcyjnego?

Pamiętaj, że usługa Git jest rozproszonym systemem SCM. Deweloper może zatwierdzić bezpośrednio w swojej gałęzi lokalnej production . Jednak gdy narzędzie Git jest prawidłowo skonfigurowane, taki push zostanie automatycznie odrzucony przez serwer Git. Przykład:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Należy pamiętać, że przepływ pracy w przykładzie jest niezależny od dostawcy. Funkcje żądania wciągnięcia i ochrony gałęzi są dostępne u wielu dostawców SCM, w tym Azure Repos, GitHub i GitLab.

Po zaakceptowaniu kodu w gałęzi chronionej kolejna warstwa kontroli dostępu zostanie zastosowana przez serwer kompilacji (np. Azure Pipelines).

2. Jakiego dostępu potrzebują podmioty zabezpieczeń?

Na platformie Azure podmiot zabezpieczeń może być podmiotem użytkownika lub podmiotem bez użytkownika, takim jak jednostka usługi lub tożsamość zarządzana. We wszystkich środowiskach podmioty zabezpieczeń powinny przestrzegać zasady najniższych uprawnień. Chociaż podmioty zabezpieczeń mogły mieć rozszerzony dostęp w środowiskach przedprodukcyjnych, produkcyjne środowiska platformy Azure powinny zminimalizować stałe uprawnienia, faworyzując dostęp just in time (JIT) i dostęp warunkowy firmy Microsoft Entra. Utwórz przypisania ról RBAC platformy Azure dla identyfikatorów użytkowników zgodnie z zasadą najmniejszych uprawnień.

Ważne jest również, aby modelować kontrolę dostępu opartą na rolach w Azure odmiennie od kontroli dostępu opartej na rolach w Azure DevOps. Celem pipeline'u jest zminimalizowanie bezpośredniego dostępu do platformy Azure. Z wyjątkiem przypadków specjalnych, takich jak innowacje, uczenie się i rozwiązywanie problemów, większość interakcji z platformą Azure powinna być prowadzona za pomocą specjalnie utworzonych i ogrodzonych potoków.

W przypadku jednostek usługi Azure Pipeline rozważ użycie roli niestandardowej, która uniemożliwia usunięcie blokad zasobów oraz wykonanie innych destrukcyjnych akcji, które są poza zakresem jej przeznaczenia.

3. Utwórz rolę niestandardową dla głównego podmiotu usługi używanego do uzyskiwania dostępu do produkcji

Częstym błędem jest nadawanie agentom budowy CI/CD ról właściciela i uprawnień. Uprawnienia współtwórcy nie są wystarczające, jeśli potok wymaga również wykonywania przypisania ról tożsamości lub innych uprzywilejowanych operacji, takich jak zarządzanie zasadami usługi Key Vault.

Jednak agent budowania w procesie CI/CD usunie całe środowisko produkcyjne, jeśli zostanie mu to polecone. Aby uniknąć nieodwracalnych zmian destrukcyjnych, tworzymy rolę niestandardową, która:

• Usuwa zasady dostępu usługi Key Vault
• Usuwa blokady zarządzania , które zgodnie z projektem powinny uniemożliwiać usuwanie zasobów (typowe wymaganie w branżach regulowanych)

W tym celu usuniemy akcje Microsoft.Authorization/*/Delete i utworzymy rolę niestandardową.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Jeśli spowoduje to usunięcie zbyt wielu uprawnień do Twoich celów, zapoznaj się z pełną listą w oficjalnej dokumentacji dotyczącej operacji dostawcy zasobów platformy Azure i dostosuj definicję roli zgodnie z potrzebami.

Wdrażanie tego scenariusza

Ten scenariusz wykracza poza usługę Resource Manager. Dlatego używamy narzędzia Terraform, które umożliwia nam również tworzenie zasad w usłudze Microsoft Entra ID i inicjalizację usługi Azure DevOps przy użyciu jednego narzędzia do infrastruktury jako kodu.

Aby uzyskać kod źródłowy i szczegółowe instrukcje, odwiedź repozytorium GitHub Governance on Azure Demo - od DevOps do ARM.

Pricing

Koszty usługi Azure DevOps zależą od liczby użytkowników w organizacji, którzy wymagają dostępu, wraz z innymi czynnikami, takimi jak liczba wymaganych współbieżnych kompilacji/wydań i liczba użytkowników. Usługi Azure Repos i Azure Pipelines to funkcje usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz cennik usługi Azure DevOps.

W usłudze Microsoft Entra ID typ zarządzania dostępem do grupy wymagany w tym scenariuszu jest dostępny w wersjach Premium P1 i Premium P2. Ceny tych warstw są obliczane dla poszczególnych użytkowników. Aby uzyskać więcej informacji, zobacz Cennik firmy Microsoft Entra.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Julie Ng | Starszy inżynier ds. usług

Dalsze kroki

• Odwiedź repozytorium kodu dla tego scenariusza w sekcji Zarządzanie na Azure — demo: od DevOps do ARM.
• Zapoznaj się z przewodnikami zarządzania chmurą w ramach Cloud Adoption Framework.
• Co to jest kontrola dostępu oparta na rolach (RBAC) platformy Azure?
• Cloud Adoption Framework: zarządzanie dostępem do zasobów na platformie Azure
• Role usługi Azure Resource Manager
  • Właściciel (wbudowany)
  • Współautor (wbudowany)
  • Czytelnik (wbudowany)
  • Rola niestandardowa
• Grupy zabezpieczeń usługi Azure DevOps
  • Administratorzy projektu
  • Contributor
  • Reader