Utforma arbetsflöden för Azure Policy som kod

  • Artikel

När du går vidare med molnstyrningen vill du gå från att manuellt hantera varje principtilldelning i Azure-portalen eller via de olika SDK:erna till något mer hanterbart och repeterbart i företagsskala. Två av de viktigaste metoderna för att hantera system i stor skala i molnet är:

  • Infrastruktur som kod: Metoden att behandla innehållet som definierar dina miljöer, allt från Azure Resource Manager-mallar (ARM-mallar) till Azure Policy-definitioner till Azure Blueprints som källkod.
  • DevOps: En union av personer, processer och produkter som möjliggör kontinuerlig leverans av värde till våra slutanvändare.

Azure Policy as Code är en kombination av dessa idéer. Behåll principdefinitionerna i källkontrollen och testa och verifiera ändringen när en ändring görs. Det bör dock inte vara omfattningen av principer som är inblandade i infrastruktur som Kod eller DevOps.

Valideringssteget bör också vara en komponent i andra CI/CD-arbetsflöden (kontinuerlig integrering eller kontinuerlig distribution), till exempel distribution av en programmiljö eller virtuell infrastruktur. Genom att göra Azure Policy-validering till en tidig komponent i bygg- och distributionsprocessen upptäcker program- och driftteamen om deras ändringar fungerar som förväntat långt innan det är för sent och de försöker distribuera i produktion.

Definitioner och grundläggande information

Innan du går in på information om Azure Policy som kodarbetsflöde är det viktigt att förstå några grundläggande begrepp, till exempel hur du skapar principdefinitioner och initiativdefinitioner och hur du utnyttjar undantag för tilldelningar av dessa definitioner:

Filnamnen motsvarar vissa delar av princip- eller initiativdefinitioner och andra principresurser:

File format Filinnehåll
policy.json Hela principdefinitionen
policyset.json Hela initiativdefinitionen
policy.parameters.json Delen properties.parameters av principdefinitionen
policyset.parameters.json Delen properties.parameters av initiativdefinitionen
policy.rules.json Delen properties.policyRule av principdefinitionen
policyset.definitions.json Delen properties.policyDefinitions av initiativdefinitionen
exemptionName.json Principundantaget som är avsett för en viss resurs eller ett visst omfång

Exempel på dessa filformat finns i GitHub-lagringsplatsen för Azure Policy

Arbetsflödesöversikt

Det rekommenderade allmänna arbetsflödet för Azure Policy as Code ser ut så här diagram:

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

Källkontroll

Befintliga princip- och initiativdefinitioner kan exporteras på olika sätt, till exempel via PowerShell-, CLI- eller Azure Resource Graph-frågor (ARG). Den källkontrollhanteringsmiljö som du väljer för att lagra dessa definitioner kan vara ett av många alternativ, inklusive en GitHub eller Azure DevOps.

Skapa och uppdatera principdefinitioner

Principdefinitionerna skapas med JSON och lagras i källkontrollen. Varje princip har en egen uppsättning filer, till exempel parametrar, regler och miljöparametrar som ska lagras i samma mapp. Följande struktur är ett rekommenderat sätt att hålla dina principdefinitioner i källkontroll.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

När en ny princip läggs till eller en befintlig uppdateras bör arbetsflödet automatiskt uppdatera principdefinitionen i Azure. Testning av den nya eller uppdaterade principdefinitionen kommer i ett senare steg.

Skapa och uppdatera initiativdefinitioner

Initiativdefinitioner skapas också med JSON-filer som ska lagras i samma mapp som principdefinitioner. Initiativdefinitionen kräver att principdefinitionen redan finns, så den kan inte skapas eller uppdateras förrän principens källa har uppdaterats i källkontrollen och sedan uppdaterats i Azure. Följande struktur är ett rekommenderat sätt att hålla initiativdefinitionerna i källkontroll:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Precis som med principdefinitioner bör arbetsflödet automatiskt uppdatera initiativdefinitionen i Azure när ett befintligt initiativ läggs till eller uppdateras. Testning av den nya eller uppdaterade initiativdefinitionen kommer i ett senare steg.

Kommentar

Vi rekommenderar att du använder en central distributionsmekanism som GitHub-arbetsflöden eller Azure Pipelines för att distribuera principer. Detta säkerställer att endast granskade principresurser distribueras till din miljö och att en gradvis och central distributionsmekanism används. Skrivbehörigheter till principresurser kan begränsas till den identitet som används i distributionen.

Testa och verifiera den uppdaterade definitionen

När automatiseringen har tagit dina nyligen skapade eller uppdaterade princip- eller initiativdefinitioner och gjort uppdateringen av objektet i Azure är det dags att testa de ändringar som har gjorts. Antingen principen eller initiativen som den ingår i ska sedan tilldelas till resurser i miljön längst från produktion. Den här miljön är vanligtvis Dev.

