Migrer une machine virtuelle entre régions Azure

Voilà un cas client qui m’a occupé un certain temps. Mon client déploie une application basée sur des services IaaS à l’aide d’images préalablement générées. Mes images « sources » sont localisées dans la région Azure France Central et doivent être mise à disposition dans la région Brazil South. Voilà pour le besoin de base.

Mon premier réflexe a été de rechercher si un service de réplication d’images n’existait pas. On a bien un repository pour les images pour les conteneurs (Azure Contrainer Registry), on doit donc avoir le même type de service pour le IaaS. C’est effectivement le cas, cela se nomme Shared Image Gallery. Mais, j’ai tout de suite exclu ce choix car :

  • Service actuellement en Preview
  • Pas encore disponible dans les régions Azure qui me concernent

Second réflexe, Azure Site Recovery. Cela fait quelques temps que l’on peut utiliser le service pour « cloner » une machine virtuelle existante pour assurer un DRP vers une autre région Azure. Très rapidement, j’ai dû abandonner cette option car les régions Azure source et destination ne dépendent pas du même cluster géographique.

clip_image001

Source : https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-support-matrix

Pire, le cas de la région Azure Brazil South est un peu particulier car au sein de son Géo, il n’a pas de région Azure associée. Bref, pas la bonne solution.

En dernier ressort, je suis tombé sur cet article : Synchronously copy all managed disks of an Azure Virtual Machine to Azure Storage Accounts in multiple Azure regions. C’est presque ce qu’il me faut car il faudra reconstruire une image après. A mes yeux, la démarche proposée avait quelques défauts :

  • On paie une VM pour faire la copie avec AZCopy alors qu’on peut faire un job de copie
  • Elle est un peu salée la VM en SKU E pour de la copie de fichiers
  • Les opérations sont réalisées en séquentielle alors qu’on se contente de suivre un job.

J’avais déjà publié un billet pour cloner des machines virtuelles dans Azure. J’ai donc juste poussé la logique d’industrialisation jusqu’au bout. Cela va se dérouler en plusieurs étapes :

  • Etape n°1 : Initialisation
  • Etape n°2 : Génération des clés SAS pour les VHD
  • Etape n°3 : Initialisation des opérations de copie
  • Etape n°4 : Suivi des opérations de copie
  • Etape n°5 : Reconstruction des Managed Disks

 

Etape n°1 : Initialisation

Avant de commencer, on va poser quelques bases. J’ai déployé une machine virtuelle en utilisant mon image dans le groupe de ressources « FranceCentral ». L’objectif est d’obtenir des Managed Disks dans le groupe de ressources « BrazilSouth » dans lequel on va préalablement avoir créé un Storage Account qui va être utilisé pour réceptionner les VHD à copier.

$SourceResourceGroup = « FranceCentral »

$SourceVMName = « MASTER »

$dataDiskNames = New-Object System.Collections.ArrayList

$dataDiskSASes = New-Object System.Collections.ArrayList

$SasKeyDuration = 36000

$DestinationResourceGroup = « BrazilSouth »

$DestinationStorageAccount = « brazilreplication »

$Accounttype = ‘Standard_LRS’

$VM = Get-AzureRmVM -ResourceGroupName $SourceResourceGroup -Name $SourceVMName -Verbose

clip_image002

 

Etape n°2 : Génération des clés SAS pour les VHD

Pour chaque disque composant notre machine virtuelle, nous devons générer une clé SAS. J’ai volontairement configuré une durée de vie assez longue, ne voulant pas tomber dans une situation ou les clés SAS auraient échouées pour cause d’une copie beaucoup trop longue.

$osDiskName = $VM.StorageProfile.OsDisk.Name

$osDiskSAS = (Grant-AzureRmDiskAccess -Access Read -DiskName $osDiskName -ResourceGroupName $SourceResourceGroup -DurationInSecond $SasKeyDuration -Verbose).AccessSAS

foreach($dataDisk in $VM.StorageProfile.DataDisks)

{

$dataDiskNames.Add($dataDisk.Name) | Out-Null

}

foreach($dataDiskName in $dataDiskNames)

