Podstawy efektu definicji usługi Azure Policy

  • Artykuł

Każda definicja zasad w usłudze Azure Policy ma pojedynczą effect definicję w elemecie policyRule. Określa to effect , co się stanie, gdy reguła zasad zostanie obliczona zgodnie z oczekiwaniami. Efekty zachowują się inaczej, jeśli dotyczą nowego zasobu, zaktualizowanego zasobu lub istniejącego zasobu.

Poniżej przedstawiono obsługiwane efekty definicji usługi Azure Policy:

Interchanging efekty

Czasami wiele efektów może być prawidłowych dla danej definicji zasad. Parametry są często używane do określania dozwolonych wartości efektów (allowedValues), dzięki czemu pojedyncza definicja może być bardziej wszechstronna podczas przypisywania. Należy jednak pamiętać, że nie wszystkie efekty są zamienne. Właściwości zasobów i logika w regule zasad mogą określić, czy określony efekt jest uznawany za prawidłowy dla definicji zasad. Na przykład definicje zasad z efektem auditIfNotExists wymagają innych szczegółów w regule zasad, które nie są wymagane dla zasad z efektem audit. Efekty zachowują się również inaczej. audit zasady oceniają zgodność zasobu na podstawie własnych właściwości, a auditIfNotExists zasady oceniają zgodność zasobu na podstawie właściwości zasobu podrzędnego lub rozszerzenia.

Poniższa lista zawiera ogólne wskazówki dotyczące efektów wymiennych:

  • audit, denyi modify albo lub append są często wymienne.
  • auditIfNotExists i deployIfNotExists są często wymienne.
  • manual nie jest wymienna.
  • disabled jest zamienny z każdym skutkiem.

Kolejność obliczania

Pierwsza ocena usługi Azure Policy dotyczy żądań utworzenia lub zaktualizowania zasobu. Usługa Azure Policy tworzy listę wszystkich przydziałów, które mają zastosowanie do zasobu, a następnie zasób jest oceniany względem każdej definicji. W przypadku trybu usługi Resource Manager usługa Azure Policy przetwarza kilka efektów przed przekazaniem żądania do odpowiedniego dostawcy zasobów. Ta kolejność uniemożliwia niepotrzebne przetwarzanie przez dostawcę zasobów, gdy zasób nie spełnia zaprojektowanych mechanizmów kontroli ładu usługi Azure Policy. W trybie dostawcy zasobów dostawca zasobów zarządza oceną i wynikiem oraz raportuje wyniki z powrotem do usługi Azure Policy.

  • disabled jest sprawdzany jako pierwszy, aby określić, czy reguła zasad powinna być oceniana.
  • append a modify następnie są oceniane. Ponieważ można zmienić żądanie, zmiana wprowadzona może uniemożliwić wyzwolenie efektu inspekcji lub odmowy. Te efekty są dostępne tylko w trybie Resource Manager.
  • deny następnie jest obliczany. Ocena odmowy przed inspekcją zapobiega podwójnemu rejestrowaniu niepożądanego zasobu.
  • audit wartość jest obliczana.
  • manual wartość jest obliczana.
  • auditIfNotExists wartość jest obliczana.
  • denyAction wartość jest obliczana jako ostatnia.

Gdy dostawca zasobów zwróci kod powodzenia w żądaniu auditIfNotExists trybu usługi Resource Manager i deployIfNotExists oceni, czy jest wymagane więcej rejestrowania zgodności, czy akcji.

PATCH żądania, które modyfikują tags tylko powiązane pola, ograniczają ocenę zasad do zasad zawierających warunki, które sprawdzają tags powiązane pola.

Definicje zasad warstwowania

Kilka przypisań może mieć wpływ na zasób. Te przypisania mogą być w tym samym zakresie lub w różnych zakresach. Każde z tych przypisań może również mieć inny efekt. Warunek i efekt dla każdej zasady są oceniane niezależnie. Na przykład:

  • Zasady 1
    • Ogranicza lokalizację zasobu do westus
    • Przypisano do subskrypcji A
    • Efekt odmowy
  • Zasady 2
    • Ogranicza lokalizację zasobu do eastus
    • Przypisane do grupy zasobów B w subskrypcji A
    • Efekt inspekcji

Taka konfiguracja spowoduje następujący wynik:

  • Każdy zasób już w grupie zasobów B w eastus systemie jest zgodny z zasadami 2 i niezgodny z zasadami 1
  • Każdy zasób już w grupie zasobów B nie jest eastus zgodny z zasadami 2 i niezgodny z zasadami 1, jeśli nie westus
  • Zasady 1 odrzucają nowy zasób w subskrypcji A nie w westus
  • Każdy nowy zasób w subskrypcji A i grupie zasobów B w westus programie jest tworzony i niezgodny w zasadach 2

Jeśli obie zasady 1 i zasady 2 miały wpływ na odmowę, sytuacja zmieni się na:

  • Dowolny zasób już w grupie zasobów B nie jest eastus zgodny z zasadami 2
  • Dowolny zasób już w grupie zasobów B nie jest westus zgodny z zasadami 1
  • Zasady 1 odrzucają nowy zasób w subskrypcji A nie w westus
  • Każdy nowy zasób w grupie zasobów B subskrypcji A jest odrzucany

Każde przypisanie jest oceniane indywidualnie. W związku z tym nie ma okazji, aby zasób prześlizgnął się przez lukę z różnic w zakresie. Wynik netto definicji zasad warstwowych jest uważany za skumulowany najbardziej restrykcyjny. Na przykład jeśli zasady 1 i 2 miały deny wpływ, zasób zostanie zablokowany przez nakładające się i powodujące konflikt definicje zasad. Jeśli nadal potrzebujesz zasobu do utworzenia w zakresie docelowym, przejrzyj wykluczenia dla każdego przypisania, aby sprawdzić, czy odpowiednie przypisania zasad mają wpływ na odpowiednie zakresy.

Następne kroki