Partager via

Concevoir des workflows Azure Policy en tant que code

  • Article

Au fil de votre progression dans la gouvernance cloud, vous allez chercher à passer de la gestion manuelle de chacune des affectations de stratégies sur le Portail Azure ou à l’aide des différents Kits de développement logiciel (SDK) à un processus plus gérable et reproductible à l’échelle de l’entreprise. Voici deux des approches prédominantes de la gestion des systèmes à grande échelle dans le cloud :

  • Infrastructure as Code : pratique consistant à traiter en tant que code source tout le contenu qui définit les environnements, des modèles Azure Resource Manager (modèles ARM) aux définitions Azure Policy en passant par Azure Blueprints.
  • DevOps : rassemblement des personnes, des processus et des produits qui permettent une livraison continue de valeur ajoutée aux clients finaux.

Azure Policy en tant que code est la combinaison de ces idées. Pour l’essentiel, vous conservez vos définitions de stratégies dans le contrôle de code source, puis testez et validez chaque modification effectuée. Toutefois, l’implication des stratégies avec l’Infrastructure as Code ou le DevOps ne devrait pas s’arrêter là.

L’étape de validation doit également être un élément d’autres workflows d’intégration continue ou de déploiement continu (CI/CD), comme le déploiement d’un environnement d’application ou d’une infrastructure virtuelle. En faisant de la validation Azure Policy l’un des premiers composants du processus de création et de déploiement, les équipes chargées des applications et des opérations détectent si leurs modifications se comportent comme prévu bien avant qu’il ne soit trop tard et qu’il faille les déployer en production.

Définitions et informations fondamentales

Avant d’aborder les détails du workflow Azure Policy en tant que workflow Code, il est important de comprendre certains concepts fondamentaux, par exemple comment créer des définitions de stratégie et des définitions d’initiative, et comment tirer profit des exemptions sur les affectations de ces définition :

Les noms de fichiers correspondent à certaines parties des définitions de stratégie ou d’initiative et d’autres ressources de stratégie :

Format de fichier Contenu du fichier
policy-v#.json Définition de stratégie complète pour cette version
policyset-v#.json Définition d’initiative complète pour cette version
policy-v#.parameters.json Partie properties.parameters de la définition de stratégie
policyset-v#.parameters.json Partie properties.parameters de la définition d’initiative
policy-v#.rules.json Partie properties.policyRule de la définition de stratégie
policyset-v#.definitions.json Partie properties.policyDefinitions de la définition d’initiative
exemptionName.json Exemption de stratégie qui cible une ressource ou une étendue particulière

Vue d’ensemble du workflow

Le workflow général recommandé d’Azure Policy en tant que code se présente comme ce diagramme :

Diagramme montrant les cadres du workflow Azure Policy en tant que code de la création jusqu’au déploiement, en passant par les tests.

Contrôle de code source

Vous pouvez exporter des définitions de stratégie et d’initiative existantes par différents moyens comme des requêtes PowerShell, CLI ou Azure Resource Graph (ARG). L’environnement de gestion du contrôle de code source choisi pour stocker ces définitions peut être l’une des nombreuses options, notamment GitHub ou Azure DevOps.

Créer et mettre à jour des définitions de stratégies

Les définitions de stratégies sont créées avec des fichiers JSON et stockées dans le contrôle de code source. Chaque stratégie possède son propre ensemble de fichiers (paramètres, règles et paramètres d’environnement) qui doivent être stockés dans le même dossier. Nous vous recommandons la structure suivante pour conserver vos définitions de stratégies dans le contrôle de code source.

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

Quand une stratégie ou version est ajoutée ou mise à jour, le workflow doit automatiquement mettre à jour la définition de stratégie dans Azure. Le test de la définition de stratégie ajoutée ou mise à jour sera effectué dans une étape ultérieure.

Créer et mettre à jour des définitions d’initiatives

Les définitions d’initiative sont également créées à l’aide de fichiers JSON qui doivent être stockés dans le même dossier que les définitions de stratégie. La définition d’initiative exige que la définition de stratégie existe déjà. Vous ne pouvez donc pas la créer ni la mettre à jour tant que la source de la stratégie n’a pas été mise à jour dans le contrôle de code source, puis dans Azure. Nous vous recommandons la structure suivante pour conserver vos définitions d’initiatives dans le contrôle de code source :

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

Comme pour les définitions de stratégie, le workflow doit automatiquement mettre à jour la définition d’initiative dans Azure lors de l’ajout ou de la mise à jour d’une initiative existante. Le test de la définition d’initiative ajoutée ou mise à jour sera effectué dans une étape ultérieure.

Notes

Il est recommandé d’utiliser un mécanisme de déploiement centralisé comme des workflows GitHub ou Azure Pipelines pour déployer des stratégies. Cela permet de garantir que seules les ressources de stratégie révisées sont déployées dans votre environnement et qu’un mécanisme de déploiement progressif et centralisé est utilisé. Les autorisations en écriture sur les ressources de stratégie peuvent être limitées à l’identité utilisée dans le déploiement.

Tester et valider la définition mise à jour

