Delen via

Azure Policy ontwerpen als code-werkstromen

  • Artikel

Wanneer u verdergaat met cloudgovernance, wilt u overstappen van het handmatig beheren van elke beleidstoewijzing in Azure Portal of via de verschillende SDK's naar iets beheerbaarder en herhaalbaarder op ondernemingsniveau. Twee van de belangrijkste benaderingen voor het beheren van systemen op schaal in de cloud zijn:

  • Infrastructuur als code: de praktijk van het behandelen van de inhoud die uw omgevingen definieert, alles van Azure Resource Manager-sjablonen (ARM-sjablonen) tot Azure Policy-definities tot Azure Blueprints, als broncode.
  • DevOps: De samenvoeging van mensen, processen en producten om continue levering van waarde aan onze eindgebruikers mogelijk te maken.

Azure Policy als code is de combinatie van deze ideeën. Bewaar in wezen uw beleidsdefinities in broncodebeheer en wanneer een wijziging wordt aangebracht, test en valideer deze wijziging. Dit mag echter niet de omvang zijn van de betrokkenheid van het beleid bij Infrastructure as Code of DevOps.

De validatiestap moet ook een onderdeel zijn van andere CI/CD-werkstromen (continue integratie of continue implementatie), zoals het implementeren van een toepassingsomgeving of virtuele infrastructuur. Door Azure Policy-validatie een vroeg onderdeel van het build- en implementatieproces te maken, ontdekken de toepassings- en operationele teams of hun wijzigingen zich gedragen zoals verwacht lang voordat het te laat is en ze proberen te implementeren in productie.

Definities en basisinformatie

Voordat u aan de slag gaat met de details van Azure Policy als codewerkstroom, is het belangrijk om een aantal fundamentele concepten te begrijpen, zoals het ontwerpen van beleidsdefinities en initiatiefdefinities en het gebruik van uitzonderingen voor toewijzingen van deze definities:

De bestandsnamen komen overeen met bepaalde delen van beleids- of initiatiefdefinities en andere beleidsbronnen:

File format Bestandsinhoud
policy-v#.json De volledige beleidsdefinitie voor die versie
policyset-v#.json De volledige initiatiefdefinitie voor die versie
policy-v#.parameters.json Het properties.parameters gedeelte van de beleidsdefinitie
policyset-v#.parameters.json Het properties.parameters gedeelte van de initiatiefdefinitie
policy-v#.rules.json Het properties.policyRule gedeelte van de beleidsdefinitie
policyset-v#.definitions.json Het properties.policyDefinitions gedeelte van de initiatiefdefinitie
exemptionName.json De beleidsvrijstelling die is gericht op een bepaalde resource of een bepaald bereik

Werkstroomoverzicht

De aanbevolen algemene werkstroom van Azure Policy als Code ziet er als volgt uit:

Diagram van Azure Policy als codewerkstroomvakken van Maken naar Testen om te implementeren.

Bronbeheer

Bestaande beleids- en initiatiefdefinities kunnen op verschillende manieren worden geëxporteerd , zoals via PowerShell-, CLI- of Arg-query's (Azure Resource Graph). De beheeromgeving voor broncodebeheer die u kunt kiezen om deze definities op te slaan, kan een van de vele opties zijn, waaronder een GitHub of Azure DevOps.

Beleidsdefinities maken en bijwerken

De beleidsdefinities worden gemaakt met behulp van JSON en opgeslagen in broncodebeheer. Elk beleid heeft een eigen set bestanden, zoals de parameters, regels en omgevingsparameters die moeten worden opgeslagen in dezelfde map. De volgende structuur is een aanbevolen manier om uw beleidsdefinities in broncodebeheer te houden.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.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
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.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
|

Wanneer een nieuw beleid of een nieuwe versie wordt toegevoegd of een bestaande versie wordt bijgewerkt, moet de werkstroom de beleidsdefinitie in Azure automatisch bijwerken. Het testen van de nieuwe of bijgewerkte beleidsdefinitie wordt in een latere stap uitgevoerd.

Initiatiefdefinities maken en bijwerken

Initiatiefdefinities worden ook gemaakt met behulp van JSON-bestanden die moeten worden opgeslagen in dezelfde map als beleidsdefinities. De initiatiefdefinitie vereist dat de beleidsdefinitie al bestaat, zodat deze pas kan worden gemaakt of bijgewerkt als de bron voor het beleid is bijgewerkt in broncodebeheer en vervolgens wordt bijgewerkt in Azure. De volgende structuur is een aanbevolen manier om uw initiatiefdefinities in broncodebeheer te houden:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of 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
|     |- versions ____________________ # Subfolder for versions of 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
|

Net als bij beleidsdefinities moet de werkstroom de initiatiefdefinitie in Azure automatisch bijwerken wanneer een bestaand initiatief wordt toegevoegd of bijgewerkt. Het testen van de nieuwe of bijgewerkte initiatiefdefinitie wordt in een latere stap uitgevoerd.

Notitie

Het is raadzaam om een gecentraliseerd implementatiemechanisme te gebruiken, zoals GitHub-werkstromen of Azure Pipelines om beleid te implementeren. Dit helpt ervoor te zorgen dat alleen gecontroleerde beleidsbronnen in uw omgeving worden geïmplementeerd en dat er een geleidelijk en centraal implementatiemechanisme wordt gebruikt. Schrijfmachtigingen voor beleidsbronnen kunnen worden beperkt tot de identiteit die in de implementatie wordt gebruikt.

De bijgewerkte definitie testen en valideren

