Bezpieczne wdrażanie przypisań usługi Azure Policy
W miarę rozszerzania środowiska zapotrzebowanie na kontrolowany potok ciągłego wdrażania (CD) z progresywną kontrolą ekspozycji. W związku z tym firma Microsoft zaleca zespołom DevOps przestrzeganie struktury bezpiecznych praktyk wdrażania (SDP). Bezpieczne wdrażanie definicji i przypisań usługi Azure Policy pomaga ograniczyć wpływ niezamierzonych zachowań zasobów zasad.
Ogólne podejście do implementowania protokołu SDP za pomocą usługi Azure Policy polega na stopniowym wdrażaniu przypisań zasad według pierścieni w celu wykrywania zmian zasad wpływających na środowisko we wczesnych etapach, zanim wpłynie to na krytyczną infrastrukturę chmury.
Pierścienie wdrażania można organizować na różne sposoby. W tym samouczku z instrukcjami pierścienie są podzielone przez różne regiony platformy Azure z pierścieniem 0 reprezentującym niekrytyczne, małe lokalizacje ruchu i Pierścień 5 oznaczające najbardziej krytyczne, najwyższe lokalizacje ruchu.
Procedura bezpiecznego wdrażania przypisań usługi Azure Policy z efektami odmowy lub dołączania
Użyj poniższego schematu blokowego jako odwołania, ponieważ pracujemy nad zastosowaniem struktury SDP do przypisań usługi Azure Policy korzystających z deny
efektów zasad lub append
.
Uwaga
Aby dowiedzieć się więcej na temat efektów zasad platformy Azure, zobacz Omówienie działania efektów.
Numery kroków schematu blokowego:
Po wybraniu definicji zasad przypisz zasady w najwyższym zakresie obejmującym wszystkie pierścienie wdrażania. Zastosuj selektory zasobów, aby zawęzić zastosowanie do najmniej krytycznego pierścienia
"kind": "resource location"
przy użyciu właściwości .audit
Skonfiguruj typ efektu przy użyciu przesłonięć przypisania. Przykładowy selektor z lokalizacjąeastUS
i efektem jakoaudit
:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "overrides":[{ "kind": "policyEffect", "value": "Audit" }]
Po wdrożeniu przypisania i zakończeniu początkowego skanowania zgodności sprawdź, czy wynik zgodności jest zgodny z oczekiwaniami.
Należy również skonfigurować testy automatyczne, które uruchamiają testy zgodności. Sprawdzanie zgodności powinno obejmować następującą logikę:
- Zbieranie wyników zgodności
- Jeśli wyniki zgodności są zgodne z oczekiwaniami, potok powinien kontynuować
- Jeśli wyniki zgodności nie są zgodne z oczekiwaniami, potok powinien zakończyć się niepowodzeniem i należy rozpocząć debugowanie
Na przykład można skonfigurować sprawdzanie zgodności przy użyciu innych narzędzi w ramach określonego potoku ciągłej integracji/ciągłego wdrażania (CI/CD).
Na każdym etapie wdrażania kontrola kondycji aplikacji powinna potwierdzić stabilność usługi i wpływ zasad. Jeśli wyniki nie są zgodnie z oczekiwaniami ze względu na konfigurację aplikacji, refaktoryzuj aplikację zgodnie z potrzebami.
Powtórz, rozwijając wartości właściwości selektora zasobów, aby uwzględnić następne pierścienie. lokalizacje i weryfikowanie oczekiwanych wyników zgodności i kondycji aplikacji. Przykładowy selektor z wartością lokalizacji dodanej:
"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS", "westUS"] }] }]
Po pomyślnym przypisaniu zasad do wszystkich pierścieni przy użyciu
audit
trybu potok powinien wyzwolić zadanie, które zmienia efektdeny
zasad i resetuje selektory zasobów do lokalizacji skojarzonej z pierścieniem 0. Przykładowy selektor z jednym regionem i efektem ustawionym na odmowę:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "overrides":[{ "kind": "policyEffect", "value": "Deny" }]
Po zmianie efektu zautomatyzowane testy powinny sprawdzić, czy wymuszanie odbywa się zgodnie z oczekiwaniami.
Powtórz, dołączając więcej pierścieni w konfiguracji selektora zasobów.
Powtórz ten proces dla wszystkich pierścieni produkcyjnych.
Procedura bezpiecznego wdrażania przypisań usługi Azure Policy z modyfikacją lub wdrożeniem efektówIfNotExists
Kroki dotyczące zasad korzystających z modify
efektów lub deployIfNotExists
są podobne do kroków opisanych wcześniej przy użyciu dodatkowej akcji korzystania z trybu wymuszania i wyzwalania zadania korygowania.
Przejrzyj następujący schemat blokowy z zmodyfikowanymi krokami 5–9:
Numery kroków schematu blokowego:
Po wybraniu definicji zasad przypisz zasady w najwyższym zakresie obejmującym wszystkie pierścienie wdrażania. Zastosuj selektory zasobów, aby zawęzić zastosowanie do najmniej krytycznego pierścienia
"kind": "resource location"
przy użyciu właściwości . Skonfiguruj tryb wymuszania przypisania do DoNotEnforce. Przykładowy selektor z lokalizacjąeastUS
i wymuszanieMode jako DoNotEnforce:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "enforcementMode": "DoNotEnforce"
Po wdrożeniu przypisania i zakończeniu początkowego skanowania zgodności sprawdź, czy wynik zgodności jest zgodny z oczekiwaniami.
Należy również skonfigurować testy automatyczne, które uruchamiają testy zgodności. Sprawdzanie zgodności powinno obejmować następującą logikę:
- Zbieranie wyników zgodności
- Jeśli wyniki zgodności są zgodne z oczekiwaniami, potok powinien kontynuować
- Jeśli wyniki zgodności nie są zgodne z oczekiwaniami, potok powinien zakończyć się niepowodzeniem i należy rozpocząć debugowanie
Sprawdzanie zgodności można skonfigurować przy użyciu innych narzędzi w potoku ciągłej integracji/ciągłego wdrażania (CI/CD).
Na każdym etapie wdrażania kontrola kondycji aplikacji powinna potwierdzić stabilność usługi i wpływ zasad. Jeśli wyniki nie są zgodnie z oczekiwaniami ze względu na konfigurację aplikacji, refaktoryzuj aplikację zgodnie z potrzebami.
Możesz również wyzwolić zadania korygowania w celu skorygowania istniejących niezgodnych zasobów. Upewnij się, że zadania korygowania przenoszą zasoby do zgodności zgodnie z oczekiwaniami.
Powtórz to przez rozwinięcie wartości właściwości selektora zasobów, aby uwzględnić lokalizacje następnego pierścienia i sprawdzić poprawną oczekiwaną zgodność wyników i kondycję aplikacji. Przykładowy selektor z wartością lokalizacji dodanej:
"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS", "westUS"] }] }]
Po pomyślnym przypisaniu zasad do wszystkich pierścieni przy użyciu trybu DoNotEnforce potok powinien wyzwolić zadanie, które zmieni zasady
enforcementMode
na Domyślne włączenie i zresetuj selektory zasobów do lokalizacji skojarzonej z pierścieniem 0. Przykładowy selektor z jednym regionem i efektem ustawionym na odmowę:"resourceSelectors": [{ "name": "SDPRegions", "selectors": [{ "kind": "resourceLocation", "in": [ "eastUS" ] }] }], "enforcementMode": "Default",
Po zmianie efektu zautomatyzowane testy powinny sprawdzić, czy wymuszanie odbywa się zgodnie z oczekiwaniami.
Powtórz, dołączając więcej pierścieni w konfiguracji selektora zasobów.
Powtórz ten proces dla wszystkich pierścieni produkcyjnych.
Procedura bezpiecznego aktualizowania wbudowanej wersji definicji w ramach przypisania usługi Azure Policy
W ramach istniejącego przypisania zastosuj przesłonięcia , aby zaktualizować wersję definicji dla najmniej krytycznego pierścienia. Używamy kombinacji przesłonięć, aby zmienić definicjęVersion i selektory w warunku przesłonięcia, aby zawęzić możliwość stosowania według
"kind": "resource location"
właściwości. Wszystkie zasoby, które znajdują się poza określonymi lokalizacjami, będą nadal oceniane względem wersji z właściwości najwyższegodefinitionVersion
poziomu w przypisaniu. Przykład zastępuje aktualizację wersji definicji2.0.*
i stosuje ją tylko do zasobów w programieEastUs
."overrides":[{ "kind": "definitionVersion", "value": "2.0.*", "selectors": [{ "kind": "resourceLocation", "in": [ "eastus"] }] }]
Po zaktualizowaniu przypisania i zakończeniu początkowego skanowania zgodności sprawdź, czy wynik zgodności jest zgodny z oczekiwaniami.
Należy również skonfigurować testy automatyczne, które uruchamiają testy zgodności. Sprawdzanie zgodności powinno obejmować następującą logikę:
- Zbieranie wyników zgodności
- Jeśli wyniki zgodności są zgodne z oczekiwaniami, potok powinien kontynuować
- Jeśli wyniki zgodności nie są zgodne z oczekiwaniami, potok powinien zakończyć się niepowodzeniem i należy rozpocząć debugowanie
Na przykład można skonfigurować sprawdzanie zgodności przy użyciu innych narzędzi w ramach określonego potoku ciągłej integracji/ciągłego wdrażania (CI/CD).
Na każdym etapie wdrażania kontrola kondycji aplikacji powinna potwierdzić stabilność usługi i wpływ zasad. Jeśli wyniki nie są zgodnie z oczekiwaniami ze względu na konfigurację aplikacji, refaktoryzuj aplikację zgodnie z potrzebami.
Powtórz, rozwijając wartości właściwości selektora zasobów, aby uwzględnić następne pierścienie. lokalizacje i weryfikowanie oczekiwanych wyników zgodności i kondycji aplikacji. Przykład z wartością lokalizacji dodanej:
"overrides":[{ "kind": "definitionVersion", "value": "2.0", "selectors": [{ "kind": "resourceLocation", "in": [ "eastus", "westus"] }] }]
Po pomyślnym dołączeniu wszystkich niezbędnych lokalizacji w _selectors można usunąć przesłonięcie i zaktualizować właściwość definitionVersion w ramach przypisania:
"properties": {
"displayName": "Enforce resource naming rules",
"description": "Force resource names to begin with DeptA and end with -LC",
"definitionVersion": "2.0.*",
}
Następne kroki
- Dowiedz się, jak programowo tworzyć zasady.
- Przejrzyj usługę Azure Policy jako przepływy pracy kodu.
- Zapoznaj się ze wskazówkami firmy Microsoft dotyczącymi bezpiecznych praktyk wdrażania.
- Zapoznaj się z artykułem Korygowanie niezgodnych zasobów za pomocą usługi Azure Policy.