Sejf 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 graudalnym wdrażaniu przypisań zasad przez pierścienie w celu wykrywania zmian zasad wpływających na środowisko na wczesnym etapie, 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:

1. 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 jako audit:

   "resourceSelectors": [{ 
     "name": "SDPRegions", 
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ] 
     }]
   }], 
   "overrides":[{ 
     "kind": "policyEffect", 
     "value": "Audit" 
   }] 
   

2. 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.

3. 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"] 
     }]
   }]
   

4. Po pomyślnym przypisaniu zasad do wszystkich pierścieni przy użyciu audit trybu potok powinien wyzwolić zadanie, które zmienia efekt deny 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" 
   }] 
   

5. Po zmianie efektu zautomatyzowane testy powinny sprawdzić, czy wymuszanie odbywa się zgodnie z oczekiwaniami.

6. Powtórz, dołączając więcej pierścieni w konfiguracji selektora zasobów.

7. 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:

1. 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"
   

2. 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.

3. 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"] 
     }]
   }]
   

4. 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",
   

5. Po zmianie efektu zautomatyzowane testy powinny sprawdzić, czy wymuszanie odbywa się zgodnie z oczekiwaniami.

6. Powtórz, dołączając więcej pierścieni w konfiguracji selektora zasobów.

7. Powtórz ten proces dla wszystkich pierścieni produkcyjnych.

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.