{

$dataDiskSASes.Add((Grant-AzureRmDiskAccess -Access Read -DiskName $dataDiskName -ResourceGroupName $SourceResourceGroup -DurationInSecond $SasKeyDuration -Verbose).AccessSAS) | Out-Null

}

clip_image003

 

A ce stade, si on observe un des objets Managed Disks dans le portail, on peut constater qu’une clé SAS a bien été générée pour chacun d’eux.

clip_image004

 

Etape n°3 : Initialisation des opérations de copie

C’est en ce point que je me suis différencié de l’article Synchronously copy all managed disks of an Azure Virtual Machine to Azure Storage Accounts in multiple Azure regions. Mon besoin n’étant pas de répliquer mes disques dans de multiples régions, pas besoin d’autant d’instance de la machine virtuelle Ubuntu pour réaliser les opérations de copies. En plus, on n’a pas besoin d’attendre. Ça fait bien longtemps qu’AZCopy.EXE supporte la notion de job pour les opérations de copies. En PowerShell, AZCOPY.EXE, c’est Start-AzureStorageBlobCopy. A ce stade, du contenu va commencer à apparaître dans le contenu prévu à cet effet dans le Storage Account localisé dans la région cible.

$DestStorageAccountKeys = Get-AzureRmStorageAccountKey -ResourceGroupName $DestinationResourceGroup -Name $DestinationStorageAccount

$DestStorageContext = New-AzureStorageContext -StorageAccountName $DestinationStorageAccount -StorageAccountKey $DestStorageAccountKeys[0].Value

Start-AzureStorageBlobCopy -AbsoluteUri $osDiskSAS -DestContainer $SourceVMName.ToLower() -DestContext $DestStorageContext -DestBlob $($osDiskName + « .VHD »)

$DatadiskCount = 0

foreach($dataDiskSAS in $dataDiskSASes)

{

Start-AzureStorageBlobCopy -AbsoluteUri $dataDiskSAS -DestContainer $SourceVMName.ToLower() -DestContext $DestStorageContext -DestBlob $(« datadisk-$DatadiskCount » + « .VHD »)

$DatadiskCount +=1

}

clip_image005

 

Etape n°4 : Suivi des opérations de copie

La commande PowerShell Start-AzureStorageBlobCopy initié un job que l’on va suivre. Avantage, on va paralléliser toutes les opérations de copie. Pour suivre cela, on dispose de la commande PowerShell Get-AzureStorageBlobCopyState. La durée des opérations de copie dépendra principalement de la volumétrie de données à répliquer. Pour mes tests, quarante-neuf minutes étaient nécessaires pour répliquer un Managed Disk SATA de 127Go et un autre de 1To.

$StartTime = Get-Date

$StorageOperations = Get-AzureStorageBlob -Container master -Context $DestStorageContext | Get-AzureStorageBlobCopyState

While ($StorageOperations | Where-Object {$_.status -eq « Pending »})

{

$StorageOperations | select-Object Copyid, Status

Start-Sleep -Seconds 10

$StorageOperations = Get-AzureStorageBlob -Container master -Context $DestStorageContext | Get-AzureStorageBlobCopyState

}

$CopyTimeSpan = New-TimeSpan -Start $StartTime -End (Get-Date)

$Totalcopyoperations ='{0:N0}’ -f $($CopyTimeSpan.TotalMinutes)

Write-Host « Copy operation completed in $Totalcopyoperations minutes. »

clip_image006

 

Etape n°5 : Reconstruction des Managed Disks

Il ne nous reste plus qu’à reconstruire des Managed Disks en commençant par construire un objet de type Managed Disk à l’aide de la commande PowerShell New-AzureRmDiskConfig. De, là, il n’y a plus qu’à créer la ressource Azure à l’aide de la commande PowerShell New-AzureRmDisk.

$Container = Get-AzureStorageContainer -Container master -Context $DestStorageContext

$ContainerBaseURI = ($Container.CloudBlobContainer).uri.absoluteuri

$ListVHDs = Get-AzureStorageBlob -Container master -Context $DestStorageContext

