Aller au contenu

Article 2 – Azure policies

Bienvenue dans ce 2ème article de notre série.

Dans celui-ci, nous allons rentrer dans le détail des Policy et notamment les Custom Policy.

  1. Action des Policy

Comme d’habitude, nous commençons par les bases, à savoir les différentes Actions que peuvent prendre les Policy.

Disabled: La Policy est désactivée.

Deny: La Policy bloquera un déploiements s’il ne la respecte pas.

DeployifnotExist: Si un déploiement ne respecte pas la Policy, une remédiation automatique sera appliquée.

Les Policy peuvent être configurées en Disabled, cela permet d’annuler l’effet de la Policy sans modifier la Blueprint.

Toutes les Policy n’acceptent pas toutes les Actions, certaines n’autorisent que Deny, d’autre uniquement Deployifnotexist et certaines acceptent les 3 Actions.

Les Policy avec « Deploy » dans leur intitulé proposent généralement Deployifnotexist.

Certaines Policy configurées en Deny peuvent bloquer le déploiement de certaines ressources depuis le portail, notamment les instances SQL managées ou les comptes de stockage, il faut alors passer par des Custom Templates (qui feront l’objet d’un futur article).

2. Policy exclusions

Si vous ne voulez pas désactiver une Policy mais voulez permettre à certaines Ressources (ou Resource Groups) d’ignorer cette Policy, il est possible de configurer une Exclusion.

3. En utilisant le portail

Dans certains cas, l’usage de Custom Policy est nécessaire.

La création de Custom Policy est décrite sur le site de Microsoft :

https://docs.microsoft.com/en-us/azure/governance/policy/how-to/programmatically-create

Les possibilités permettraient de remplir un livre, nous allons donc nous limiter à quelques astuces pour savoir comment les exploiter correctement, votre imagination sera la seule limite à ce que vous pourrez mettre en œuvre.

Pour rappel, il n’est actuellement pas possible d’importer ou exporter une Blueprint contenant une Custom Policy.

Créer une Custom Policy dans le portail consiste à importer le contenu d’un fichier JSON dans la boite Policy Rule et à remplir différents paramètres :

  • Pour faciliter la réutilisation de la Policy, il est recommandé de choisir de la stocker dans le Management Group via la boite Definition Location.
  • Nom et Description sont là pour décrire la Policy
  • Category contient une liste de catégories permettant de retrouver plus facilement la Policy plus tard. Il est possible de créer une nouvelle Category (par exemple Custom).

4. Création d’une Custom Policy en utilisant Powershell

La commande PowerShell suivante permet de réaliser les actions décrites précédemment plus rapidement :

New-AzPolicyDefinition -Name MyNewPolicy -DisplayName MyNewPolicy -Description "My Policy Description" -Policy $home\LocationPolicy.json -ManagementGroupName "xxxx" -Metadata '{"category":"Security Policy"}'

5.Fichier JSON de Custom Policy

Les possibilités étant quasiment illimitées, cette page est un bon point de départ :

https://docs.microsoft.com/en-us/azure/governance/policy/samples/

Par exemple cette règle forcera à faire débuter tous les noms de Resource Groups par rg- et tous les noms de ressources seront sur le format xxx-AAA-11.

{

   "properties": {

       "displayName": "Match multiple name patterns.",

       "description": "Allows one of 2 naming patterns. All deployments must start either by RG-something or be like xxx-AA-11",

       "mode": "Indexed",

       "policyRule": {

           "if": {

               "allOf": [{

                       "not": {

                           "field": "name",

                           "match": "rg-*"

                       }

                   },

                   {

                       "not": {

                           "field": "name",

                           "match": "xxx-???-##"

                       }

                   }

               ]

           },

           "then": {

               "effect": "deny"

           }

       }

   }

}

6. Forcer une réévaluation de respect des Policy

La réévaluation de respect des Policy peut prendre une heure, ce qui peut être interminable quand on est en train de faire des tests.

Le script PowerShell ci-dessous lancera une mise à jour immédiate.

$subscriptionId = "xxxxxxxx-yyyy-zzzz-yyyy-xxxxxxxxxxxx"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview"

$azContext = Get-AzContext

$azProfile = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile

$profileClient = New-Object -TypeName Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient -ArgumentList ($azProfile)

$token = $profileClient.AcquireAccessToken($azContext.Tenant.Id)

$authHeader = @{

    'Content-Type'='application/json'

    'Authorization'='Bearer ' + $token.AccessToken

}

Invoke-RestMethod -Method Post -Uri $uri -UseBasicParsing -Headers $authHeader

Article rédigé par Arnaud Torres

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

J’accepte les conditions et la politique de confidentialité