Udostępnij za pośrednictwem

Projektowanie przepływów pracy typu „zasady platformy Azure jako kod”

W miarę postępu w dziedzinie zarządzania w chmurze, należy przejść od ręcznego zarządzania poszczególnymi przypisaniami zasad w portalu Azure lub za pośrednictwem różnych zestawów SDK, do bardziej zorganizowanego i powtarzalnego sposobu zarządzania na skalę przedsiębiorstwa. Dwa z dominujących podejść do zarządzania systemami na dużą skalę w chmurze to:

  • Infrastruktura jako kod: praktyka traktowania zawartości definiującej środowiska — od szablonów usługi Azure Resource Manager (szablonów usługi ARM) do definicji usługi Azure Policy do usługi Azure Blueprints jako kodu źródłowego.
  • DevOps: związek osób, procesów i produktów w celu umożliwienia ciągłego dostarczania wartości użytkownikom końcowym.

Usługa Azure Policy jako kod jest kombinacją tych pomysłów. Zasadniczo należy zachować definicje zasad w kontroli źródła i za każdym razem, gdy zmiana zostanie wprowadzona, przetestuj i zweryfikuj ją. Nie powinno to jednak być zakresem zaangażowania polityk w infrastrukturę jako kod lub metodę DevOps.

Krok weryfikacji powinien być również składnikiem innych przepływów pracy ciągłej integracji lub ciągłego wdrażania (CI/CD), takich jak wdrażanie środowiska aplikacji lub infrastruktury wirtualnej. Dzięki temu, że weryfikacja zasad Azure Policy staje się wczesnym elementem procesu budowy i wdrażania, zespoły ds. aplikacji i operacji odkrywają, czy ich zmiany zachowują się zgodnie z oczekiwaniami na długo, zanim jest za późno i gdy próbują wdrożyć je w środowisku produkcyjnym.

Definicje i podstawowe informacje

Zanim przejdziesz do szczegółów przepływu pracy usługi Azure Policy jako kodu, ważne jest, aby zrozumieć niektóre podstawowe pojęcia, takie jak tworzenie definicji zasad i definicji inicjatyw oraz jak korzystać z wykluczeń dotyczących przypisań tych definicji:

Nazwy plików odpowiadają niektórym fragmentom definicji zasad lub inicjatyw oraz innym zasobom zasad:

Format pliku Zawartość pliku
policy-v#.json Cała definicja zasad dla tej wersji
policyset-v#.json Cała definicja inicjatywy dla tej wersji
policy-v#.parameters.json Część properties.parameters definicji zasad
policyset-v#.parameters.json Część properties.parameters definicji inicjatywy
policy-v#.rules.json Część properties.policyRule definicji zasad
policyset-v#.definitions.json Część properties.policyDefinitions definicji inicjatywy
exemptionName.json Wykluczenie z zasad, które jest przeznaczone dla określonego zasobu lub zakresu

Omówienie przepływu pracy

Zalecany ogólny przepływ pracy usługi Azure Policy w postaci kodu wygląda następująco:

Diagram przedstawiający elementy przepływu pracy usługi Azure Policy jako kod, od Tworzenia do Testowania i Wdrożenia.

Kontrola źródła

Istniejące definicje zasad i inicjatyw można eksportować na różne sposoby, takie jak za pomocą programu PowerShell, interfejsu wiersza polecenia lub zapytań usługi Azure Resource Graph (ARG). Wybrane środowisko zarządzania kontrolą źródła do przechowywania tych definicji może być jedną z wielu opcji, w tym GitHub lub Azure DevOps.

Tworzenie i aktualizowanie definicji zasad

Definicje zasad są tworzone przy użyciu formatu JSON i przechowywane w kontroli źródła. Każda zasada ma własny zestaw plików, takich jak parametry, reguły i parametry środowiska, które powinny być przechowywane w tym samym folderze. Poniższa struktura jest zalecanym sposobem przechowywania definicji zasad w kontroli źródła.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Po dodaniu nowych zasad lub nowej wersji lub zaktualizowaniu istniejącej wersji przepływ pracy powinien automatycznie zaktualizować definicję zasad na platformie Azure. Testowanie nowej lub zaktualizowanej definicji zasad jest w późniejszym kroku.

