Valv distribution av Azure Policy-tilldelningar

När din miljö expanderar ökar även efterfrågan på en kontrollerad pipeline för kontinuerlig distribution (CD) med progressiv exponeringskontroll. Därför rekommenderar Microsoft DevOps-team att följa ramverket för säkra distributionsmetoder (SDP). Säker distribution av Azure Policy-definitioner och tilldelningar hjälper till att begränsa effekten av oavsiktliga beteenden för principresurser.

Den övergripande metoden för att implementera SDP med Azure Policy är att graudally distribuera principtilldelningar per ringar för att identifiera principändringar som påverkar miljön i ett tidigt skede innan det påverkar den kritiska molninfrastrukturen.

Distributionsringar kan ordnas på olika sätt. I den här självstudien delas ringarna upp av olika Azure-regioner med Ring 0 som representerar icke-kritiska platser med låg trafik och Ring 5 som anger de mest kritiska och högsta trafikplatserna.

Steg för säker distribution av Azure Policy-tilldelningar med neka- eller tilläggseffekter

Använd följande flödesschema som referens när vi går igenom hur du tillämpar SDP-ramverket på Azure Policy-tilldelningar som använder deny eller append -principeffekterna.

Kommentar

Mer information om Azure-policyeffekter finns i Förstå hur effekter fungerar.

Stegnummer för flödesschema:

1. När du har valt din principdefinition tilldelar du principen på den högsta nivån, inklusive alla distributionsringar. Använd resursväljare för att begränsa tillämpligheten till den minst kritiska ringen med hjälp "kind": "resource location" av egenskapen . audit Konfigurera effekttypen med hjälp av tilldelnings åsidosättningar. Exempelväljare med eastUS plats och effekt som audit:

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

2. När tilldelningen har distribuerats och den första efterlevnadsgenomsökningen har slutförts kontrollerar du att kompatibilitetsresultatet är som förväntat.

   Du bör också konfigurera automatiserade tester som kör efterlevnadskontroller. En efterlevnadskontroll bör omfatta följande logik:

   • Samla in efterlevnadsresultat
   • Om efterlevnadsresultaten är som förväntat bör pipelinen fortsätta
   • Om kompatibilitetsresultaten inte är som förväntat bör pipelinen misslyckas och du bör börja felsöka

   Du kan till exempel konfigurera efterlevnadskontrollen med hjälp av andra verktyg i din specifika CI/CD-pipeline (kontinuerlig integrering/kontinuerlig distribution).

   Vid varje distributionssteg bör hälsokontrollerna för programmet bekräfta tjänstens stabilitet och effekten av principen. Om resultatet inte är som förväntat på grund av programkonfigurationen omstrukturerar du programmet efter behov.

3. Upprepa genom att expandera egenskapsvärdena för resursväljaren så att de innehåller nästa ringar. platser och validera förväntade efterlevnadsresultat och programhälsa. Exempelväljare med ett extra platsvärde:

   "resourceSelectors": [{ 
     "name": "SDPRegions", 
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS", "westUS"] 
     }]
   }]
   

4. När du har tilldelat principen till alla ringar i läget audit bör pipelinen utlösa en aktivitet som ändrar principeffekten till deny och återställer resursväljarna till den plats som är associerad med Ring 0. Exempelväljare med en region och en effekt inställd på att neka:

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

5. När effekten har ändrats bör automatiserade tester kontrollera om verkställigheten sker som förväntat.

6. Upprepa genom att inkludera fler ringar i konfigurationen av resursväljaren.

7. Upprepa den här processen för alla produktionsringar.

Steg för säker distribution av Azure Policy-tilldelningar med ändra eller distribueraIfNotExists-effekter

Stegen för principer som använder modify eller deployIfNotExists effekter liknar de steg som tidigare beskrivits med den ytterligare åtgärden att använda tvingande läge och utlösa en reparationsaktivitet. Granska följande flödesschema med ändrade steg 5–9:

Stegnummer för flödesschema:

1. När du har valt din principdefinition tilldelar du principen på den högsta nivån, inklusive alla distributionsringar. Använd resursväljare för att begränsa tillämpligheten till den minst kritiska ringen med hjälp "kind": "resource location" av egenskapen . Konfigurera tvingande läge för tilldelningen till DoNotEnforce. Exempelväljare med eastUS plats och enforcementMode som DoNotEnforce:

   "resourceSelectors": [{ 
     "name": "SDPRegions", 
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ] 
     }]
   }], 
   "enforcementMode": "DoNotEnforce"
   

2. När tilldelningen har distribuerats och den första efterlevnadsgenomsökningen har slutförts kontrollerar du att kompatibilitetsresultatet är som förväntat.

   Du bör också konfigurera automatiserade tester som kör efterlevnadskontroller. En efterlevnadskontroll bör omfatta följande logik:

   • Samla in efterlevnadsresultat
   • Om efterlevnadsresultaten är som förväntat bör pipelinen fortsätta
   • Om kompatibilitetsresultaten inte är som förväntat bör pipelinen misslyckas och du bör börja felsöka

   Du kan konfigurera efterlevnadskontrollen med hjälp av andra verktyg i ci/CD-pipelinen (continuous integration/continuous deployment).

   Vid varje distributionssteg bör hälsokontrollerna för programmet bekräfta tjänstens stabilitet och effekten av principen. Om resultatet inte är som förväntat på grund av programkonfigurationen omstrukturerar du programmet efter behov.

   Du kan också utlösa reparationsåtgärder för att åtgärda befintliga icke-kompatibla resurser. Se till att reparationsuppgifterna gör att resurserna efterlevs som förväntat.

3. Upprepa genom att expandera egenskapsvärdena för resursväljaren så att de inkluderar nästa rings platser och verifiera förväntade efterlevnadsresultat och programhälsa. Exempelväljare med ett extra platsvärde:

   "resourceSelectors": [{ 
     "name": "SDPRegions", 
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS", "westUS"] 
     }]
   }]
   

4. När du har tilldelat principen till alla ringar med DoNotEnforce-läge ska pipelinen utlösa en aktivitet som ändrar principen enforcementMode till Standardaktivering och återställer resursväljarna till den plats som är associerad med Ring 0. Exempelväljare med en region och en effekt inställd på att neka:

   "resourceSelectors": [{ 
     "name": "SDPRegions", 
     "selectors": [{
         "kind": "resourceLocation",
         "in": [ "eastUS" ] 
     }]
   }], 
   "enforcementMode": "Default",
   

5. När effekten har ändrats bör automatiserade tester kontrollera om verkställigheten sker som förväntat.

6. Upprepa genom att inkludera fler ringar i konfigurationen av resursväljaren.

7. Upprepa den här processen för alla produktionsringar.

Nästa steg

• Lär dig hur du programmatiskt skapar principer.
• Granska Azure Policy som kodarbetsflöden.
• Studera Microsofts vägledning om säkra distributionsmetoder.
• Läs Åtgärda icke-kompatibla resurser med Azure Policy.