Archives de catégorie : Azure Resource Manager Policy

Découverte d’Azure Resource Policy

Depuis l’arrivée du modèle RBAC dans Azure, on est capable de maitriser ce qu’un utilisateur pouvait faire (et ne pas faire) dans une souscription au travers des rôles et Custom-Rôles. Oui, on peut maitriser ce qui est consommé. Par contre comment bloquer l’usage de certaines ressources sous conditions? Par exemple, comment empêcher le déploiement de ressources très couteuse, ou tout du moins mettre en place un processus pour encadrer ces usages au sein de nos souscriptions Azure?

La réponse est venue très récemment (15 avril 2016) avec l’arrivée de la fonctionnalité Azure Resource Policy. Au passage, je recommande la session Deploying, Managing, and Controlling Apps with Azure Resource Manager de la Build 2016 pour éclairer sur le sujet.

Avant de continuer, il faut comprendre une subtilité. Le modèle RBAC se focalise sur les actions qu’un utilisateur peut ou ne peut pas réaliser sur un périmètre donné, le tout au travers des groupes de ressources. Les Resources Policies ne concernent que les ressources, le périmètre peut être global ou limité à un groupe de ressources particulier.

Pour la mise en œuvre, il faut disposer d’une version récente du module AzureRM PowerShell (1.0 de mémoire) pour disposer des commandes suivantes :

clip_image001

 

Pour la suite, ça se complique un peu. Pour exprimer notre politique, nous devons nous exprimer au format JSON. A la base, une politique ressemble à cela :

{

« if » : {

<condition> | <logical operator>

},

« then » : {

« effect » : « deny | audit | append »

}

}

Définir une politique, c’est bien mais on peut être plus subtil que de simplement refuser. Techniquement, on peut :

  • Audit : Autoriser la demande de déploiement et se contenter d’une entrée dans le journal d’audit
  • Deny : Refuser la demande de déploiement et générer une entrée dans le journal d’audit
  • Append : Réaliser le déploiement en complétant celui-ci (exemple ajout de tags par défaut pour la refacturation)

 

 

Cela semble donc assez simple. La condition, c’est que nous voulons trapper lors du déploiement sur la plateforme Azure. Pour exemple, j’ai repris un exemple de la documentation officielle de Resource Manager Policy.

{

« if »: {

« not » : {

« field » : « tags »,

« containsKey » : « costCenter »

}

},

« then » : {

« effect » : « deny »

}

}

Je pense que c’est assez explicite pour comprendre ce qui va se passer si on tentait de déployer la moindre ressource sans aucun tag, … Traduisons cela en PowerShell :

$policy = New-AzureRmPolicyDefinition -Name AccountingCompliancePolicy -Description « Block any Azure deployment without accounting tag » -Policy ‘{

« if »: {

« not » : {

« field » : « tags »,

« containsKey » : « costCenter »

}

},

« then » : {

« effect » : « deny »

}

}’

$Policy

clip_image002

 

La politique a été acceptée. Avec la commande Get-AzureRMpolicyDefinition, on va retrouver notre politique mais aussi d’autres, …

Get-AzureRMPolicyDefinition | Select Name, Properties

clip_image003

 

C’est que par défaut, on a déjà quelques politiques. Celle-ci-dessous permet de s’assurer que nos ressources ne seront déployées que dans les régions européennes (North Europe et West Europe).

clip_image004

 

Mettre en place notre politique, c’est aussi définir un périmètre sur lequel nous voulons appliquer notre politique. On peut l’appliquer à toute la souscription si on veut mais pour les besoins de la démonstration, on va se limiter à un groupe de ressources particulier :

$AzureResourceGroup = Get-AzureRMResourceGroup -ResourceGroupName « ResourceManagerPolicy »

clip_image005

 

Nous avons tout ce qu’il nous faut. On a plus qu’à déclarer une nouvelle association de notre politique pour le groupe de ressources que nous venons de récupérer dans la variable $AzureResourceGroup

$policy = Get-AzureRmPolicyDefinition -Name ‘AccountingCompliancePolicy’

New-AzureRmPolicyAssignment -Name « AccountingCompliancePolicyAssignment » -PolicyDefinition $policy -Scope $AzureResourceGroup.ResourceId

clip_image006

 

Pour s’en convaincre, il n’y a qu’à tester un déploiement depuis le portail avec une simple machine virtuelle sans configurer aucun Tag. Le processus de validation ne nous remonte aucune erreur, logique, du point de vue JSON, le déploiement est conforme.

clip_image007

 

Par contre, on voit bien que par la suite, cela ne se passe pas bien. En consultant le détail, on voit bien qu’il y a eu plusieurs erreurs :

clip_image008

 

On peut consulter chaque erreur, on a la même cause. C’est bien un refus (c’était le but de notre politique). Dans la capture ci-dessous, c’est la création du Storage Account qui a échoué à cause de notre politique Resource Manager Policy :

clip_image009

 

Le nom de l’opération va nous être utile si on veut filtrer pour retrouver les logs en question.

get-azurermlog | where {$_.OperationName –eq « Microsoft.Authorization/policies/deny/action »} | select ResourceGroupName,OperationName, Category, status

clip_image010

 

Si on sait l’identifier, on peut y associer des alertes Ces alertes peuvent :

  • Envoyer un mail sur l’évènement (bof)
  • Déclencher un WebHook sur l’évènement qui va lui-même déclencher un Runbook Azure Automation

Pour finir quelques scénarios intéressants à creuser autour de cette nouvelle fonctionnalité :

  • Exiger la présence de tags / Enforcer la présence de tags dans les déploiements pour la refacturation
  • S’assurer que les ressources ne soient déployées que dans certaines régions
  • Limiter les Resources Providers utilisables
  • Bloquer l’utilisation de certaines fonctionnalités (géo-réplication du stockage par exemple)
  • Bloquer l’utilisation d’éditions particulières d’un Resource Provider (notion de SKU)
  • Imposer notre convention de nommage des objets

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)