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

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:

• Definicja zasad
• Definicja inicjatywy
• Wykluczenie z zasad

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

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:

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.

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.

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.

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

• Dowiedz się więcej o strukturze definicji zasad.
• Dowiedz się więcej o strukturze przypisywania zasad.
• Dowiedz się, jak programowo tworzyć zasady.
• Dowiedz się, jak uzyskać dane zgodności.
• Dowiedz się, jak korygować niezgodne zasoby.
• W obszarze jak postępować zgodnie z praktykami dotyczącymi bezpiecznego wdrażania zasad