ForEach ($VHD in $ListVHDs)

{

$Disksize = ($vhd.Length/1GB) +1

$Vhduri = $ContainerBaseURI + « / » + $vhd.name

$diskName = ($vhd.name).Substring(0, ($vhd.name).lastindexof(« . »))

Write-Host « Creating Managed Disk $diskName in Resource Group $DestinationResourceGroup. »

$diskConfig = New-AzureRmDiskConfig -AccountType $Accounttype -Location ((get-azurermresourcegroup -Name $DestinationResourceGroup).location) -DiskSizeGB $Disksize -SourceUri $vhdUri -CreateOption Import

New-AzureRmDisk -DiskName $diskName -Disk $diskConfig -ResourceGroupName $DestinationResourceGroup

}

clip_image007

 

Maintenant, il y a plus qu’à reconstruire l’image de référence au brésil et supprimer les fichiers VHD.

 

Conclusion

La solution n’est pas parfaite, elle peut encore être améliorée. Si vous être plus de culture Linux, allez lire ce billet : Copy custom vm images on azure. L’approche est sensiblement identique.

 

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

Générer un certificat auto-signé avec Key-Vault

Pour ceux qui comme moi génèrent des certificats depuis longtemps, je suis passé par toutes les étapes (OpenSSL, New-SelfSignedCertificate). Avec Azure, il était logique que je regarde comment générer un certificat auto-signé. Le problème des solutions citées précédemment, c’était que le certificat était généré localement, dans le magasin personnel de la machine. Combien de fois avez-vous oublié le certificat et sa clé privée sur un serveur ou pire sur votre portable.

Avec Azure, l’usage des certificats s’est banalisé. On associe des Service Principals aux applications déclarées dans Azure AD que l’on consomme ensuite dans différents services (Azure Automation aujourd’hui par exemple). Pour cette raison, j’avais rapidement cherché un moyen de générer mes certificats auto-signés directement dans Azure. Logiquement, j’ai commencé par regarder le KeyVault. Une recherche rapide dans le module PowerShell associé me confirme que c’est bien prévu dans les scénarios du produit.

clip_image001

J’ai donc creusé un peu le sujet et voilà la version courte. On commence par préparer un objet CertificatePolicy :

$AutomationcertificateName = « LabAutomation »

$AutomationcertSubjectName = « cn= » + $AutomationcertificateName

$AutomationCertificateLifetimePolicy = 36

$Policy = New-AzureKeyVaultCertificatePolicy -SecretContentType « application/x-pkcs12 » -SubjectName $AutomationcertSubjectName -IssuerName « Self » -ValidityInMonths $AutomationCertificateLifetimePolicy -ReuseKeyOnRenewal

$Policy

clip_image002

 

Vous l’avez bien compris, on peut personnaliser avec beaucoup d’autres paramètres, mais on va faire court. Pour la suite, cela se passe avec la commande Add-AzureKeyVaultCertificate. Point de détail, la commande retourne un status, à nous de suivre jusqu’à ce que le certificat soit délivré :

$AddAzureKeyVaultCertificateStatus = Add-AzureKeyVaultCertificate -VaultName ‘mykeyvaultforcert’ -Name $AutomationcertificateName -CertificatePolicy $Policy

$AddAzureKeyVaultCertificateStatus.status

While ($AddAzureKeyVaultCertificateStatus.Status -eq « inProgress »)

{

Start-Sleep -Seconds 10

$AddAzureKeyVaultCertificateStatus = Get-AzureKeyVaultCertificateOperation -VaultName ‘mykeyvaultforcert’ -Name $AutomationcertificateName

$AddAzureKeyVaultCertificateStatus.status

}

$AddAzureKeyVaultCertificateStatus

clip_image003

 

Notre certificat auto-signé est maintenant dans le KeyVault, pour l’utiliser, ne nous reste plus qu’à l’exporter. La ça se complique un peu, il faut en passer par un peu de Dot.Net avec la classe X509Certificate2Collection. Dans le code ci-dessous, nous générons un fichier PFX contenant, le certificat, sa clé privée, le tout sécurité par un mot de passe (merci de fermer la session PowerShell après usage !)