Kommentar

I det här steget utför vi integreringstestning av principdefinitionen i din Azure-miljö, detta är skilt från att kontrollera funktionerna i principdefinitionen som ska ske under definitionsskapandeprocessen.

Tilldelningen bör använda enforcementMode av inaktiverad så att resursskapande och uppdateringar inte blockeras, men att befintliga resurser fortfarande granskas för kompatibilitet med den uppdaterade principdefinitionen. Även med enforcementMode rekommenderar vi att tilldelningsomfånget antingen är en resursgrupp eller en prenumeration som är specifikt för validering av principer.

Kommentar

Även om tvingande läge är användbart är det inte en ersättning för att noggrant testa en principdefinition under olika förhållanden. Principdefinitionen bör testas med PUT och PATCH REST API-anrop, kompatibla och icke-kompatibla resurser och gränsfall som en egenskap som saknas i resursen.

När tilldelningen har distribuerats använder du Azure Policy SDK, Azure Pipelines Security and Compliance Assessment-uppgiften eller Arg-frågor (Azure Resource Graph) (se exempel) för att hämta efterlevnadsdata för den nya tilldelningen. Miljön som används för att testa principer och tilldelningar bör ha resurser med varierande efterlevnadstillstånd. Som ett bra enhetstest för kod vill du testa att resurser utvärderas som förväntat utan falska positiva eller falska negativa värden. Om du bara testar och validerar för det du förväntar dig kan det uppstå oväntade och oidentifierade effekter från principen. Mer information finns i Utvärdera effekten av en ny Azure Policy-definition.

Aktivera reparationsåtgärder

Om valideringen av tilldelningen uppfyller förväntningarna är nästa steg att verifiera reparationen. Principer som använder antingen deployIfNotExists eller ändra kan utlösa en associerad reparationsuppgift för att korrigera resurser från ett icke-kompatibelt tillstånd och föra dem i kompatibilitet.

Det första steget för att åtgärda resurser är att bevilja principtilldelningen den rolltilldelning som definierats i principdefinitionen. Den här rolltilldelningen ger den hanterade identiteten för principtilldelning tillräckligt med behörighet för att göra nödvändiga ändringar för att göra resursen kompatibel.

När principtilldelningen har rätt rättigheter använder du Policy SDK för att utlösa en reparationsaktivitet mot en uppsättning resurser som är kända för att vara icke-kompatibla. Tre tester bör utföras mot dessa åtgärdade uppgifter innan du fortsätter:

  • Kontrollera att reparationsuppgiften har slutförts
  • Kör principutvärdering för att se att resultatet av principefterlevnad uppdateras som förväntat
  • Kör ett miljöenhetstest mot resurserna direkt för att verifiera att deras egenskaper har ändrats

Genom att testa både de uppdaterade resultaten av principutvärderingen och miljön får du en direkt bekräftelse på att reparationsuppgifterna ändrade vad som förväntades och att principdefinitionen såg kompatibilitetsändringen som förväntat.

Uppdatera till framtvingade tilldelningar

När alla valideringsgrindar har slutförts uppdaterar du tilldelningen så att enforcementMode av aktiverad används. Vi rekommenderar att du gör den här ändringen från början i samma miljö långt från produktion. Kontrollera att de önskade effekterna tillämpas när resursen skapas och resursuppdateringen. När den miljön har verifierats så att den fungerar som förväntat bör ändringen sedan begränsas till att omfatta nästa miljö och så vidare tills principen distribueras till produktionsresurser.

Bearbeta integrerade utvärderingar

Det allmänna arbetsflödet för Azure Policy as Code är för att utveckla och distribuera principer och initiativ till en miljö i stor skala. Principutvärdering bör dock vara en del av distributionsprocessen för alla arbetsflöden som distribuerar eller skapar resurser i Azure, till exempel att distribuera program eller köra ARM-mallar för att skapa infrastruktur.

I dessa fall, när program- eller infrastrukturdistributionen har slutförts till en testprenumeration eller resursgrupp, bör principutvärdering göras för att kontrollera valideringen av alla befintliga principer och initiativ. Även om de kan konfigureras som enforcementMode inaktiverade i en sådan miljö är det bra att veta tidigt om en program- eller infrastrukturdistribution bryter mot principdefinitionerna tidigt. Den här principutvärderingen bör därför vara ett steg i dessa arbetsflöden och misslyckas med distributioner som skapar icke-kompatibla resurser.

Granska

Den här artikeln beskriver det allmänna arbetsflödet för Azure Policy som kod och även var principutvärdering ska ingå i andra distributionsarbetsflöden. Det här arbetsflödet kan användas i alla miljöer som stöder skriptbaserade steg och automatisering baserat på utlösare.

Nästa steg