Azure Policy ontwerpen als code-werkstromen

  • Artikel
  • 8 minuten om te lezen

Naarmate u verder gaat met cloudgovernance, wilt u van het handmatig beheren van elke beleidsdefinitie in de Azure Portal of via de verschillende SDK's naar iets dat beter beheersbaar en herhaalbaar is op ondernemingsschaal. Twee van de overheersende benaderingen voor het beheren van systemen op schaal in de cloud zijn:

  • Infrastructure as Code: De praktijk van het behandelen van de inhoud die uw omgevingen definieert, van Azure Resource Manager-sjablonen (ARM-sjablonen) tot Azure Policy-definities tot Azure Blueprints, als broncode.
  • DevOps: De union van mensen, processen en producten om continue waardelevering aan onze eindgebruikers mogelijk te maken.

Azure Policy code is de combinatie van deze ideeën. Houd uw beleidsdefinities in broncodebeheer en wanneer er een wijziging wordt aangebracht, test en valideer deze wijziging. Dit mag echter niet de mate van beleidsbetrokkenheid met Infrastructure as Code of DevOps zijn.

De validatiestap moet ook een onderdeel zijn van andere werkstromen voor continue integratie of continue implementatie. Voorbeelden hiervan zijn 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 niet-compatibel zijn, lang voordat het te laat is en ze proberen te implementeren in productie.

Definities en basisinformatie

Lees de volgende definities en voorbeelden voordat u Azure Policy informatie krijgt over de werkstroom voor Azure Policy code:

De bestandsnamen worden uitgelijnd met delen van de beleids- of initiatiefdefinitie:

  • policy(set).json - De volledige definitie
  • policy(set).parameters.json - Het properties.parameters gedeelte van de definitie
  • policy.rules.json - Het properties.policyRule gedeelte van de definitie
  • policyset.definitions.json - Het properties.policyDefinitions gedeelte van de definitie

Voorbeelden van deze bestandsindelingen zijn beschikbaar in de Azure Policy GitHub-repo:

Overzicht van werkstromen

De aanbevolen algemene werkstroom van Azure Policy code ziet eruit als in dit diagram:

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

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
|     |- 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
|

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

Bekijk ook Export Azure Policy resources om uw bestaande definities en toewijzingen op te halen in de broncodebeheeromgeving GitHub.

Initiatiefdefinities maken en bijwerken

Initiatieven hebben ook hun eigen JSON-bestand en gerelateerde bestanden die moeten worden opgeslagen in dezelfde map. Voor de initiatiefdefinitie is vereist dat de beleidsdefinitie al bestaat, dus deze kan pas worden gemaakt of bijgewerkt als de bron voor het beleid is bijgewerkt in broncodebeheer en vervolgens is 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
|     |- 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
|

Net als bij beleidsdefinities moet de initiatiefdefinitie in Azure automatisch worden bijgewerkt wanneer u een bestaand initiatief toevoegt of bijwerkt. Het testen van de nieuwe of bijgewerkte initiatiefdefinitie wordt in een latere stap uitgevoerd.

De bijgewerkte definitie testen en valideren

Zodra automatisering uw zojuist gemaakte of bijgewerkte beleids- of initiatiefdefinities heeft doorgevoerd en de update voor het object in Azure heeft uitgevoerd, is het tijd om de aangebrachte wijzigingen te testen. Het beleid of de initiatief(en) waar het deel van uitmaakt, moet vervolgens worden toegewezen aan resources in de omgeving die het verste van de productieomgeving is. Deze omgeving is doorgaans Dev.

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

Notitie

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

Nadat de toewijzing is geïmplementeerd, gebruikt u de Azure Policy SDK, de Azure Policy Compliance Scan GitHub Action ofde azure Pipelines Security and Compliance Assessment-taak om nalevingsgegevens voor de nieuwe toewijzing op te halen. De omgeving die wordt gebruikt om het beleid en de toewijzingen te testen, moet zowel compatibele als niet-compatibele resources hebben. Net als bij een goede eenheidstest voor code wilt u testen of resources zijn zoals verwacht en dat u ook geen fout-positieven of fout-negatieven hebt. Als u alleen test en valideert op wat u verwacht, kan het beleid onverwachte en niet-geïdentificeerde gevolgen hebben. Zie Evaluate the impact of a new Azure Policy definition (De impact van een nieuwe definitie Azure Policy evalueren) voor meer informatie.

Hersteltaken inschakelen

Als de validatie van de toewijzing voldoet aan de verwachtingen, is de volgende stap het valideren van herstel. Beleid dat deployIfNotExists of modify gebruikt, kan worden omgezet in een hersteltaak en resources corrigeren vanuit een niet-compatibele status.

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 door te voeren 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 die bekend staan als niet-compatibel. Er moeten drie tests worden uitgevoerd voor deze hersteltaken voordat u doorgaat:

  • Valideren of de hersteltaak is voltooid
  • Voer een beleidsevaluatie uit om te zien of de resultaten van de naleving van het beleid worden bijgewerkt zoals verwacht
  • Een omgevingseenheidtest rechtstreeks uitvoeren op de resources om te controleren of de eigenschappen zijn gewijzigd

Het testen van zowel de bijgewerkte resultaten van de beleidsevaluatie als de omgeving biedt direct een bevestiging dat de hersteltaken hebben gewijzigd wat er werd verwacht en dat de beleidsdefinitie de nalevingswijziging heeft gezien zoals verwacht.

Bijwerken naar afgedwongen toewijzingen

Nadat alle validatiepoorten zijn voltooid, moet u de toewijzing bijwerken om enforcementMode van ingeschakeld te gebruiken. Het is raadzaam om deze wijziging in eerste instantie in dezelfde omgeving te maken, ver van de productieomgeving. Zodra die omgeving is gevalideerd zoals verwacht, moet het bereik van de wijziging worden beperkt tot de volgende omgeving, en meer, totdat het beleid wordt geïmplementeerd naar productiebronnen.

Geïntegreerde evaluaties verwerken

De algemene werkstroom voor Azure Policy as 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 infrastructuur te maken.

In dergelijke gevallen moet, nadat de implementatie van de toepassing of infrastructuur is uitgevoerd op een testabonnement of resourcegroep, beleidsevaluatie worden uitgevoerd voor die scopecontrole van de validatie 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 toepassings- of infrastructuurimplementatie in een vroeg stadium in strijd is met beleidsdefinities. Deze beleidsevaluatie moet daarom een stap zijn in deze werkstromen en failimplementaties die niet-compatibele resources maken.

Beoordelen

In dit artikel wordt de algemene werkstroom voor Azure Policy code beschreven en wordt ook beschreven waar beleidsevaluatie deel moet uitmaken van andere implementatiewerkstromen. Deze werkstroom kan worden gebruikt in elke omgeving die ondersteuning biedt voor gescripte stappen en automatisering op basis van triggers. Voor een zelfstudie over het gebruik van deze werkstroom op GitHub, zie Zelfstudie:Azure Policy implementeren als code met GitHub .

Volgende stappen