$PfxCertPathForRunAsAccount = « C:\TEMP\CERTIFICATE.PFX »

$PfxCertPlainPasswordForRunAsAccount = « P@ssw0rd12345 »

$secretRetrieved = Get-AzureKeyVaultSecret -VaultName ‘mykeyvaultforcert’ -Name $AutomationcertificateName

$pfxBytes = [System.Convert]::FromBase64String($secretRetrieved.SecretValueText)

$certCollection = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection

$certCollection.Import($pfxBytes, $null, [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)

$protectedCertificateBytes = $certCollection.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $PfxCertPlainPasswordForRunAsAccount)

[System.IO.File]::WriteAllBytes($PfxCertPathForRunAsAccount, $protectedCertificateBytes)

Get-ChildItem -Path « c:\temp\cert*.* »

clip_image004

 

Ne reste plus qu’à consommer. Avantage de cette approche, le certificat est préservé dans notre KeyVault. Dans mon contexte, Azure Automation est partie intégrante d’une solution en cours de développement, nous réinstancions donc plusieurs fois par jour nos instances.

 

BenoitS – Simple and Secure by design but Business compliant (with disruptive flag enabled)

Ma session au Powershell Saturday 2018

Ce samedi s’est déroulé l’édition française du PowerShell Saturday dans les locaux de Cellenza. Pendant, cette édition, j’ai eu l’occasion de présenter l’avancement sur Resource Group As a Service. Resource Group As a Service est un sujet que j’avais déjà présenté lors du Global Azure Bootcamp de 2018.

clip_image001

A l’époque, on était plus proche du PoC of Concept, entre temps, le développement a beaucoup avancé. Aujourd’hui, nous sommes maintenant plus proche du Minimum Viable Product. L’objectif de cette session n’était pas de présenter la solution en elle-même mais ce que son développement m’a permis d’apprendre sur Azure Function, Azure Automation et sur PowerShell lui-même. C’est donc plus une session de retour sur expérience.

Pour ceux que cela intéresse, la présentation ainsi que les exemples PowerShell présentés sont disponibles à cette URL.

 

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

PoShKeePass un module PowerShell pour KeePass

Je suis un adepte de KeePass depuis longtemps. La solution présente pas mal d’avantages dont d’être certifié par l’ANSSI. Travaillant pour plusieurs clients simultanément, je manipule donc beaucoup de credentials permettant d’accéder aux souscriptions Azure (Avec Multi-Factor authentification cela s’entend). Pour travailler avec le portail pas de problème. Pour les scripts PowerShell, j’ai fini par découvrir le module PowerShell PoShKeePass qui propose un certain nombre de commandes pour manipuler le contenu de notre base de données :

clip_image001

 

En quelques commandes, on peut rapidement accéder à nos secrets :

Import-module PoShKeePass

Get-KeePassDatabaseConfiguration -DatabaseProfileName Personnal

Get-KeePassEntry -DatabaseProfileName Personnal -KeePassEntryGroupPath MyKeePass2018/MyAzure -AsPlainText | format-list

clip_image002

 

Maintenant plus d’excuses pour ne pas sécuriser ses comptes Azure AD à privilèges.

 

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

Cloner des machines virtuelles dans Azure

Avec l’arrivée des Managed Disks, il a été introduit la capacité à cloner ces objets sous forme d’objets Snapshots. Après avoir pas mal joué avec j’y vois plusieurs avantages :

  • Recréer une machine virtuelle à partir d’un snapshot est bien plus rapide que de la restaurer depuis Azure Site Recovery (60Mb/S pour la vitesse).
  • Changer le nom des managed Disks histoire de s’aligner avec notre politique de nommage (genre après une bascule depuis On-Premises avec Azure Site Recovery)
  • Changer le nom de l’objet machine virtuelle (pas le nom du système d’exploitation)
  • Changer la performance des disques utilisés
  • Relocaliser les Managed Disks dans d’autres groupes de ressources (ca ne se déplace pas encore mais on peut cloner)
  • Réaliser une sauvegarde rapide et être en mesure de reconstruire rapidement (updates, opérations de maintenance critiques, mises en production le vendredi, …)
  • Changer l’Availability Zone / Availability Set / région Azure de la machine virtuelle
  • Relocaliser une machine virtuelle sur un autre Virtual network

 

