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 :

  1. Définition
  2. Affectation
  3. Audit de conformité

Schèma d'utilisation Azure Policy

 

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 portailaffectation des ressources Azure Policy

 

 

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.

rapport de conformité Azure Policy

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.

Livre Blanc Cell'insight 8 journey to the cloud