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

  • Artykuł

W miarę postępu podróży za pomocą ładu w chmurze należy przejść od ręcznego zarządzania poszczególnymi przypisaniami zasad w witrynie Azure Portal lub za pośrednictwem 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 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 zostanie wprowadzona zmiana, 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. Dzięki weryfikacji usługi Azure Policy wczesnego składnika procesu kompilacji i wdrażania zespoły ds. aplikacji i operacji wykryją, czy ich zmiany zachowują się zgodnie z oczekiwaniami, zanim za późno i 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:

File format 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
exemptionName.json Wykluczenie z zasad, które jest przeznaczone dla określonego zasobu lub zakresu

Przykłady tych formatów plików są dostępne w repozytorium GitHub usługi Azure Policy

Omówienie przepływu pracy

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

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

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
|     |- 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
|     |- 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
|     |- 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
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Po dodaniu nowych zasad lub zaktualizowaniu istniejącego przepływu pracy powinien zostać automatycznie zaktualizowany definicja 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 utrzymania definicji inicjatywy 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
|     |- 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
|     |- 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 środowisku są wdrażane tylko zweryfikowane zasoby zasad i że jest używany mechanizm wdrażania stopniowego i centralnego. Uprawnienia do zapisu do zasobów zasad mogą być ograniczone do tożsamości używanej we wdrożeniu.

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 jest zwykle deweloperem.

Uwaga

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

Przypisanie powinno używać funkcji enforcementMode wyłączone, 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 przypadku wymuszaniaMode zaleca się, aby zakres przypisania był grupą zasobów lub subskrypcją przeznaczoną specjalnie do sprawdzania poprawności 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), 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 ani 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 usługi 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 zdefiniowane w definicji zasad. To przypisanie roli daje tożsamości zarządzanej przypisania zasad wystarczające uprawnienia, 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 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 korygowania zmieniły oczekiwaną wartość i że definicja zasad odnotowała zmianę zgodności zgodnie z oczekiwaniami.

Aktualizacja wymuszanych przypisań

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 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 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 wymuszanieModewyłą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 nie są zgodne.

Wykonaj przegląd

W tym artykule opisano ogólny przepływ pracy usługi 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