Tworzenie i aktualizowanie definicji inicjatyw

Definicje inicjatyw są również tworzone przy użyciu plików JSON, które powinny być przechowywane w tym samym folderze co definicje zasad. Definicja inicjatywy wymaga, aby definicja zasad już istniała, więc nie można jej utworzyć ani zaktualizować, dopóki źródło zasad nie zostanie zaktualizowane w kontroli źródła, a następnie zaktualizowane na platformie Azure. Poniższa struktura jest zalecanym sposobem przechowywania definicji inicjatywy w systemie kontroli wersji.

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Podobnie jak w przypadku definicji zasad, przepływ pracy powinien automatycznie aktualizować definicję inicjatywy na platformie Azure po dodaniu lub zaktualizowaniu istniejącej inicjatywy. Testowanie nowej lub zaktualizowanej definicji inicjatywy jest w późniejszym kroku.

Uwaga

Zaleca się użycie scentralizowanego mechanizmu wdrażania, takiego jak przepływy pracy usługi GitHub lub usługa Azure Pipelines, w celu wdrożenia zasad. Pomaga to zagwarantować, że w twoim środowisku są wdrażane tylko zweryfikowane zasoby zasad oraz że stosowany jest centralny mechanizm wdrażania stopniowego. Uprawnienia do zapisu do zasobów zasad mogą być ograniczone do tożsamości używanej podczas wdrożenia.

Testowanie i weryfikowanie zaktualizowanej definicji

Gdy automatyzacja podjęła nowo utworzone lub zaktualizowane definicje zasad lub inicjatywy i wprowadziła aktualizację obiektu na platformie Azure, nadszedł czas na przetestowanie wprowadzonych zmian. Zasady lub inicjatywy, które są jej częścią, powinny być następnie przypisywane do zasobów w najbardziej odległym środowisku od środowiska produkcyjnego. To środowisko to zazwyczaj Dev.

Uwaga

W tym kroku przeprowadzamy testowanie integracji definicji zasad w środowisku platformy Azure. Jest to oddzielone od weryfikowania funkcjonalności definicji zasad, która powinna wystąpić podczas procesu tworzenia definicji.

Przypisanie powinno używać funkcji enforcementMode jako wyłączony, aby tworzenie zasobów i aktualizacje nie były blokowane, ale istniejące zasoby są nadal kontrolowane pod kątem zgodności ze zaktualizowaną definicją zasad. Nawet w przypadku trybu wymuszania zaleca się, aby zakres przypisania był grupą zasobów lub subskrypcją przeznaczoną specjalnie do walidacji zasad.

Uwaga

Chociaż tryb wymuszania jest przydatny, nie jest to zamiennik dokładnego testowania definicji zasad w różnych warunkach. Definicja zasad powinna być testowana przy użyciu PUTPATCH wywołań interfejsu API REST, zgodnych i niezgodnych zasobów oraz przypadków brzegowych, takich jak brak właściwości z zasobu.

Po wdrożeniu przypisania użyj zestawu SDK usługi Azure Policy, zadania Oceny zabezpieczeń i zgodności usługi Azure Pipelines lub zapytań usługi Azure Resource Graph (ARG) (zobacz przykłady), aby uzyskać informacje o zgodności dotyczące nowego przypisania. Środowisko używane do testowania zasad i przypisań powinno mieć zasoby o różnych stanach zgodności. Podobnie jak dobry test jednostkowy dla kodu, chcesz przetestować, czy zasoby są oceniane zgodnie z oczekiwaniami bez wyników fałszywie dodatnich ani fałszywie ujemnych. Jeśli testujesz i weryfikujesz tylko dla tego, czego oczekujesz, może wystąpić nieoczekiwany i niezidentyfikowany wpływ wynikający z polityki. Aby uzyskać więcej informacji, zobacz Ocena wpływu nowej definicji usługi Azure Policy.

