Metoda testowania dla stref docelowych platformy Azure
Uwaga
Ten artykuł dotyczy tylko platformy Microsoft Azure, a nie innych ofert w chmurze firmy Microsoft, takich jak Microsoft 365 lub Microsoft Dynamics 365.
Niektóre organizacje mogą chcieć przetestować wdrożenie platformy stref docelowych platformy Azure dla definicji i przypisań usługi Azure Policy, ról i przypisań niestandardowych kontroli dostępu na podstawie ról (RBAC). Testy można wykonać za pomocą automatyzacji przy użyciu szablonów usługi Azure Resource Manager (szablonów usługi ARM), azOps, terraform, Bicep lub ręcznie za pośrednictwem witryny Azure Portal. Te wskazówki zawierają podejście, które może służyć do testowania zmian i ich wpływu na wdrożenie platformy stref docelowych platformy Azure.
Ten artykuł może być również używany ze wskazówkami dotyczącymi automatyzacji platformy i krytycznym obszarem projektowania metodyki DevOps w odniesieniu do zespołów i zadań związanych z funkcjami platformy i centralną.
Te wskazówki są najbardziej odpowiednie dla organizacji z niezawodnymi procesami zarządzania zmianami zarządzającymi zmianami w hierarchii grup zarządzania środowiska produkcyjnego. Hierarchia grup zarządzania kanarką może być używana niezależnie do tworzenia i testowania wdrożeń przed ich wdrożeniem w środowisku produkcyjnym.
Uwaga
Termin canary służy do unikania nieporozumień w środowiskach deweloperskich lub środowiskach testowych. Ta nazwa jest używana tylko do celów ilustracyjnych. Możesz zdefiniować dowolną nazwę uważaną za odpowiednią dla środowiska stref docelowych platformy Azure.
Podobnie termin środowisko produkcyjne jest używane w ramach tych wskazówek, aby odwoływać się do hierarchii grup zarządzania, które organizacja może mieć w miejscu, który zawiera subskrypcje i zasoby platformy Azure dla obciążeń.
Definicja platformy
Ważne
Te wskazówki nie dotyczą środowisk deweloperskich ani środowisk testowych, które będą używane przez właścicieli aplikacji lub usług nazywanych strefami docelowymi, obciążeniami, aplikacjami lub usługami. Są one umieszczane i obsługiwane w hierarchii grupy zarządzania środowiska produkcyjnego i skojarzonego ładu (RBAC i Azure Policy).
Te wskazówki dotyczą tylko testowania na poziomie platformy i zmian w kontekście stref docelowych platformy Azure.
Skala przedsiębiorstwa ułatwia projektowanie i wdrażanie wymaganych składników platformy Azure w celu umożliwienia konstruowania i operacjonalizacji stref docelowych na dużą skalę.
Zasoby platformy w zakresie tego artykułu i to podejście do testowania są następujące:
| Produkt lub usługa | Dostawca zasobów i typ |
|---|---|
| Grupy zarządzania | Microsoft.Management/managementGroups |
| Skojarzenie subskrypcji grup zarządzania | Microsoft.Management/managementGroups/subscriptions |
| Definicje zasad | Microsoft.Authorization/policyDefinitions |
| Definicje inicjatywy zasad lub definicje zestawu zasad | Microsoft.Authorization/policySetDefinitions |
| Przypisania zasad | Microsoft.Authorization/policyAssignments |
| Definicje ról RBAC | Microsoft.Authorization/roleDefinitions |
| Przypisania ról RBAC | Microsoft.Authorization/roleAssignments |
| Subskrypcje | Microsoft.Subscription/aliases |
Przykładowe scenariusze i wyniki
Przykładem tego scenariusza jest organizacja, która chce przetestować wpływ i wynik nowej usługi Azure Policy w celu zarządzania zasobami i ustawieniami we wszystkich strefach docelowych zgodnie z zasadą projektowania ładu opartego na zasadach. Nie chcą wprowadzać tej zmiany bezpośrednio w środowisku produkcyjnym, ponieważ obawiają się wpływu, jaki może mieć.
Testowanie tej zmiany platformy przy użyciu środowiska kanarowego umożliwi organizacji zaimplementowanie i przejrzenie wpływu i wyniku zmiany usługi Azure Policy. Ten proces zapewni spełnienie wymagań organizacji przed wdrożeniem usługi Azure Policy w środowisku produkcyjnym.
Podobny scenariusz może być zmianą przypisań ról RBAC platformy Azure i członkostwa w grupach firmy Microsoft Entra. Może to wymagać formy testowania przed wprowadzeniem zmian w środowisku produkcyjnym.
Ważne
Nie jest to typowe podejście lub wzorzec wdrażania dla większości klientów. Nie jest to obowiązkowe w przypadku wdrożeń stref docelowych platformy Azure.
Rysunek 1. Hierarchia grup zarządzania Kanary.
Jak pokazano na diagramie, cała hierarchia grup zarządzania środowiska produkcyjnego platformy Azure jest duplikowana w obszarze Tenant Root Group. Nazwa kanary jest dołączana do nazw wyświetlanych i identyfikatorów grupy zarządzania. Identyfikatory muszą być unikatowe w ramach jednej dzierżawy firmy Microsoft Entra.
Uwaga
Nazwy wyświetlane grupy zarządzania środowiska kanarowego mogą być takie same jak nazwy wyświetlane grupy zarządzania środowiska produkcyjnego. Może to spowodować zamieszanie dla użytkowników. W związku z tym zalecamy dołączenie nazwy "kanary" do nazw wyświetlanych, a także do ich identyfikatorów.
Hierarchia grup zarządzania środowiska kanarowego jest następnie używana do upraszczania testowania następujących typów zasobów:
- Grupy zarządzania
- Umieszczanie subskrypcji
- RBAC
- Role (wbudowane i niestandardowe)
- Przypisania
- Azure Policy
- Definicje (wbudowane i niestandardowe)
- Inicjatywy, znane również jako definicje zestawów
- Przypisania
Co zrobić, jeśli nie chcesz wdrażać całej hierarchii grup zarządzania środowiska kanarnego?
Jeśli nie chcesz wdrażać całej hierarchii grup zarządzania środowiska kanarnego, możesz przetestować zasoby platformy w hierarchii środowiska produkcyjnego przy użyciu subskrypcji piaskownicy , jak pokazano na diagramie.
Rysunek 2. Hierarchia grup zarządzania w skali przedsiębiorstwa z wyróżnionymi piaskownicami.
Aby przetestować usługę Azure Policy i kontrolę dostępu opartą na rolach w tym scenariuszu, potrzebujesz jednej subskrypcji platformy Azure z rolą RBAC właściciela przypisaną do tożsamości, którą chcesz ukończyć testowanie, na przykład konto użytkownika, jednostkę usługi lub tożsamość usługi zarządzanej. Ta konfiguracja umożliwia tworzenie, przypisywanie i korygowanie definicji i przypisań usługi Azure Policy tylko w zakresie subskrypcji piaskownicy.
To podejście piaskownicy może być również używane do testowania kontroli dostępu opartej na rolach w ramach subskrypcji, na przykład jeśli tworzysz nową niestandardową rolę RBAC w celu udzielenia uprawnień dla określonego przypadku użycia. Te testy można wykonać w ramach subskrypcji piaskownicy i przetestować przed utworzeniem i przypisaniem ról wyższych w hierarchii.
Zaletą tego podejścia jest to, że subskrypcje piaskownicy mogą być używane przez czas wymagany, a następnie usuwane ze środowiska.
Jednak takie podejście nie umożliwia testowania przy użyciu dziedziczenia kontroli dostępu opartej na rolach i zasad platformy Azure z hierarchii grup zarządzania.
Korzystanie z jednej dzierżawy firmy Microsoft Entra
Podczas korzystania z jednej dzierżawy firmy Microsoft Entra należy wziąć pod uwagę następujące zagadnienia:
- Jest zgodny z zaleceniami dotyczącymi projektowania w skali przedsiębiorstwa dla dzierżaw firmy Microsoft Entra.
- Zgodnie z najlepszymi rozwiązaniami dotyczącymi platformy Azure w przewodniku Cloud Adoption Framework, standaryzacja w ramach jednego katalogu i wskazówek dotyczących tożsamości jest najlepszym rozwiązaniem dla większości.
- W jednej dzierżawie firmy Microsoft Entra można używać różnych grup firmy Microsoft Entra zarówno dla środowisk produkcyjnych, jak i środowisk stref docelowych platformy Azure, z tymi samymi użytkownikami przypisanymi do odpowiedniej hierarchii grup zarządzania w ramach tej samej dzierżawy firmy Microsoft Entra.
- Zwiększone lub zduplikowane koszty licencjonowania identyfikatora Entra firmy Microsoft ze względu na wiele tożsamości w różnych dzierżawach firmy Microsoft Entra.
- Jest to szczególnie istotne dla klientów korzystających z funkcji Microsoft Entra ID P1 lub P2.
- Zmiany kontroli dostępu opartej na rolach będą bardziej złożone zarówno w środowiskach kanarskich, jak i w środowiskach produkcyjnych, ponieważ prawdopodobnie użytkownicy i grupy nie są identyczne w obu dzierżawach firmy Microsoft Entra.
- Ponadto identyfikatory użytkowników i grup nie będą takie same w dzierżawach firmy Microsoft Entra, ponieważ są one globalnie unikatowe.
- Zmniejsza złożoność i nakład pracy związany z zarządzaniem wieloma dzierżawami firmy Microsoft Entra.
- Uprzywilejowani użytkownicy, którzy muszą zachować dostęp i zalogować się do oddzielnych dzierżaw w celu przeprowadzenia testów, mogą przypadkowo wprowadzić zmiany w środowisku produkcyjnym, zamiast wprowadzać zmiany w środowisku kanarowym i na odwrót.
- Zmniejsza prawdopodobieństwo dryfu konfiguracji i niepowodzeń wdrażania.
- Nie wymaga utworzenia dodatkowych procesów zabezpieczeń ani break-glass ani awaryjnego dostępu.
- Zmniejsza tarcie i czas wymagany do wdrożenia zmian w strefach docelowych platformy Azure.
Wskazówki dotyczące implementacji
Poniżej przedstawiono wskazówki dotyczące implementowania hierarchii grup zarządzania kanarką i korzystania z niej dla stref docelowych platformy Azure wraz z hierarchią grupy zarządzania środowiska produkcyjnego.
Ostrzeżenie
Jeśli obecnie używasz portalu do wdrażania środowiska stref docelowych platformy Azure i zarządzania nimi, wdrożenie i wykorzystanie kanarowego podejścia może być trudne ze względu na wysokie ryzyko zarówno środowiska produkcyjnego, jak i kanarowego częstego przeprowadzania synchronizacji, a tym samym nie zapewniania hierarchii podobnej do repliki i środowiska produkcyjnego.
Rozważ przejście do podejścia do wdrażania infrastruktury jako kodu dla stref docelowych platformy Azure, jak pokazano powyżej, jeśli jesteś w tym scenariuszu. Możesz też pamiętać o potencjalnych zagrożeniach związanych z dryfem konfiguracji między kanarkiem a produkcją i zachować ostrożność.
- Użyj oddzielnych jednostek usługi Firmy Microsoft (SPN) lub tożsamości usługi zarządzanej (MSI), które mają przyznane uprawnienia do odpowiedniego środowiska produkcyjnego lub hierarchii grup zarządzania środowiska kanarnego.
- Te wskazówki są zgodne z zasadą najniższych uprawnień (PoLP)
- Użyj oddzielnych folderów w repozytorium git, gałęziach lub repozytoriach do przechowywania infrastruktury jako kodu dla środowiska produkcyjnego i środowisk kanarowych wdrożeń stref docelowych platformy Azure.
- Używanie odpowiednich jednostek usługi Microsoft Entra (SPN) lub tożsamości usługi zarządzanej (MSI) w ramach potoków ciągłej integracji/ciągłego wdrażania w zależności od tego, która hierarchia jest wdrażana.
- Zaimplementuj zasady gałęzi git lub zabezpieczenia dla środowiska kanarowego, tak jak w środowisku produkcyjnym.
- Rozważ zmniejszenie liczby osób zatwierdzających i sprawdzenie, czy środowisko kanarowe działa szybko.
- Użyj tych samych akcji usługi Azure Pipelines lub GitHub, które używają zmiennych środowiskowych, aby zmienić, która hierarchia jest wdrażana. Inną opcją jest sklonowanie potoków i zmianę zakodowanych ustawień w celu zdefiniowania, która hierarchia jest wdrażana.
- Korzystanie z szablonów devOps usługi Azure Pipelines lub szablonów przepływów pracy funkcji GitHub Actions pomoże Ci zachować zgodność z zasadą "nie powtarzaj się" (DRY).
- Mieć zestaw subskrypcji kanarowych w ramach oddzielnego działu UMOWY EA i konta, które można przenosić wokół hierarchii grup zarządzania kanary zgodnie z potrzebami.
- Korzystne może być, aby zestaw zasobów zawsze był wdrażany w subskrypcjach środowiska kanarkowego.
- Przydatne może być posiadanie szablonów infrastruktury jako kodu, takich jak szablony usługi ARM, Bicep lub Terraform, które tworzą zestaw zasobów, które umożliwiają walidację zmian w środowisku kanargu.
- Wyślij wszystkie dzienniki aktywności platformy Azure dla wszystkich subskrypcji platformy Azure, w tym wszystkich subskrypcji środowiska kanarkowego, do obszaru roboczego usługi Azure Log Analytics w środowisku produkcyjnym zgodnie z zaleceniami projektowymi stref docelowych platformy Azure.
Napiwek
Jeśli masz już strefy docelowe platformy Azure wdrożone w środowisku produkcyjnym i chcesz teraz dodać środowisko kanary. Rozważ sklonowanie bieżącego wdrożenia hierarchii środowiska produkcyjnego i zmianę nazw zasobów w celu ich prefiksu za pomocą schematu nazw kanarków.
Ma to na celu upewnienie się, że wdrażane środowisko w celu włączenia środowiska kanarowego jest zsynchronizowane z produkcją od samego początku. Jest to łatwe w przypadku korzystania z narzędzia infrastruktura jako kod wraz z repozytorium git.
Następne kroki
Dowiedz się, jak zaimplementować środowiska piaskownicy strefy docelowej.