Zodra de automatisering uw zojuist gemaakte of bijgewerkte beleids- of initiatiefdefinities heeft gemaakt en de update naar het object in Azure heeft aangebracht, is het tijd om de aangebrachte wijzigingen te testen. Het beleid of de initiatief(en) waarvan het deel uitmaakt, moet vervolgens worden toegewezen aan resources in de omgeving die het meest van productie is. Deze omgeving is doorgaans Dev.

Notitie

In deze stap voeren we integratietests uit van de beleidsdefinitie in uw Azure-omgeving. Dit is los van het verfyen van de functionaliteit van de beleidsdefinitie die moet plaatsvinden tijdens het maken van de definitie.

De toewijzing moet afdwingingsmodus van uitgeschakeld gebruiken, zodat het maken en bijwerken van resources niet wordt geblokkeerd, maar dat bestaande resources nog steeds worden gecontroleerd op naleving van de bijgewerkte beleidsdefinitie. Zelfs met enforcementMode wordt aanbevolen dat het toewijzingsbereik een resourcegroep of een abonnement is dat specifiek is voor het valideren van beleid.

Notitie

Hoewel de afdwingingsmodus nuttig is, is het geen vervanging voor het grondig testen van een beleidsdefinitie onder verschillende omstandigheden. De beleidsdefinitie moet worden getest met PUT en PATCH REST API-aanroepen, compatibele en niet-compatibele resources en edge-gevallen, zoals een eigenschap die ontbreekt in de resource.

Nadat de toewijzing is geïmplementeerd, gebruikt u de Azure Policy SDK, de azure Pipelines Security and Compliance Assessment-taak of ARG-query's (Azure Resource Graph) (zie voorbeelden) om nalevingsgegevens voor de nieuwe toewijzing op te halen. De omgeving die wordt gebruikt om het beleid en de toewijzingen te testen, moeten resources met verschillende nalevingsstatussen hebben. Net als een goede eenheidstest voor code, wilt u testen of resources worden geëvalueerd zoals verwacht zonder fout-positieven of fout-negatieven. Als u alleen test en valideert voor wat u verwacht, is er mogelijk onverwachte en niet-geïdentificeerde impact van het beleid. Zie De impact van een nieuwe Azure Policy-definitie evalueren voor meer informatie.

Hersteltaken inschakelen

Als de validatie van de toewijzing voldoet aan de verwachtingen, is de volgende stap het valideren van herstel. Beleidsregels die deployIfNotExists of wijzigen gebruiken, kunnen een gekoppelde hersteltaak hebben geactiveerd om resources van een niet-compatibele status te corrigeren en deze in overeenstemming te brengen.

De eerste stap voor het herstellen van resources is het verlenen van de beleidstoewijzing aan de roltoewijzing die is gedefinieerd in de beleidsdefinitie. Deze roltoewijzing geeft de beheerde identiteit van de beleidstoewijzing voldoende rechten om de benodigde wijzigingen aan te brengen om de resource compatibel te maken.

Zodra de beleidstoewijzing over de juiste rechten beschikt, gebruikt u de Beleids-SDK om een hersteltaak te activeren voor een set resources waarvan bekend is dat ze niet-compatibel zijn. Er moeten drie tests worden uitgevoerd voor deze herstelde taken voordat u doorgaat:

  • Controleer of de hersteltaak is voltooid
  • Beleidsevaluatie uitvoeren om te zien dat beleidsnalevingsresultaten worden bijgewerkt zoals verwacht
  • Een test van een omgevingseenheid uitvoeren op basis van de resources om te controleren of de eigenschappen zijn gewijzigd

Het testen van zowel de bijgewerkte resultaten van de beleidsevaluatie als de omgeving geeft rechtstreeks een bevestiging dat de hersteltaken zijn gewijzigd wat er werd verwacht en dat de beleidsdefinitie de nalevingswijziging zag zoals verwacht.

Bijwerken naar afgedwongen toewijzingen

Nadat alle validatiepoorten zijn voltooid, werkt u de toewijzing bij om afdwingingsmodus van ingeschakeld te gebruiken. Het is raadzaam om deze wijziging in eerste instantie in dezelfde omgeving te maken, ver van productie. Controleer of de gewenste effecten worden toegepast tijdens het maken van resources en het bijwerken van resources. Zodra die omgeving is gevalideerd zoals verwacht, moet de wijziging worden beperkt tot de volgende omgeving, enzovoort, totdat het beleid is geïmplementeerd in productiebronnen.

Geïntegreerde evaluaties verwerken

De algemene werkstroom voor Azure Policy als code is voor het ontwikkelen en implementeren van beleid en initiatieven in een omgeving op schaal. Beleidsevaluatie moet echter deel uitmaken van het implementatieproces voor elke werkstroom die resources implementeert of maakt in Azure, zoals het implementeren van toepassingen of het uitvoeren van ARM-sjablonen om een infrastructuur te maken.

In deze gevallen moet, nadat de implementatie van de toepassing of infrastructuur is uitgevoerd voor een testabonnement of resourcegroep, beleidsevaluatie worden uitgevoerd voor die scopecontrolevalidatie van alle bestaande beleidsregels en initiatieven. Hoewel ze kunnen worden geconfigureerd als enforcementMode uitgeschakeld in een dergelijke omgeving, is het handig om vroeg te weten of een toepassing of infrastructuurimplementatie in strijd is met beleidsdefinities. Deze beleidsevaluatie moet daarom een stap in deze werkstromen zijn en mislukte implementaties die niet-compatibele resources maken.

Beoordelen

In dit artikel wordt de algemene werkstroom voor Azure Policy behandeld als code en ook waar beleidsevaluatie deel moet uitmaken van andere implementatiewerkstromen. Deze werkstroom kan worden gebruikt in elke omgeving die ondersteuning biedt voor scriptstappen en automatisering op basis van triggers.

Volgende stappen