Włączyć zadania naprawcze

Jeśli weryfikacja przypisania spełnia oczekiwania, następnym krokiem jest zweryfikowanie działania naprawczego. Zasady korzystające z deployIfNotExists lub modify mogą mieć uruchomione powiązane zadanie naprawcze, aby poprawić zasoby z niezgodnego stanu i doprowadzić je do zgodności.

Pierwszym krokiem do skorygowania zasobów jest przyznanie przypisaniu zasad przypisania ról zdefiniowanego w definicji zasad. To przypisanie roli daje zarządzanej tożsamości wystarczające uprawnienia, aby wprowadzić potrzebne zmiany i zapewnić zgodność zasobu.

Gdy przypisanie zasad ma odpowiednie prawa, użyj SDK do zasad, aby uruchomić zadanie naprawcze względem zestawu zasobów, które są znane jako niezgodne. Przed kontynuowaniem należy wykonać trzy testy względem tych skorygowanych zadań:

  • Sprawdź, czy zadanie korygowania zostało ukończone pomyślnie
  • Uruchom ocenę zasad, aby zobaczyć, że wyniki zgodności zasad są aktualizowane zgodnie z oczekiwaniami
  • Uruchamianie testu jednostkowego środowiska względem zasobów bezpośrednio w celu sprawdzenia, czy ich właściwości uległy zmianie

Testowanie zarówno zaktualizowanych wyników oceny zasad, jak i środowiska, zapewnia bezpośrednie potwierdzenie, że zadania korygujące doprowadziły do zmian oczekiwanych rezultatów i że definicja zasad odnotowała zmianę zgodności zgodnie z oczekiwaniami.

Aktualizacja zleconych zadań

Po zakończeniu wszystkich bram weryfikacji zaktualizuj przypisanie, aby używać elementu enforcementMode włączonego. Zaleca się wprowadzenie tej zmiany początkowo w tym samym środowisku daleko od środowiska produkcyjnego. Sprawdź, czy żądane efekty są stosowane podczas tworzenia zasobów i aktualizacji zasobów. Gdy to środowisko zostanie zweryfikowane jako działające zgodnie z oczekiwaniami, zmiana powinna zostać ograniczona do uwzględnienia następnego środowiska itd., dopóki zasady nie zostaną wdrożone w zasobach produkcyjnych.

Integrowane oceny procesów

Ogólny przepływ pracy usługi Azure Policy jako kod służy do opracowywania i wdrażania zasad i inicjatyw w środowisku na dużą skalę. Jednak ocena polityk powinna być częścią procesu wdrażania każdego przepływu pracy, który wdraża lub tworzy zasoby na platformie Azure, takie jak wdrażanie aplikacji lub korzystanie z szablonów ARM w celu utworzenia infrastruktury.

W takich przypadkach po zakończeniu wdrażania aplikacji lub infrastruktury w ramach testowej subskrypcji lub grupy zasobów należy przeprowadzić ocenę zasad dla tego zakresu sprawdzania poprawności wszystkich istniejących zasad i inicjatyw. Chociaż można je skonfigurować jako tryb wymuszaniawyłączony w takim środowisku, warto wiedzieć wcześ­nie, czy wdrożenie aplikacji lub infrastruktury narusza definicje zasad. W związku z tym ocena zasad powinna być krokiem w tych przepływach pracy i umożliwić anulowanie wdrożeń, które tworzą niezgodne zasoby.

Wykonaj przegląd

W tym artykule opisano ogólny przepływ pracy w ramach Azure Policy jako kod oraz wyjaśniono, gdzie ocena zasad powinna być częścią innych przepływów pracy wdrażania. Ten przepływ pracy może być używany w dowolnym środowisku, które obsługuje kroki skryptowe i automatyzację na podstawie wyzwalaczy.

Następne kroki