Bref, il y a plein de raisons qui font que cloner une machine virtuelle peut être intéressant. Dans le détail des opérations voilà comment cela se présente :

  • Etape n°1 : Désallouer la machine virtuelle
  • Etape n°2 : Créer des snapshot des managed Disks
  • Etape n°3 : Créer des Managed Disks à partir des snapshots
  • Etape n°4 : Créer une nouvelle machine virtuelle
  • Etape n°5 : Ajouter les disques de données
  • Etape n°6 : Suppression des Snapshots

Etape n°1 : Désallouer la machine virtuelle

Même si l’opération peut être réalisé à chaud, on va quand même désallouer la machine virtuelle histoire de créer une image consistante de tous les Managed Disks. C’est un snapshot de chaque Manage Disks qu’il faudra réaliser. Rappel, désallouer ne veut pas dire shutdown dans le système d’exploitation.

 

Etape n°2 : Créer des snapshot des managed Disks

Nous allons créer autant d’objets Snapshots que de Managed Disks associés à notre machine virtuelle. Le seul disque que l’on ne pourra pas snapshoter. Commencez par identifier les noms Managed Disks associés à votre machine virtuelle. Dans l’exemple ci-dessous ma machine virtuelle comprend un disque OS et un disque de données.

clip_image001

 

Pour chaque Managed Disk, on va utiliser le bouton « Create Snapshot » comme illustré ci-dessous :

clip_image002

 

L’objet Snapshot sera créé dans la même région Azure. Par contre, il est tout à fait possible de créer l’objet dans un Resource Group différent. On peut même change la performance. As-t-on réellement besoin d’avoir notre snapshot en SSD?

clip_image003

Etape n°3 : Créer des Managed Disks à partir des snapshots

Il n’est pas possible de créer une machine virtuelle avec des Snapshots. On doit créer des Managed Disks à partir de nos snapshots.

clip_image004

 

Ici encore, ce qui est intéressant, c’est de pouvoir créer le Managed Disk dans une région Azure, une autre Availability zone. Vu que nous créons l’objet nous pouvons réappliquer notre charte de nommage (ceux qui ont migré des machines virtuelles depuis On-Premises me comprendrons, …).

clip_image005

 

Une fois l’opération terminée, nous devirons avoir autant de Managed Disks que de snapshots comme illustré ci-dessous :

clip_image006

Etape n°4 : Créer une nouvelle machine virtuelle

Avec des disques, nous pouvons créer une nouvelle machine virtuelle. Pour cela nous allons reprendre le Managed Disk contenant notre système d’exploitation. Nous allons utiliser le bouton « Create VM ».

clip_image007

 

Pour la création de la machine virtuelle, il n’y a pas grand-chose à dire.

clip_image008

 

Par contre, à cette étape, il y a un point intéressant. Nous pouvons redéfinir l’Availability zone, voire même l’Availability Set. Il y a même un bonus avec la possibilité de changer à quel Virtual Network la nouvelle carte réseau sera associée.

clip_image009

Etape n°5 : Ajouter les disques de données

N’oubliez pas de redéclarer vos disques de données et de sauvegarder la configuration.

clip_image010

Etape n°6 : Suppression des Snapshots

Conserver les snapshots n’a pas de sens sur le long terme. C’est du stockage facturé, tout comme les Managed Disks. Pensez donc à les supprimer dès que le clonage sera terminé.

clip_image011

 

 

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

Arretons de stocker os tokens Azure avec le module Powershell

Ca faisait quelques temps que j’avais remarqué un comportement « étrange » de certains de mes scripts Azure. Pour beaucoup d’entre eux, je commence par m’assurer avec un Get-AzuremContext que je suis bien authentifié. A ma grande surprise, je découvre que oui, pourtant, je n’ai renseigné aucun credential. Magie ? Nan. J’ai creusé un peu plus le sujet pour redécouvrir le module AzureRM.Profile. Ma recherche m’a amenée sur cette page : Automatic-Context-Autosave avec la découverte de quelques commandes inconnues :

