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

  • Artykuł

Podczas przechodzenia do ładu w chmurze należy przejść od ręcznego zarządzania każdą definicją zasad w Azure Portal lub za pomocą różnych zestawów SDK do czegoś bardziej możliwego do zarządzania i powtarzalnego w skali 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 Azure Policy definicji 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.

Azure Policy, ponieważ kod jest kombinacją tych koncepcji. Zasadniczo należy zachować definicje zasad w kontroli źródła i za każdym razem, gdy zmiana zostanie wprowadzonych, przetestuj i zweryfikuj ją. Nie powinno to jednak być zakresem zaangażowania zasad w infrastrukturę jako kod lub metodyę 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. Wprowadzając Azure Policy weryfikację wczesnego składnika procesu kompilacji i wdrażania, zespoły ds. aplikacji i operacji wykryją, czy ich zmiany zachowują się zgodnie z oczekiwaniami na długo przed zbyt późno i próbują wdrożyć je w środowisku produkcyjnym.

Definicje i podstawowe informacje

Zanim przejdziesz do szczegółów Azure Policy jako przepływu pracy kodu, ważne jest, aby zrozumieć, jak tworzyć definicje zasad i definicje inicjatyw:

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

Format pliku Zawartość pliku
policy.json Cała definicja zasad
policyset.json Cała definicja inicjatywy
policy.parameters.json Część properties.parameters definicji zasad
policyset.parameters.json Część properties.parameters definicji inicjatywy
policy.rules.json Część properties.policyRule definicji zasad
policyset.definitions.json Część properties.policyDefinitions definicji inicjatywy

Przykłady tych formatów plików są dostępne w repozytorium github Azure Policy:

Omówienie przepływu pracy

Zalecany ogólny przepływ pracy Azure Policy jak kod wygląda jak na poniższym diagramie:

Diagram przedstawiający Azure Policy jako pola przepływu pracy Kodu z obszaru Tworzenie do testowania do wdrożenia.

Kontrola źródła

Istniejące definicje zasad i inicjatyw można eksportować za pomocą zapytań programu PowerShell, interfejsu wiersza polecenia lub 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
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|

Po dodaniu nowych zasad lub zaktualizowaniu istniejącego przepływu 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 już istnienia definicji zasad, 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 utrzymania definicji inicjatyw w kontroli źródła:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an 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
|
|  |- init2/ _________________________ # Subfolder for an 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
|

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 tylko przeglądane zasoby zasad są wdrażane w środowisku i że jest używany centralny mechanizm wdrażania. Uprawnienia do zapisu do zasobów zasad można ograniczyć do tożsamości używanej we wdrożeniu.

Testowanie i weryfikowanie zaktualizowanej definicji

Po dokonaniu automatyzacji nowo utworzonych lub zaktualizowanych definicji zasad lub inicjatyw i wprowadzeniu aktualizacji do obiektu na platformie Azure nadszedł czas na przetestowanie wprowadzonych zmian. Zasady lub inicjatywy, które są jego częścią, powinny być następnie przypisywane do zasobów w środowisku najdalej od środowiska produkcyjnego. To środowisko jest zwykle deweloperem.

Przypisanie powinno używać opcji enforcementModewyłączonej , aby tworzenie zasobów i aktualizacje nie były blokowane, ale istniejące zasoby są nadal poddawane inspekcji pod kątem zgodności ze zaktualizowaną definicją zasad. Nawet w trybie enforcementMode zaleca się, aby zakres przypisania był grupą zasobów lub subskrypcją przeznaczoną specjalnie do sprawdzania poprawności zasad.

Uwaga

Tryb wymuszania jest przydatny, ale nie zastępuje dokładnie 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 Azure Policy, zadania Oceny zabezpieczeń i zgodności usługi Azure Pipelines lub zapytań usługi Azure Resource Graph (zobaczprzykłady), aby uzyskać dane zgodności dla 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 lub fałszywie ujemnych. Jeśli testujesz i weryfikujesz tylko oczekiwane elementy, może wystąpić nieoczekiwany i niezidentyfikowany wpływ z zasad. Aby uzyskać więcej informacji, zobacz Ocena wpływu nowej definicji Azure Policy.

Włączanie zadań korygowania

Jeśli weryfikacja przypisania spełnia oczekiwania, następnym krokiem jest zweryfikowanie korygowania. Zasady korzystające z metody deployIfNotExists lub modyfikujące mogą mieć wyzwalane skojarzone zadanie korygowania w celu skorygowania zasobów ze stanu niezgodnego i zapewnienia zgodności.

Pierwszym krokiem do skorygowania zasobów jest przyznanie przypisania zasad przypisanie roli zdefiniowanej w definicji zasad. To przypisanie roli zapewnia tożsamości zarządzanej przypisania zasad wystarczające prawa, aby wprowadzić wymagane zmiany w celu zapewnienia zgodności zasobu.

Gdy przypisanie zasad ma odpowiednie prawa, użyj zestawu SDK zasad, aby wyzwolić zadanie korygowania 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 sprawdzić, czy 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 korygowania zmieniły oczekiwaną wartość i że definicja zasad odnotowała zmianę zgodności zgodnie z oczekiwaniami.

Aktualizacja do wymuszonych przypisań

Po zakończeniu wszystkich bram sprawdzania poprawności zaktualizuj przypisanie, aby używać elementu enforcementModewłączonego. Zaleca się wprowadzenie tej zmiany początkowo w tym samym środowisku daleko od środowiska produkcyjnego. Po zweryfikowaniu tego środowiska jako działającego zgodnie z oczekiwaniami zmiana powinna zostać ograniczona do następnego środowiska i tak dalej, dopóki zasady nie zostaną wdrożone w zasobach produkcyjnych.

Integrowane oceny procesów

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

W takich przypadkach po zakończeniu wdrażania aplikacji lub infrastruktury w ramach subskrypcji testowej lub grupy zasobów należy przeprowadzić ocenę zasad dla tego zakresu, sprawdzając weryfikację wszystkich istniejących zasad i inicjatyw. Chociaż można je skonfigurować jako tryb enforcementModewyłączone w takim środowisku, warto wiedzieć wcześnie, czy wdrożenie aplikacji lub infrastruktury narusza definicje zasad na wczesnym etapie. W związku z tym ocena zasad powinna być krokiem w tych przepływach pracy i wdrożeniach, które kończą się niepowodzeniem, tworzącymi niezgodne zasoby.

Przegląd

W tym artykule opisano ogólny przepływ pracy dla Azure Policy jako kod, a także miejsce, w którym 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