Säker 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 gradvis distribuera principtilldelningar av 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älvstudiekursen delas ringar upp efter 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.

Steg för att på ett säkert sätt uppdatera den inbyggda definitionsversionen i Azure Policy-tilldelning

1. I den befintliga tilldelningen tillämpar du åsidosättningar för att uppdatera versionen av definitionen för den minst kritiska ringen. Vi använder en kombination av åsidosättningar för att ändra definitionVersion och väljare inom åsidosättningsvillkoret för att begränsa tillämpligheten efter "kind": "resource location" egenskap. Alla resurser som ligger utanför de angivna platserna fortsätter att utvärderas mot versionen från egenskapen på den definitionVersion översta nivån i tilldelningen. Exempel åsidosätt uppdatering av definitionens version till 2.0.* och tillämpa den endast på resurser i EastUs.

   "overrides":[{ 
     "kind": "definitionVersion", 
     "value": "2.0.*",
     "selectors": [{
       "kind": "resourceLocation",
       "in": [ "eastus"]
     }]
   }] 
   

2. När tilldelningen har uppdaterats 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. Exempel med ett extra platsvärde:

    "overrides":[{ 
     "kind": "definitionVersion", 
     "value": "2.0",
     "selectors": [{
       "kind": "resourceLocation",
       "in": [ "eastus", "westus"]
     }]
   }] 
   

4. När du har inkluderat alla nödvändiga platser i _selectors kan du ta bort åsidosättningen och uppdatera egenskapen definitionVersion i tilldelningen:

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

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.