clip_image001

 

Trois commandes ont attiré mon attention :

  • Disable-AzureRmContexteAutoSave
  • Enable-AzurermContextAutosave
  • Get-AzureRmContextAutoSaveSettings

J’ai donc commencé par Get-AzureRmContextAutoSaveSettings avec une surprise. Mes tokens sont bien conservés dans mon profil, c’est la configuration par défaut.

clip_image002

 

En ce qui me concerne, d’un point de vue sécurité, c’est moche. D’une part, je me balade avec les tokens de mes clients (MFA n’est pas encore chez tous et cela ne résout pas toujours le problème). C’est dommage qu’on fasse attention à utiliser des navigateurs en mode privé pour se connecter à Azure si le module PowerShell ignore le même ce concept. D’autre part, cela induit un risque. J’ai tendance à utiliser beaucoup de scripts chez mes différents clients. Avec cette fonctionnalité, je risque de travailler sur la mauvaise souscription sans m’en rendre compte avec un impact tout aussi industriel que le script.

Pour cette raison, j’ai pris l’habitude de désactiver cette fonctionnalité avec la commande Disable-AzureRmContextAutoSave comme illustré ci-dessous :

clip_image003

 

Maintenant, il n’y a plus de risque pour moi.

clip_image004

 

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

Un peu de PowerShell pour gérer les Network Security Groups

De temps en temps, j’ai des clients avec des challenges. Quand on mélange Azure et PowerShell, il y a risque que je réponse présent (même si finalement, je vais me faire mal). Je vous partage donc le challenge du moment. Un de mes clients est en phase de montée en puissance sur Azure avec une exigence, un contrôle strict des flux réseaux entrants et sortants, tout comme il le pratique On-Premises. Tout de suite, ça va faire beaucoup des règles dans les Network Security group. Autant dire tout de suite que le portail ne va pas être d’une grande aide sur le sujet.

Challenge intéressant, challenge Accepté, voici AzureImportNSG.PS1. Ce script PowerShell permet de :

  • Créer l’objet Network Security group (réalise une sauvegarde si existe déjà pour le rollback)
  • Injecter les règles en provenance d’un fichier XML
  • S’assure de la mise en place de la journalisation des flux dans votre instance Log Analytics préférée

clip_image001

Que reste-t-il à faire alors ? Juste lier le Network Security group à l’objet Subnet. Simple and Secure by design ! Et comme il faut pouvoir retravailler les règles, s’il y a un script d’import, il y a aussi un script d’export pour générer notre fichier XML.

clip_image002

Avec cela, plus d’excuse pour ne pas avoir des réseaux en béton. Les deux scripts sont disponibles sur mon repo GitHub.

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

Resource Group As a Service–Enfin l’heure de consommer les API

Après un billet d’introduction et quatre pour la mise en œuvre, il serait peut-être temps de conclure et d’exploiter les API mises à disposition. Pour rappel, notre seconde instance du service Azure Function propose les API suivantes :

 

Avant de pouvoir commencer à consommer, on doit préparer un peu le terrain pour Postman. Pour ceux qui ont suivi le billet Authentifiez vos Azure Function avec Azure AD, ils sauvent que c’est l’heure de la construction des paramètres. Commençons par mettre en place une clé pour Postman au niveau de notre application Azure AD. Ce sera notre secret à consommer depuis Postman.

clip_image001

 

Ensuite, récupérons l’identifiant unique de notre tenant Azure AD (Aka TenantID) avec la commande PowerShell suivante : Get-AzureADCurrentSessionInfo | Format-List

clip_image002

 

Prochaine étape avec l’identifiant unique de notre application Azure AD ainsi que l’URL de Callback pour le retour à Azure Function après authentification. Nous obtiendrons ces deux informations avec la commande PowerShell suivante : Get-AzureRMADApplication -DisplayNameStartWith resourcegroupasaservicepublicapi