Maintenant que l’automatisation s’est occupée des définitions de stratégies ou d’initiatives créées ou mises à jour et a effectué la mise à jour sur l’objet dans Azure, il est temps de tester les modifications apportées. La stratégie ou la (ou les) initiative(s) à laquelle (auxquelles) elle appartient doit ensuite être affectée aux ressources de l’environnement le plus éloigné de la production, généralement Dev.

Remarque

Dans cette étape, nous effectuons des tests d’intégration de la définition de stratégie dans votre environnement Azure. Ces tests sont distincts de la vérification de la fonctionnalité de la définition de stratégie qui doit se produire pendant le processus de création de définition.

L’affectation doit utiliser enforcementModedisabled afin que la création et la mise à jour des ressources ne soient pas bloquées, mais que la conformité des ressources existantes à la définition de stratégie mise à jour soit toujours auditée. Même avec enforcementMode, il est recommandé que l’étendue d’affectation soit un groupe de ressources ou un abonnement servant spécialement à valider des stratégies.

Notes

Si enforcementMode est utile, il ne remplace pas pour autant un test rigoureux d’une définition de stratégie dans différentes conditions. La définition de stratégie doit être testée avec des appels d’API REST PUT et PATCH, des ressources conformes et non conformes, ainsi que des cas limites comme une propriété manquantes dans la ressource.

Une fois l’affectation déployée, utilisez le Kit de développement logiciel (SDK) Azure Policy, la tâche d’évaluation de la sécurité et de la conformité Azure Pipelines ou des requêtes Azure Resource Graph (ARG) (voir des exemples) pour obtenir des données de conformité pour la nouvelle affectation. L’environnement utilisé pour tester les stratégies et les affectations doit avoir des ressources avec différents états de conformité. À l’instar d’un bon test unitaire pour le code, il est important de vérifier que les ressources sont évaluées comme prévu et qu’il n’y a pas de faux positifs ou de faux négatifs. Si vous vous contentez de tester et de valider ce que vous attendez, la stratégie risque d’avoir un impact imprévu et non identifié. Pour plus d’informations, consultez Évaluer l’impact d’une nouvelle définition Azure Policy.

Activer les tâches de correction

Si la validation de l’affectation répond aux attentes, il s’agit ensuite de valider la correction. Les stratégies qui utilisent deployIfNotExists ou modify peuvent avoir une tâche de correction associée déclenchée pour corriger des ressources à partir d’un état non conforme et les mettre en conformité.

La première étape de la correction des ressources consiste à accorder à l’affectation de stratégie l’attribution de rôle définie dans la définition de stratégie. Cette attribution de rôle accorde à l’identité managée de l’affectation de stratégie des droits suffisants pour apporter les modifications permettant de rendre la ressource conforme.

Dès que l’affectation de stratégie dispose des autorisations nécessaires, utilisez le kit SDK Policy pour déclencher une tâche de correction sur un ensemble de ressources connues pour être non conformes. Avant de continuer, trois tests doivent être effectués sur ces tâches corrigées :

  • Vérifier que la tâche de correction a réussi
  • Exécuter l’évaluation de la stratégie pour voir si les résultats de conformité de la stratégie ont été mis à jour comme prévu
  • Exécuter un test unitaire d’environnement directement sur les ressources pour vérifier que leurs propriétés ont changé

Le fait de tester à la fois les résultats de l’évaluation de la stratégie mise à jour et l’environnement lui-même permet de confirmer que les tâches de correction ont changé ce qui était attendu et que la définition de stratégie a constaté la modification de conformité comme prévu.

Mettre à jour pour appliquer les affectations

Une fois toutes les épreuves de validation effectuées, mettez à jour l’affectation pour utiliser enforcementModeenabled. Il est recommandé d’effectuer cette modification au départ dans le même environnement éloigné de la production. Vérifiez que les effets souhaités sont appliqués lors de la création de ressources et de la mise à jour de ressources. Après la vérification que cet environnement fonctionne comme prévu, la modification doit être étendue de façon à inclure l’environnement suivant, et ainsi de suite, jusqu’à ce que la stratégie soit déployée sur les ressources de production.

Traiter les évaluations intégrées

Le workflow général d’Azure Policy en tant que code vise à développer et à déployer des stratégies et des initiatives dans un environnement à grande échelle. Toutefois, l’évaluation de la stratégie doit faire partie du processus de déploiement de tous les workflows qui déploient ou créent des ressources dans Azure, par exemple le déploiement d’applications ou l’exécution de modèles ARM dans le but de créer une infrastructure.

Dans ce cas, une fois le déploiement de l’application ou de l’infrastructure effectué sur un abonnement ou un groupe de ressources de test, l’évaluation de la stratégie doit être effectuée pour cette validation de toutes les stratégies et initiatives existantes. Bien qu’elles puissent être configurées comme enforcementMode disabled dans un environnement de ce type, il est utile de savoir très vite si le déploiement d’une application ou d’une infrastructure est contraire aux définitions de stratégies. Cette évaluation de stratégie doit donc constituer une étape de ces workflows et faire échouer les déploiements qui créent des ressources non conformes.

Révision

Cet article traite du workflow général d’Azure Policy en tant que code et explique que l’évaluation de la stratégie doit faire partie d’autres workflows de déploiement. Ce workflow peut être utilisé dans n’importe quel environnement prenant en charge les scripts et l’automatisation par déclencheurs.

Étapes suivantes