Azure BluePrint, orchestration et conformité

Est-ce l’annonce d’une perte de contrôle ? Cette délégation annonce-t-elle de grandes « catastrophes » à venir ?
Non, si les mécanismes de contrôles proposés par Azure sont correctement mis en œuvre.

Au premier rang des bonnes pratiques, les Blueprints sont là pour assurer un contrôle efficace des ressources.
La définition donnée par l’éditeur est on ne peut plus clair :
« Azure Blueprint permet aux architectes cloud et aux membres de l’informatique centrale de définir un ensemble reproductible de ressources Azure qui implémentent et respectent les normes, modèles et exigences d’une organisation ».

Attention, sous une apparente facilité de mise en œuvre se cache une solution puissante, complète et très performante.

Comment parvenir à cet objectif de conformité et de rapidité des déploiements ? Pourquoi les Blueprints participent à cette délégation contrôlée ? Voici quelques clefs pour comprendre avant de se lancer sur le sujet.

Un peu de théorie

Un déploiement à l’aide des Blueprints est un déploiement orchestré et déclaratif à l’instar d’autres technologies Cloud complémentaires comme par exemple Azure Automation. Vous pouvez revoir sur ce point l’article suivant.

Mais ce sujet est différent. Il est plus judicieux de parler de conformité de déploiement. Dès lors que l’on commence à travailler sur cette fonctionnalité, on entend souvent parler d’artefacts. Il existe de nombreux sens pour le mot Artefact. Ici, le plus adapté est composant. Ils sont au nombre de 4 et seront utilisés plus loin dans cet article.

Composants ou artefacts

BluePrint = déploiement orchestré et déclaratif de composants. Mais après ?
2 étapes principales. La définition du Blueprint (le quoi) puis son affectation. Définir, c’est donner (déclarer) un cadre d’utilisation. Affecter, c’est « attacher » ce cadre à un groupe d’utilisateurs.

Dans la pratique

La fonctionnalité Blueprints est disponible depuis le portail Azure, elle donne notamment accès à une première création. Tout commence dans le menu de gauche par la Définition du Blueprint

Le menu Blueprints, bien démarrer

Il existe quelques exemples déjà créés, ils peuvent être consultés pour information. Ici, la découverte se fera au travers d’un exemple vierge appelé Blueprint vide sans propriété ni artefact initial.

Le mode pas à pas démarre par le nommage, la description, puis l’abonnement qui héberge ce Blueprint. L’écran suivant permet de rentrer dans le vif du sujet avec l’ajout des artefacts. Le mode de création ne sera pas vu en détail dans cet article. Pour pouvoir répéter et comprendre ce déploiement, le modèle suivant est utilisé.

Dans ce modèle simple, plusieurs choses très importantes :

1. Une limite d’application à un groupe d’utilisateurs et un scope de rôles et responsabilité. Qui est concerné par ce blueprint ? Quelles sont les actions possibles dans ce cadre ?
2. Une conformité positionnée sur la création des ressources groupes qui se verront (dans le scope défini) obligatoirement attacher une étiquette (un tag) de manière transparente pour l’utilisateur.
3. Un modèle ARM « invisible » qui limite le type de compte de stockage que pourront créer les utilisateurs.

Que se passe-t-il une fois le modèle déployé ?

Un groupe de ressource est créé par un utilisateur attaché aux rôles dans le Blueprint (Artefact : Attribution de rôles). La création est possible car le rôle attaché est un rôle de contributeur qui permet entre autre de créer des ressources. Cette ressource est créée sans étiquette mais est automatiquement mise en conformité (Artefact : Attribution de stratégie).

Étiquettes itpro1 et itpro2, mise en conformité automatique

Ce même utilisateur va maintenant créer un compte de stockage depuis le portail dans le ressource groupe présent dans la définition (Artefact : Groupe de ressources).
Un utilisateur courant se verra proposer tous les types de stockage disponibles. L’utilisateur « contrôlé » par le Blueprint ne verra pour sa part que les types de stockage proposés par le modèle ARM (Artefact : Modèles Microsoft Azure Resource Manager).

A gauche, hors blueprint, à droite, contrôlé par l’artefact ARM

Délégation donc, mais délégation contrôlée. Et relativement transparente pour l’utilisateur. L’intégration est telle que la notion de contrainte est plutôt légère. Il est à mon avis préférable de parler d’aide à la conformité que de contrainte de déploiement.

Conclusion

Ce qui peut au départ ressembler à l’utilisation des Policy Azure (stratégies de contrôles) est en fait une solution beaucoup plus complète. L’intégration des rôles, des stratégies et des modèles ARM apportent une solution globale. L’existant peut être en grande partie réutilisé. Par exemple, les modèles ARM déjà utilisés en entreprise pour le déploiement de ressources seront injectés directement en tant qu’Artéfact. Les stratégies existantes seront également portées dans les Blueprints.

Présenté très sommairement dans ce sujet, cette fonctionnalité est à tester avec des modèles plus complets. Le niveau d’attribution est beaucoup plus fin qu’il n’y parait. L’artefact Groupe de ressources qui n’a pas été présenté en détail permet d’affiner le scope d’application. La création du compte de stockage présentée plus haut ne serait plus limitée si elle se faisait hors du groupe de ressources attaché au Blueprint. Ce n’est qu’un exemple !

Pour résumer, voici un rappel des points importants 

1 / Un Blueprint est composé d’artefacts de 4 types. Groupes de ressources, Modèles Microsoft Azure Resource Manager, Affectations de rôles et Affectations de stratégies
2 / Blueprint n’est pas une contrainte mais une aide au déploiement.
3 / Les modèles existants (ARM, Policy) sont réutilisables.