Article coécrit par David Frappart et Souha Bel Haj Hassine Dans ce nouvel article, nous allons parler du formidable...
6 mars 2018
Azure Policy pour la gouvernance de votre plateforme
La mise en place de démarches DevOps répond aux problématiques rencontrées dans beaucoup d’organisations IT « classiques », à savoir :
- le manque de communication et de coordination entre développeurs et opérationnels,
- les objectifs décorrélés : livraison de nouvelles fonctionnalités VS stabilité de la plateforme,
- les frustrations liées notamment aux délais de mise à disposition de ressources.
La simplicité et la rapidité de mise en œuvre de plateformes sur Azure favorise le déploiement et/ou la migration d’environnements sur le cloud. Cela lève donc certains freins pour les développeurs en leur offrant la liberté de déployer des environnements beaucoup plus rapidement ! En ce sens, le cloud facilite la mise en place de démarche DevOps.
Néanmoins, suite au déploiement rapide d’environnements Azure, certaines entreprises font face à un manque de maîtrise de leur plateforme, aussi bien en termes de supervision des applications que de sécurité ou encore de suivi du budget.
Afin de préserver la liberté que peut offrir le cloud aux développeurs tout en maîtrisant son utilisation, il est important de définir un cadre d’utilisation du Cloud.
Présentation du service Azure Policy
Azure Policy est un nouveau service, encore en preview au moment où je rédige cet article, qui vous permet de définir le cadre d’utilisation de vos abonnements Azure. Selon les règles mises en place, vous pourrez par exemple :
- mettre en place des limites quant aux choix disponibles :
- dans le dimensionnement des VMs, pour éviter de devoir déployer des VMs trop coûteuses sur des environnements de Dev par exemple
- dans le choix des datacenters
- dans la version des bases SQL Azure
- mettre en place des audits :
- Sur l’activation des logs de diagnostics
- Sur le chiffrement des bases SQL Azure
- vérifier la convention de nommage définie
- définir des tags par défaut.
Comment utiliser Azure Policy ?
L’utilisation d’Azure Policy est composée de 3 étapes :
- Définition
- Affectation
- Audit de conformité
Première étape, la définition des policies
La première étape est de définir les policies ou regroupements de policies (cf. Initiatives ci-dessous). Vous pouvez soit les sélectionner parmi celles proposées ou en créer des spécifiques si besoin.
Création de policies custom : https://docs.microsoft.com/en-us/azure/azure-policy/create-manage-policy#implement-a-new-custom-policy
Chaque définition de policy ou d’initiative, peut être associée à une catégorie. Ces catégories sont simplement des metadatas qui peuvent vous aider à rechercher vos définitions par la suite (exemples : Network, Security, Monitoring…).
Initiatives
Pour faciliter la gestion de vos policies, vous avez la possibilité, et cela est conseillé, de passer par des « initiatives ». Ce sont simplement des regroupements de policies censées avoir le même objectif.
On pourrait, par exemple, définir une initiative de chiffrement dans laquelle on aurait :
- une policy sur le chiffrement des bases SQL Azure,
- une sur le chiffrement des comptes de stockage,
- et une sur le chiffrement des disques.
Même si vous n’avez qu’une policy à mettre dans une initiative, il est tout de même préférable de passer par une initiative pour en simplifier la gestion. Si jamais dans le futur, vous souhaitez ajouter une autre policy dans l’initiative, celle-ci sera directement prise en compte là où l’initiative est affectée !
Paramètres
Vous pouvez variabiliser les valeurs utilisées au sein des définitions pour limiter le nombre de définitions et choisir une valeur au moment de l’affectation. Par exemple, pour la policy qui vise à limiter le choix de datacenter, la liste des datacenters possibles est passée en paramètre. On peut ainsi, à partir de la même définition, choisir de limiter un resource group au datacenter West Europe et un autre au datacenter East Europe.
Deuxième étape, les affectations
Ensuite, il faut affecter ces définitions à un scope. Les scopes sont basés sur les souscriptions ou groupes de ressources sur lesquels on peut préciser des exclusions.
Il est ainsi possible de répartir les policies à travers différents périmètres. Par exemple :
- pour l’ensemble des souscriptions
- limiter le choix des datacenters
- contrôler la convention de nommage
- appliquer des tags
- pour des environnements particuliers
- limiter le choix dans les SKU (seulement des petites VM sur des environnements de développement par exemple)
- pour des groupes de ressources
- limiter le choix des types de ressources (dans un groupe de ressources dédié à la partie réseau transverse, seules les ressources de types réseau seront autorisées…).
L’affectation peut se faire simplement :
-
- Via le portail
- Via le portail
-
- Via PowerShell à l’aide de la commande :
New-AzureRMPolicyAssignment
- Via PowerShell à l’aide de la commande :
Troisième étape, la conformité
Une fois que les policies ont été affectées, il est possible de vérifier la conformité de vos environnements à l’aide du rapport de conformité mis à disposition dans le portail Azure.
Déploiement automatique d’Azure Policy
L’utilisation du service Azure Policy s’avère très intéressant dans des cas où le nombre de ressources Azure devient très important et donc que la gouvernance de la plateforme se complexifie. Dans certains cas, les ressources sont réparties entre plusieurs souscriptions. Il peut alors être intéressant d’automatiser la création des définitions afin de mettre à disposition un « catalogue » de policies dans chacune des souscriptions.
Comme il vaut mieux passer par des « initiatives », nous allons utiliser la commande PowerShell suivante pour créer une initiative custom :
New-AzureRmPolicySetDefinition
En entrée de cette commande, nous précisons :
-
-
- le nom, le label et la description de l’initiative à créer
- une catégorie pour l’initiative, à renseigner dans les metadatas :
$metadata='{"category": "'+$initiativeCategory+'"}' - un fichier JSON de description pour l’initiative
- un éventuel fichier JSON si l’initiative a des paramètres en entrée.
-
New-AzureRmPolicySetDefinition -Name $initiativeName -DisplayName $initiativeDisplayName -Description $initiativeDescription -Metadata $metadata -PolicyDefinition $definitionFile -Parameter $paramFile
Prenons le cas d’une initiative avec 2 policies qui se chargent d’appliquer chacune un tag aux ressources Azure : un pour le nom de l’application concernée, un pour l’environnement. Les tags sont appliqués avec une valeur définie par défaut dans le cas où le tag n’est pas présent.
Fichier de définition
[
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
"parameters": {
"tagName": {
"value": "[parameters('AppNameLabel')]"
},
"tagValue": {
"value": "[parameters('AppNameValue')]"
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
"parameters": {
"tagName": {
"value": "[parameters('EnvLabel')]"
},
"tagValue": {
"value": "[parameters('EnvValue')]"
}
}
}
]
Les Id des policies à ajouter dans les initiatives peuvent être récupérés en PowerShell à l’aide de la commande : Get-AzureRmPolicyDefinition
Fichier de paramètres
{
"AppNameLabel": {
"type": "String",
"metadata": {
"displayName": "Application Name"
},
"allowedValues": [
"AppName"
]
},
"AppNameValue": {
"type": "String",
"metadata": {
"displayName": "Application Name Value"
},
"allowedValues": [
"Backup"
]
},
"EnvLabel": {
"type": "String",
"metadata": {
"displayName": "Environment"
},
"allowedValues": [
"Env"
]
},
"EnvValue": {
"type": "String",
"metadata": {
"displayName": "Environment Value"
},
"allowedValues": [
"SBX"
]
}
}
Conclusion
Du fait des lacunes rencontrées en termes de gouvernance sur les plateformes Azure, les services Azure dédiés à la gouvernance sont en pleine évolution. Scott Guthrie nous en a d’ailleurs beaucoup parlé lors du Red Shirt Dev Tour. Azure Policies est donc un des services auquel il faut penser dans la mise en place de Gouvernance Azure !
Pour le moment, ce service est encore en preview.
