Niveau : ★★★★☆
Voilà un point qui pose question et inquiétude. Il y a beaucoup à dire sur ce sujet, l’article suivant présente quelques points importants, quelques pistes de réflexion qui permettront de réaligner son environnement sur le CAF (Cloud Adoption Framework).
Très loin d’être exhaustif, mais plutôt destiné à mettre en appétit et à dédramatiser ce sujet.
J’ai déjà déployé mes ressources et mes charges de travail sur Azure et je l’ai fait sans respecter / connaitre / appliquer le CAF. Et je suis maintenant bien ennuyé pour gouverner correctement mes ressources.
Parce que le constat est rapide, pas de LZ (Landing Zone) cohérente, c’est une charge supplémentaire dans toutes les actions de gouvernance que je veux mener. Quelques exemples évidents :
- Positionner des Azure policy ? C’est abonnement par abonnement
- Positionner des RBAC, c’est abonnement par abonnement …Etc.
Faut-il jeter l’éponge ? Je ne pense pas. Il y a toujours moyen de rattraper ce manque, même post déploiement.
Ce que l’on trouve en général, et je dirais que c’est presque la meilleure des situations, ce sont des abonnements à la racine du management groupe par défaut nomme Tenant Root Group. Mais ce groupe ne doit pas servir à l’administration. Et les subscriptions à plats ne sont pas la solution.
C’est une premier constat, ça ne s’inscrit pas dans le CAF et ça ne facilite pas la gouvernance. Ce que l’on retrouve également beaucoup, c’est un positionnement de MG (Management groups) pour améliorer la lisibilité, un peu comme une arborescence de répertoires. Cela ne correspond pas non plus à un besoin de gouvernance.
On gagne en lisibilité dans la console, c’est propre, mais rien d’autre.
Finalement, peu importe ce qui est en place hors du CAF, ce qui est important c’est comment réaligner au mieux l’existant.
Première tâche, la répartition des ressources. Est-elle cohérente ou bien ne l’est-elle pas ?
Ce que je considère comme non cohérent, c’est par exemple un mélange des genres avec des ressources de plateforme dans le ou les mêmes abonnements que les ressources applicatives. Si cela peut convenir à très petite échelle (et encore !), c’est beaucoup plus compliqué à petite ou moyenne échelle.
Ce que l’on comprend rapidement, c’est qu’il va falloir pour s’aligner sur le CAF … déplacer des ressources. Ce qui est dit au début de cet article, c’est que rien ou presque n’est impossible ou définitif, mais il y a quand même une bonne charge pour se remettre aux normes.
Il y a aussi avant / pendant cette phase un point essentiel, c’est de convaincre les équipes en place et expliquer pourquoi ces actions sont nécessaires.
Et en tout premier lieu, expliquer qu’il n’y a pas de coûts liés aux MG et aux subscriptions. Ce ne sont que des conteneurs organisationnels !
Des boites vides sur lesquelles on va pouvoir positionner des stratégies et des équipes d’exploitation.
Pour convaincre, je m’appuie souvent sur l’exemple ci-dessous. Comment il va être possible de passer de 4 attachements RBAC 4 attachements d’Azure Policy à 1 seul en s’appuyant sur les MG et l’héritage. Ce n’est pas une architecture cible, mais c’est un schéma simple et parlant pour commencer à expliquer les avantages et la granularité que vont amener les managements groups.
ATTENTION : Les plus pointilleuses / pointilleux vous diront qu’il est tout à fait possible d’attacher les RBAC à la racine, donc au niveau du Tenant Root Group.
Pour moi, c’est à éviter et ce n’est pas une bonne pratique. Il faut largement préférer le MG intermédiaire, qui porte dans la majorité des cas le nom de l’entreprise ou de l’organisation.
Mener ce changement, c’est créer des MG sur le modèle du CAF. C’est un prérequis au déplacement des subscriptions et des ressources.
On passe donc de l’ancienne version à gauche à la nouvelle à droite.
Seconde tâche, avant de basculer les ressources, décider de ce que seront les RBAC et les Policy Azure. C’est à dire vérifier que les policy existantes (s’il elles existent) sont reconduites. Par exemple, si il y a des policy liées aux contraintes légales sur les subscriptions existantes, il faut que le passage de la source à la cible s’accompagne des mêmes attachements de policy. Si j’ai choisi de déployer mes ressources en France uniquement, je dois porter ce choix sur ma nouvelle arborescence.
Je dois ainsi attacher cette stratégie mais sur un scope différent. Ici également, la présence de MG me donne plus de facilités.
Comme ce choix est une stratégie d’entreprise qui doit être appliquée sur toutes les subscriptions, je la positionne au + haut niveau, le MG intermédiaire, plutôt que de positionner sur chacune des subscriptions.
Cette remarque est également valable pour les RBAC, je dois conduire la même réflexion sur le sujet des droits.
Troisième tâche, poursuivre l’identification et contrôler si les premiers piliers du CAF sont en place. C’est à dire (et oui …), le naming et le tagging. Je pense que la refonte de l’arborescence doit OBLIGATOIREMENT s’accompagner d’une réflexion approfondie sur le sujet naming / tagging.
Il faut avoir les idées claires sur les ressources. Trois pistes de travail :
1 / Le naming n’existe pas, alors il va falloir en mode « dégradé » s’appuyer sur des tags pour compléter l’absence de convention de nommage. Il est difficile ou impossible de renommer une ressource, la meilleur des solutions est de venir ajouter des informations normalement présentes dans la convention de nommage par des paire clefs / valeurs dans les tags.
2 / Le naming et Ok mais tagging est absent, c’est également à compléter. Mais c’est un peu plus facile
3 / Naming et Tagging sont Ok, c’est une bonne situation, il est possible de passer à la suite.
Voir à ce sujet cette série d’articles : https://thierrybtblog.wordpress.com/2022/03/01/gouvernance-azure-pas-si-facile/
Une bonne pratique est également de traiter les tâches 2 et 3 en parallèle. Elles sont intimement liées, les Azure Policy utilisent avec bonheur le contenu des tags pour améliorer encore la gouvernance. Ce qui est présenté ici avec Philippe sur son (excellent) chaine Youtube.
https://www.youtube.com/watch?v=-KvzxuwEVic&list=PLxf9spw2semQssko_pwji9lpqgUDGHxlB&index=13
Voilà pour quelques uns des points les plus importants, c’est à traiter à minima pour réussir sa transition d’environnement non gouverné ou difficile à gouverner vers le Cloud Adoption Framework, le nec + ultra ;).
Mais … il manque quelque chose.
Puisqu’il est important de respecter le CAF, alors autant le faire jusqu’au bout et appliquer une des bonnes pratiques en terme de management groups. C’est à dire créer un %G spécifique qui va accueillir les subscriptions à décommissionner une fois tous les environnements basculés. Cette partie à droite, normalement coincée entre la Sanbox et la LZ.
Voilà, cette fois, tout est Ok, dans le respect du Cloud Adoption Framework ! Alors, tentées / tentés par l’aventure ?
Dans la partie 2/2, le sujet sera revu mais traité avec une approche différente appelée Brownfield. C’est une transition par duplication qui va sécurisé au maximum la bascule.
Si ce sujet vous inspire et que vous avez des remarques, ajouts, points contraires, n’hésitez pas à commenter et à partager vos expériences sur ce sujet de l’architecture conceptuelle.
Une techno, des infos. 