Publier une application Azure Managed Application avec BluePrint

Après un premier billet sur la gouvernance on continue. BluePrint permet de standardiser nos souscriptions pour déployer des ressources (Templates ARM) et imposer des règles (Azure BluePrints). Combiné avec d’autres fonctionnalités, on peut encadrer l’usage qui est fait d’Azure en proposant nos propres services. C’est ce que je vous propose d’illustrer dans ce billet avec Azure Managed Application. Quand on développe des applications dans Azure, à un moment, il faut penser à les mettre à disposition, mieux les distribuer. C’est dans cette optique que Azure Managed Application a été développé. La fonctionnalité propose :

  • De packager notre application pour une mise à disposition au sein de notre souscription Azure (Service Catalog Managed Application
  • De devenir fournisseur de solution disponible sur le portail Azure (Marketplace Managed Application)

clip_image002

 

Voilà pour la version courte de Azure Managed Application. Pour la version longue, je vous renvoie vers la documentation officielle.

Pour ce billet, nous allons nous attarder sur la mise à disposition d’une application préalablement préparée au sein de notre souscription. Notre application sera relativement simple : Bastion as A Service. Je voulais fournir une machine virtuelle standardisée. A la base, je pensais utiliser DevTest pour proposer ce service. Cependant, DevTest ne respectait pas mes exigences de compliance. Je me suis donc rabattu sur Azure Managed Application pour proposer un service similaire. Cela présente que des avantages :

  • L’application sera instanciée à la demande. Pas d’usage, pas de machine virtuelle à sécuriser si elle n’existe pas
  • Les ressources composant la machine virtuelle ne doivent pas pouvoir être modifiées
  • Le consommateur doit cependant pouvoir supprimer l’application (même s’il n’a pas accès aux ressources mises à disposition par l’application)

 

Ce billet sera organisé en quatre étapes :

  • Etape n°1 : Mise à disposition des prérequis
  • Etape n°2 : Préparer notre application
  • Etape n°3 : Publication de notre application
  • Etape n°4 : Consommer notre application

 

Etape n°1 : Mise à disposition des prérequis

Notre Azure Managed Application va réutiliser le Virtual Network Spoke01Network mis à disposition dans le groupe de ressource du même nom dans ma souscription AzureTestLabs. Pour rappel, ce Virtual Network est configuré avec un accord de Peering vers un Virtual Network situé dans ma souscription « Hub ». Le Virtual Network comprend deux sous-réseaux :

  • Local
  • Spoke

C’est ce Virtual Network et ces subnets sur lesquels les futures cartes réseau pourront se raccorder.

 

Etape n°2 : Préparer notre application

Dans notre contexte, notre application est composée de deux éléments regroupés au sein d’un fichier ZIP nommé bastion.zip. Le package comprend :

C’est ce contenu que nous allons publier dans notre souscription. Du point de vue Azure, notre application sera un objet dans Azure. Nous allons donc créer un groupe de ressources nommé ManagedApplication dans notre souscription.

New-AzResourceGroup -ResourceGroupName ManagedApplication -Location WestEurope

clip_image004

 

Pour chaque application, nous devons associer une identité (utilisateur ou groupe) qui disposera d’un certain niveau de permissions sur les ressources déployées. Dans notre contexte, ce sera un groupe, qui disposera des permissions Azure les plus étendues sur les ressources liées aux machines virtuelles déployées.

$OwnerID = New-AzureADGroup -DisplayName « BastionOwners » -MailEnabled $false -SecurityEnabled $true -MailNickName « BastionOwners »

$OwnerID

clip_image006

 

Ce groupe devra disposer des privilèges, on va retenir Owner.

$roleid = (Get-AzRoleDefinition -Name Owner).id

$roleid

clip_image007

 

Le contenu de notre package est disponible sur ce repo Github : https://github.com/Benoitsautierecellenza/ManagedApplication/blob/master/Bastion.zip

La construction d’une interface graphique, c’est un fichier JSON : CreateUiDefinition elements. Ce qui est intéressant, c’est qu’il est possible de tester individuellement cette interface à l’aide du script SideLoad-CreateUIDefinition.ps1. Ce script va mettre à disposition notre fichier « createUiDefinition.json » dans un Storage Account accessible via une clé SAS. Nous serons directement connectés au portail Azure pour déployer notre application.

. .\SideLoad-CreateUIDefinition.ps1 -storageContainerName « test456 » -StorageResourceGroupLocation « WestEurope » -createUIDefFile .\createUiDefinition.JSON

clip_image009

 

L’instance de l’Azure Managed Application doit être hébergé dans un groupe de ressources dédié à cet usage (sans aucune autre ressources).

clip_image011

 

Mon application ayant pour objectif de mettre à disposition une machine virtuelle de type Bastion (sur socle Windows), le consommateur doit définir un compte Administrateur local ainsi que le mot de passe associé. Ce qui est intéressant à ce niveau, c’est que l’interface supporte les expressions régulières : CredentialsCombo.

clip_image013

 

Autre point intéressant, on peut filtrer la liste des tailles de machines virtuelles pour le SizeSelector. C’est plus intéressant que d’exprimer la limitation dans le template ARM.

clip_image015

 

Etape n°3 : Publication de notre application

L’application doit être mise à disposition dans notre application. En PowerShell, c’est la commande New-AzManagedApplicationDefinition qui va nous intéresser.

New-AzManagedApplicationDefinition -Name Bastion -ResourceGroupName ManagedApplications -DisplayName « Bastion as a service » -Description « Provide a bastion as a service » -Location « WestEurope » -LockLevel ReadOnly -PackageFileUri https://raw.githubusercontent.com/Benoitsautierecellenza/ManagedApplication/master/Bastion.zip -Authorization « $($ownerid.ObjectId):$RoleID »

clip_image017

 

Ça c’est pour la version simple (publier dans une souscription). Pour ceux qui veulent industrialiser le déploiement, un Export de BluePrint a été mis à disposition ici. Pour ceux que cela intéresse, un petit rappel : Découverte d’Azure BluePrint. Vu que c’est du déjà vu, on va se contenter de la version courte avec l’import avec Manage-AzureRmBluePrint. Après avoir cloné le repo depuis Azure Cloud Shell, ne reste plus qu’à réaliser l’import. C’est du prêt à consommer.

$SourceDirectory = « /home/by/ManagedApplication/DeployManagedApplications »

$DestinationSubscription = « <SubscriptionID> »

$Managementgroup = « <Management Group name> »

Manage-AzureRMBlueprint.ps1 -Mode Import -Module Az -ImportDir $SourceDirectory -SubscriptionID $DestinationSubscription -ManagementGroup $Managementgroup -Force

clip_image019

 

Je passe sur la publication du BluePrint pour m’attarder sur son assignation. Le template ARM qui est derrière (disponible ici) a besoin d’un certain nombre d’informations pour réaliser la publication, on retrouve donc les mêmes paramètres que pour la publication en PowerShell. Pour ceux que cela intéresse, c’est la classe ‘Microsoft.Solutions/applicationDefinitions’. Pour la structure du template ARM, c’est pas vraiment documenté en ARM, j’ai donc été chercher les informations à la source : Application Definitions – Create Or Update.

clip_image021

 

Avec le BluePrint mis à disposition ici, on devrait avoir un résultat comme illustré ci-dessous :

clip_image023

 

Etape n°4 : Consommer notre application

L’application étant représentée par un objet dans le portail Azure, on peut déclencher son déploiement à partir de là, avec le bouton « Deploy from definition ».

clip_image025

 

De là, on va retrouver l’interface de l’application (celle mise à disposition dans le fichier createUiDefinition.Json), je ne repasse donc pas dessus. Seul point d’attention, on doit déployer l’application dans un groupe de ressources vide.

clip_image026

 

Ce qui est intéressant, c’est le double déploiement qui va avoir lieu. Le premier déploiement, c’est l’application dans notre groupe de ressources.

clip_image028

 

Avec un peu de patience, on découvre notre application déployée. Un premier point d’attention avec la section « Parameters And Output.

clip_image030

 

Cette section référence les paramètres renseignés pendant le déploiement (qui en fait étaient des Outputs du fichier createUiDefinition.Json) pour alimenter en paramètres le template ARM mainTemplate.JSON)

clip_image032

 

Point intéressant dans ces paramètres, le paramètre expiration. Il référence une date à sept jours dans le futur. Cela me sera utile dans le template ARM mainTemplate.JSON pour positionner un tag de date d’expiration automatiquement. Le language utilisé pour générer l’interface graphique est assez riche : CreateUiDefinition functions. La section Output référence elle l’adresse IP privée de la carte réseau associée à la machine virtuelle nouvellement créée (aucune chance que la machine virtuelle soit exposée sur Internet).

Allons faire un tour dans le Managed Resource Group. C’est le groupe de ressources dans lequel toutes les ressources de notre application ont été déployées.

clip_image034

 

Ce qui est intéressant avec Azure Managed Application, c’est que même si nous avons la possibilité de supprimer l’instance de l’application déployée, nous ne pouvons en aucun cas toucher aux ressources mises à disposition. Dans mon contexte, je suis assuré que les caractéristiques des ressources liées à la machines virtuelles ne peuvent pas être altérées (ajout d’une adresse IP publique par exemple). Un Lock a été positionné sur le groupe de ressources mais même avec le rôle « Owner », je suis incapable de le supprimer.

 

Benoît – Simple and Secure by design but Business compliant

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.