Azure Stratégie, brique essentielle de la gouvernance 

Lorsqu’il est question de Cloud Azure, la bonne pratique, voire la meilleure des pratiques est de s’appuyer sur les stratégies Azure (ou Azure Policy).

C’est un élément, une brique essentielle pour garantir la conformité et l’unicité des ressources déployées. Ressources est ici un terme global puisqu’il s’agit tout à la fois de IaaS, de PaaS mais aussi par exemple de personnalisation de portail.

Mais que se cache-t-il exactement derrière cette appellation de stratégie ? A quoi cela sert-il vraiment ?
C’est tout à la fois un outil d’audit, de bon usage, de contrôle des coûts ou de respect de la conformité. Mais aussi un outil de contrôle de déploiement, qui ne permettra pas de déployer tel ou tel composant ou qui imposera tel ou tel modèle. Et même dans certains cas, un outil de remédiation qui va « réaligner » et corriger les ressources.

Il ne faut pas sous-estimer les possibilités des stratégies, elles sont immenses et pratiquement infinies.

Présentation théorique

Une stratégie est composée de deux parties bien distinctes. Une règle de sélection ou condition, une action. Puis, cette stratégie est ensuite positionnée sur un scope pour être appliquée. Règle et scope sont deux choses différentes.
Les ressources de type machines virtuelles dont le nom commence par windows, voilà une règle.

L’attachement de cette stratégie sur un abonnement monabo0001, voilà le scope. Ainsi, une machine nommée mamachine0001 n’est pas concernée par la règle. Même si elle est présente dans l’abonnement monabo0001.

Si cette machine est nommée windows0001, elle est concernée par la règle. Mais (il y a un mais), la stratégie ne s’applique que si cette machine virtuelle est dans l’abonnement monabo0001. Vient ensuite l’action ou effets. Ces effets sont au nombre de 7. De l’audit à la modification en passant par l’interdiction.  Un exemple d’effet sera présenté dans la partie pratique.
Sans aller trop loin dans le code, dans le fichier Json ci-dessous apparaissent clairement la notion de règle (balise « policyRule ») et la notion d’effet (balise « effect »).

Une connaissance approfondie du code ne sera nécessaire que lorsqu’il s’agira de créer ses propres stratégies. Mais, il y a déjà beaucoup à faire avec les stratégies par défaut disponibles dans la console.

Dans la pratique

Comme la fonctionnalité est très complète, elle a une console dédiée sur le portail.

Tout commence par le menu Définitions ou se trouvent deux types de définition. Les Policy (le terme n’est pas traduit dans la console) et les Initiatives. Une initiative est en fait un regroupement de stratégies sur un même thème. On voit clairement dans l’écran précédent qu’une initiative peut porter deux stratégies, mais aussi … 989. On trouve également dans le menu des catégories comme General, Security Center ou Backup. Il est de cette façon plus facile de sélectionner un thème particulier.

Dans cette console, tout commence par la définition car c’est ici que condition et effet sont choisis. Dans l’exemple suivant, la stratégie se nomme Configurer une sauvegarde sur des machines virtuelles sans étiquette donnée dans un coffre Recovery Services existant dans la même localisation.

Voilà une règle de gouvernance élémentaire et indispensable lorsqu’il s’agit de machine de production.
Pour résumer, les conditions sont :
une machine virtuelle qui n’a pas d’étiquette (appelée également tags ou balises).
Une fois cette stratégie sélectionnée, il faut l’affecter.

Et lors de cette affectation (le scope ou cible de déploiement), il faut choisir l’un de effets proposés par la stratégie. On retrouve dans l’image suivante quelques-uns des points listés.

Il est intéressant de noter que cette stratégie possède plusieurs effets : deployIfNotExists, auditIfNotExists, disabled. L’affectation se fait enfin sur une étendue (Groupe de management, Abonnement, groupe de ressources). Dernière subtilité, si l’effet choisi est de type déploiement (deployIfNotExists) et que le choix de l’administrateur est de créer une tâche de remédiation lors de l’affectation, la console propose de créer automatiquement une identité managée pour effectuer les actions. Si cette identité est de type système, elle est attachée au cycle de vie de l’affectation. Cela signifie que dès que l’affectation est retirée, l’identité liée est automatiquement supprimée.

Comme elle est affectée, cette définition est maintenant visible dans la console dans le sous menu Affectations. Au bout de quelques minutes, le temps de la vérification de l’état et des conditions, la stratégie affiche un pourcentage de Conformité. C’est un écran très utile à l’échelle d’une entreprise ou l’on retrouve des dizaines de stratégies avec leur niveau de conformité.

Voilà un tableau de suivi qui offre une vue synthétique et expose un taux global puis le taux pour chaque stratégie.

Enfin, si l’effet est de type deployIfNotExists (ce n’est pas le seul effet qui va effectuer de la remédiation), c’est le sous menu Correction qui va afficher le statut des remédiations.

Ce cycle Définitions => Affectations => Conformité => Correction (facultatif) est bien le meilleur moyen de « gouverner » son Cloud Azure. Et d’assurer automatiquement que ce qui est décidé est bien appliqué.

Présenter cette belle mécanique en quelques pages est impossible, mais comprendre la philosophie du produit et important. Enfin, se lancer dans ce mode de gouvernance est certainement une très bonne idée pour simplifier la gestion de ses ressources Azure.

En synthèse, un rappel des points importants 

1 / La gouvernance est au centre des préoccupations pour qui veut optimiser et contrôler la bonne utilisation de ses ressources.

2 / Les stratégies sont des conditions et des effets positionnés sur une cible, un scope.

3 / Les effets vont du simple audit à la remédiation des ressources dont la conformité n’est pas valide.