clip_image003

 

Maintenant, c’est l’heure de consommer.

 

API Get-AuthorizedSubscriptions

Testons avec la première API : Get-AuthorizedSubscriptions depuis Postman. Pour chaque API, nous allons configurer la méthode d’authentification OAuth 2.0

clip_image005

 

Pour les paramètres, je vous renvoie vers le billet Authentifiez vos Azure Function avec Azure AD. Avec tout cela, on devrait être en mesure de demander un jeton en cliquant sur le bouton Get New Access Token.

clip_image006

 

Normalement, cela devrait nous rediriger vers une mire d’authentification Azure AD. Si tout se passe bien, Azure AD rendra la main à notre application Azure AD via la CallBack URL.

clip_image008

 

Après authentification, on devrait obtenir une interface comme illustré ci-dessous avec un Token que nous allons consommer avec le bouton « Use Token ».

clip_image009

 

Attention, le token obtenu est valable une heure. Passé ce délai, il faudra penser à un demander un nouveau. Si tout se passe bien, notre API Get-AzureAuthorizedSubscriptions devrait finir par nous répondre avec une liste de GUID qui sont en fait la liste des souscriptions qui me sont autorisés pour utiliser le service.

clip_image011

 

Derrière l’appel à l’API nous avons une Azure Function. On peut constater la trace de l’appel à la fonction

clip_image013

 

En fait, quand on regarde le contenu de la table AuthorizedCallers, on comprend que la fonction a récupéré l’identité de l’appelant et recherché si l’utilisateur était autorisé ou non.

clip_image015

 

Dans mon contexte, on comprend que mon compte est autorisé à demander la création de groupes de ressources dans deux souscriptions Azure.

API Get-AuthorizedEnvironments

Chaque utilisateur autorisé sur une souscription est associé à un ou plusieurs environnements. Au final, ce sera un tag sur le groupe de ressources qui sera créé. Côté API, elle attend un paramètre : un identifiant unique de souscription. Ça tombe bien, c’est justement ce que la précédente API nous avait retourné. L’API attend un paramètre nommé SubscriptionID.

clip_image017

 

La demande initiée, on doit pouvoir constater le traitement dans Azure Function. A la lecture des logs, on constate que l’appelant serait autorisé à utiliser une seule valeur pour le tag Environnement.

clip_image019

 

De retour dans Postman, on constate bien que l’appelant pourra uniquement demander la création de groupes de ressources tagués TESTS pour la souscription donnée. Toute demande de création pour un autre environnement sera automatiquement rejetée.

clip_image021

 

API Get-AzureAuthorizedRegions

Resource Group As a service permet de limiter les régions Azure pour la création des groupes de ressources. Quelque part, c’est un peu le rôle de Azure Policy me direz-vous ? Oui mais Azure Policy est intégré à ARM qui n’a aucune idée de qui réalise le déploiement. L’API Get-AzureAuthorizedRegions permet de répondre à cette problématique. Chaque utilisateur accrédité pour une souscription donné est limité à une liste de régions Azure donnée. Logiquement l’API attend un identifiant unique de souscription Azure pour répondre à la question. En retour, nous sommes informés des régions Azure dans lesquelles nous sommes autorisés à demander la création d’un groupe de ressource dans la souscription Azure indiquée en paramètre.

clip_image023

 

Côté Azure Function, on peut voir le déroulement de l’exécution.

clip_image025

 

API Get-AuthorizedCostCenters

Resource Group As a Service contribue à la maitrise des coûts. Chaque groupe de ressources qui sera créé se verra assigné un tag CostCenter. Chaque utilisateur autorisé pour une souscription donnée est associé à une liste de valeurs autorisées pour ce tag. Encore une fois, il faut préciser la souscription Azure pour laquelle on veut connaitre les valeurs du tag qui nous sont autorisées.

clip_image027

 

En retour, on obtient. On une liste des valeurs que l’on pourra utiliser pour demander la création de notre groupe de ressources.

 

API Request-ResourceGroup

