Utforma arbetsflöden för Azure Policy som kod

  • Artikel
  • 7 minuter för att läsa

När du går vidare med molnstyrning bör du övergå från att manuellt hantera varje principdefinition i Azure Portal eller via olika SDK:er till något mer hanterbart och repeterbart i företagsskala. Två av de dominerande metoderna för att hantera system i stor skala i molnet är:

  • Infrastruktur som kod: Metoder för att behandla det innehåll 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 människor, processer och produkter för att möjliggöra kontinuerlig leverans av värde till våra slutanvändare.

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

Valideringssteget bör också vara en komponent i andra arbetsflöden för kontinuerlig integrering eller kontinuerlig distribution. Exempel är distribution av en programmiljö eller virtuell infrastruktur. Genom att Azure Policy en tidig komponent i bygg- och distributionsprocessen upptäcker program- och driftteamen om deras ändringar är icke-kompatibla, 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å Azure Policy som kodarbetsflöde granskar du följande definitioner och exempel:

Filnamnen justeras till delar av principen eller initiativdefinitionen:

  • policy(set).json – Hela definitionen
  • policy(set).parameters.json – properties.parameters Delen av definitionen
  • policy.rules.json – properties.policyRule Delen av definitionen
  • policyset.definitions.json – properties.policyDefinitions Delen av definitionen

Exempel på dessa filformat finns på lagringsplatsen Azure Policy GitHub:

Arbetsflödesöversikt

Det rekommenderade allmänna arbetsflödet för Azure Policy som Code ser ut som i det här diagrammet:

Diagram som Azure Policy som kodarbetsflödesrutor från Skapa till Testa till Distribuera.

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 behålla principdefinitionerna i källkontrollen.

.
|
|- 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
|  |- 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
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|

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.

Granska också Exportera Azure Policy resurser för att hämta dina befintliga definitioner och tilldelningar till källkodshanteringsmiljön GitHub.

Skapa och uppdatera initiativdefinitioner

På samma sätt har initiativ sin egen JSON-fil och relaterade filer som ska lagras i samma mapp. Initiativdefinitionen kräver att principdefinitionen redan finns, så den kan inte skapas eller uppdateras förrän källan för principen har uppdaterats i källkontrollen och sedan uppdaterats i Azure. Följande struktur är ett rekommenderat sätt att behålla initiativdefinitionerna i källkontrollen:

.
|
|- 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
|
|  |- 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
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|

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

Testa och verifiera den uppdaterade definitionen

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

Tilldelningen bör använda enforcementMode för 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.

Anteckning

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

När tilldelningen har distribuerats använder du uppgiften Azure Policy SDK, Azure Policy Compliance Scan GitHub Actioneller Azure Pipelines Security and Compliance Assessment för att hämta efterlevnadsdata för den nya tilldelningen. Miljön som används för att testa principerna och tilldelningarna bör ha både kompatibla och icke-kompatibla resurser. Precis som ett bra enhetstest för kod vill du testa att resurserna är som förväntat och att du inte heller har några falska positiva eller falska negativa resultat. Om du bara testar och validerar för det du förväntar dig kan det uppstå oväntade och oidentifierade effekter av 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 modify kan omvandlas till en reparationsuppgift och korrigera resurser från ett icke-kompatibelt tillstånd.

Det första steget för att åtgärda resurser är att bevilja principtilldelningen rolltilldelningen som definierats i principdefinitionen. Den här rolltilldelningen ger den hanterade identiteten för principtilldelning tillräcklig behörighet för att göra de ändringar som krävs 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ärder innan du fortsätter:

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

Testning av både det uppdaterade resultatet av principutvärderingen och miljön ger en direkt bekräftelse på att reparationsaktiviteterna ändrade vad som förväntades och att principdefinitionen såg efterlevnadsändringen som förväntat.

Uppdatera till framtvingade tilldelningar

När alla verifieringsgrindar har slutförts uppdaterar du tilldelningen för att använda enforcementMode för aktiverad. Vi rekommenderar att du gör den här ändringen från början i samma miljö långt från produktion. När miljön har verifierats som fungerar som förväntat bör ändringen 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 som kod ä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 distribuera program eller köra ARM-mallar för att skapa infrastruktur.

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

Genomgång

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. En självstudie om hur du använder det här arbetsflödet på GitHub finns i Självstudie: Implementera Azure Policy som kod med GitHub.

Nästa steg