On a enfin tous les paramètres pour demander la création d’un groupe de ressources. C’est le rôle de l’API Request-ResourceGroup. A ce niveau, on a un peu plus de monde dans la section Body. En fait, on retrouve beaucoup des informations que nous avons déjà abordées :

  • ResourceGroupName : Pas la peine d’expliquer
  • Region : La région Azure dans laquelle créer le groupe de ressources (doit être autorisée)
  • ProjectName : Tag optionnel
  • SubscriptionID : Pas la peine d’expliquer
  • Environment : Une des valeurs qui nous sont autorisées
  • Backup : Tag optionnel
  • CreatedOn : Tag optionnel
  • SLA : Tag optionnel

 

clip_image029

 

Il faut être un peu patient, entre l’authentification, la création du groupe de ressources et la mise en place des tags, ce n’est pas instantané mais 14 secondes, c’est pas cher payé quand on a toute une équipe de développeurs qui attend la création d’un groupe de ressources pour travailler (je ne parle même pas du TJM cumulé, …).

clip_image031

 

Le résultat

Au final, ce qui nous intéresse, c’est quand même le résultat. Jusqu’à maintenant, on est capable de déclencher la création d’un groupe de ressources dans une souscription Azure.

clip_image001[1]

 

En regardant d’un peu plus près, on retrouve même tous les tags demandés. Pour certains, il y a même eu interprétation (CreatedOn, Owner, …)

clip_image002[1]

 

Pourtant, il y a un truc qui manque, les permissions. C’est là ou Resource Group As a Service a besoin de nous. Si on ne lui dit rien sur ce sujet, il ne fera rien. Par contre, si on lui communique les bonnes indications dans la table AuthorizedIAMTemplateRole, ça changera du tout au tout. Le contenu attendu est le suivant :

  • PartitionKey : L’identifiant unique de votre souscription
  • RowKey : Guid unique au sein de la Partition Key
  • Azure AD Group : Groupe Azure AD qui sera utilisé pour assigner un rôle
  • Role : Nom du Rôle Builtin / custom à assigner au niveau du groupe de ressources
  • Environment : Valeur du tag Environnement

 

Chaque ligne dans la table AuthorizedIAMTemplateRole représente donc une assignation de rôle Builtin / custom pour un environnement donné et une souscription donnée.

C’est grâce à cela que Resource Group As a Service prend tout son intérêt. Les permissions positionnées sur le groupe de ressources dépendront de la valeur du tag Environnment utilisée par le demandeur. Ce qui manque, c’est quelques entrées dans une table Azure. Easy en quelques lignes de PowerShell :

$RGName = « <Groupe de ressources contenant le Storage Account contenant les tables> »

$storageAccountName = « <Nom du storage Account> »

$SubscriptionID = « <Azure Subscription ID> »

$AuthorizedIAMTemplateRoleTableName = « AuthorizedIAMTemplateRole »

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName $RGName -Name $storageAccountName

Import-Module -Name AzureRmStorageTable

$IAMTable = Get-AzureStorageTableTable -resourceGroup $RGName -tableName $AuthorizedIAMTemplateRoleTableName -storageAccountName $storageAccountName

Add-StorageTableRow -table $IAMTable -partitionKey $SubscriptionID -rowKey (new-guid).guid -property @{« AzureADGroup »= »GROUPE »; « Environment »= »TESTS »; »Role »= »Reader »}

clip_image003[1]

 

Si on recommence la création du groupe de ressources, on pourra alors constater qu’il y a bien un assignement de rôle qui a été réalisé pour le groupe Azure AD indiqué et le groupe de ressources nouvellement créé.

$AdGroup = Get-AzureADGroup -SearchString GROUPE

Get-AzureRMRoleAssignment -ObjectID $groupe.ObjectID

clip_image004

 

Maintenant Resource Group As a Service prend tout son sens.Si vous êtes arrivés jusque-là, c’est que votre implémentation manuelle de Resource Group As a Service est opérationnelle, félicitations. Pour les plus fainéants, la prochaine version sera 90% industrialisée et comprendra le déblocage de quelques features actuellement cachées.

 

Benoît – Simple and secure by design but business compliant.