Plongée dans la mesure des usages dans Azure

Un sujet sur lequel je passe un peu de temps en ce moment. Lorsqu’on explique le Cloud, on rappelle toujours une de ses caractéristiques principales : c’est un service mesurable et donc facturable. C’est bien de le dire, encore faut-il pouvoir le prouver, dont acte.

On commence par les classiques avec l’authentification et la sélection de la souscription avec laquelle on désire travailler (jamais présupposer).

$Cred = Get-Credential

Login-AzureRMAccount -Credential $Cred

Select-AzureRmSubscription -SubscriptionName ‘Microsoft Partner Network’

clip_image001

Lorsqu’on creuse la liste des modules PowerShell, il y en a bien un a bien un qui nous intéresse : AzureRMUsageAggregates, lequel ne contient qu’une seule commande. (disponible depuis le module Azure PowerShell 0.9.4).

clip_image002

Donc, ce qu’il faut comprendre, c’est que la commande va nous permettre de faire un dump de tous les usages indépendamment des ressources dont in veut pouvoir mesurer les usages. Conclusion, il faudra affiner le résultat progressivement. Ça tombe bien, c’est le sujet de ce billet.  Pour réaliser le dump initial, en précisant une plage de date :

$startdate = « 01/01/2016 »

$enddate = « 16/05/2016 »

$Usage = Get-UsageAggregates -ReportedStartTime $startdate -ReportedEndTime $enddate -AgregationGranularity Daily -ShowDetails $True

$Usage | Get-Member

clip_image003

On récupère le tout dans la variable $Usage et on regarde ce qu’elle expose. Ce qui nous intéresse, c’est l’attribut UsageAggregations. Voyons quelques exemples, …

$Usage.UsageAggregations | Select -First 20

clip_image004

Visiblement, on a pas mal d’informations. Ce qui serait intéressant, ce serait de pouvoir faire le tri. Pour cela, explorons un peu la structure avec la commande suivante :

($Usage.UsageAggregations | Select -First 1).Properties

clip_image005

Ce qu’il faut comprendre, c’est qu’il y a eu quatre authentifications réalisées en ce premier jour de Janvier 2016. Maintenant, voyons cela à l’échelle de la période :

(($usage.UsageAggregations).properties | Where {$_.MeterName -eq « Users »}).count

clip_image006

OK, on ne peut pas dire que j’ai beaucoup bossé avec cette souscription depuis début janvier 2016. Mesurer l’usage des identités, ce n’est pas le plus intéressant. Le problème, c’est que nous avons pour le moment l’intégralité des mesures d’usages. On va commencer par filtrer uniquement un sous-ensemble qui nous intéresse. Avec l’arrivée d’ARM fin 2014, on pense tout de suite aux groupes de ressources. Voilà notre premier niveau de filtrage. Il faut juste filtrer avec l’attribut InstanceData comme illustré ci-dessous :

($usage.UsageAggregations).properties | Where {$_.instancedata -ne $null} | select -first 1

clip_image007

Lorsqu’on observe la structure, on comprend que cela inclus à la fois l’identifiant de la souscription mais aussi les ressources impliquées. Dans l’exemple ci-dessus, nous avons un groupe de ressources pour lequel il a été mesuré l’usage du service Azure Automation sur la période du 1er janvier 2016. Maintenant qu’on sait comment cela se présente, filtrer selon un groupe de ressources est assez simple :

$UsageRG = ($usage.UsageAggregations).properties | Where {$_.InstanceData -like ‘*resourceGroups/myresourcegroup*’}

$UsageRG.count

$UsageRG | Select -First 1

clip_image008

Plus que 257 entrées de mesure d’usages concernant uniquement mon groupe de ressources. Avec un peu de travail, on arrive à isoler les métriques des usages au sein de ce groupe de ressources :

$UsageRG | Select MeterName | Group-Object MeterName | Select Name

clip_image009

La liste des métriques de mesure d’usage devrait nous aider à comprendre de quoi on parle : Du trafic réseau, du compute du storage en mode page et des transactions, Vous avez deviné ? Oui, c’est bien les composants d’une machine virtuelle. On va se focaliser sur l’aspect stockage et plus particulièrement le nombre de transactions au sein de ce groupe de ressources :

$transactionUsage = $UsageRG | Where {$_.MeterName -like « *Storage Transaction* »}

$transactionUsage.count

$transactionUsage | Select -First 1

clip_image010

Cette mesure est intéressante car elle permet de répondre à une question intéressante : Combien de transaction ma machine virtuelle va-t-elle générer sur mon stockage ? C’est une métrique qui peut avoir une influence sur le coût de notre machine virtuelle.

Avec un peu de travail, on peut retrouver la mesure des usages pour les transactions IOPS réalisées pour la machine virtuelle associée au groupe de ressource pour notre période :

$transactionUsage | Select UsageStartTime,MeterName, Quantity | Out-GridView

clip_image011

Ca nous dit que notre machine virtuelle ne génère pas beaucoup de transactions. Dans un sens, c’est bien, c’est qu’elle ne va pas nous générer des coûts cachés. Est-ce de même pour les IOPS sur les VHD ?

$IOPSUsage = $UsageRG | Where {$_.MeterName -like « Standard IO – Page Blob/Disk (GB) »}

$IOPSUsage.count

$IOPSUsage | select -First 1

clip_image012

Voilà donc la volumétrie disque réalisée sur le/les VHD dépendant de mon groupe de ressources que ma machine virtuelle a utilisé, on va en extraire quelques statistiques :

$IOPSUsage | Measure-Object -Property Quantity -Average -Maximum -Minimum -sum

clip_image013

Remarque : Attention avec le stockage Premium, c’est une métrique distincte.

Autant dire tout de suite que cette machine virtuelle n’est que très peu utilisée, pas plus d’un tiers de Gb au maximum. Maintenant, on comprend l’intérêt de positionner des Tags sur nos ressources, cela simplifie grandement le filtrage de la mesure des usages.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Découverte d’Azure Resource Policy

Depuis l’arrivée du modèle RBAC dans Azure, on est capable de maitriser ce qu’un utilisateur pouvait faire (et ne pas faire) dans une souscription au travers des rôles et Custom-Rôles. Oui, on peut maitriser ce qui est consommé. Par contre comment bloquer l’usage de certaines ressources sous conditions? Par exemple, comment empêcher le déploiement de ressources très couteuse, ou tout du moins mettre en place un processus pour encadrer ces usages au sein de nos souscriptions Azure?

La réponse est venue très récemment (15 avril 2016) avec l’arrivée de la fonctionnalité Azure Resource Policy. Au passage, je recommande la session Deploying, Managing, and Controlling Apps with Azure Resource Manager de la Build 2016 pour éclairer sur le sujet.

Avant de continuer, il faut comprendre une subtilité. Le modèle RBAC se focalise sur les actions qu’un utilisateur peut ou ne peut pas réaliser sur un périmètre donné, le tout au travers des groupes de ressources. Les Resources Policies ne concernent que les ressources, le périmètre peut être global ou limité à un groupe de ressources particulier.

Pour la mise en œuvre, il faut disposer d’une version récente du module AzureRM PowerShell (1.0 de mémoire) pour disposer des commandes suivantes :

clip_image001

 

Pour la suite, ça se complique un peu. Pour exprimer notre politique, nous devons nous exprimer au format JSON. A la base, une politique ressemble à cela :

{

« if » : {

<condition> | <logical operator>

},

« then » : {

« effect » : « deny | audit | append »

}

}

Définir une politique, c’est bien mais on peut être plus subtil que de simplement refuser. Techniquement, on peut :

  • Audit : Autoriser la demande de déploiement et se contenter d’une entrée dans le journal d’audit
  • Deny : Refuser la demande de déploiement et générer une entrée dans le journal d’audit
  • Append : Réaliser le déploiement en complétant celui-ci (exemple ajout de tags par défaut pour la refacturation)

 

 

Cela semble donc assez simple. La condition, c’est que nous voulons trapper lors du déploiement sur la plateforme Azure. Pour exemple, j’ai repris un exemple de la documentation officielle de Resource Manager Policy.

{

« if »: {

« not » : {

« field » : « tags »,

« containsKey » : « costCenter »

}

},

« then » : {

« effect » : « deny »

}

}

Je pense que c’est assez explicite pour comprendre ce qui va se passer si on tentait de déployer la moindre ressource sans aucun tag, … Traduisons cela en PowerShell :

$policy = New-AzureRmPolicyDefinition -Name AccountingCompliancePolicy -Description « Block any Azure deployment without accounting tag » -Policy ‘{

« if »: {

« not » : {

« field » : « tags »,

« containsKey » : « costCenter »

}

},

« then » : {

« effect » : « deny »

}

}’

$Policy

clip_image002

 

La politique a été acceptée. Avec la commande Get-AzureRMpolicyDefinition, on va retrouver notre politique mais aussi d’autres, …

Get-AzureRMPolicyDefinition | Select Name, Properties

clip_image003

 

C’est que par défaut, on a déjà quelques politiques. Celle-ci-dessous permet de s’assurer que nos ressources ne seront déployées que dans les régions européennes (North Europe et West Europe).

clip_image004

 

Mettre en place notre politique, c’est aussi définir un périmètre sur lequel nous voulons appliquer notre politique. On peut l’appliquer à toute la souscription si on veut mais pour les besoins de la démonstration, on va se limiter à un groupe de ressources particulier :

$AzureResourceGroup = Get-AzureRMResourceGroup -ResourceGroupName « ResourceManagerPolicy »

clip_image005

 

Nous avons tout ce qu’il nous faut. On a plus qu’à déclarer une nouvelle association de notre politique pour le groupe de ressources que nous venons de récupérer dans la variable $AzureResourceGroup

$policy = Get-AzureRmPolicyDefinition -Name ‘AccountingCompliancePolicy’

New-AzureRmPolicyAssignment -Name « AccountingCompliancePolicyAssignment » -PolicyDefinition $policy -Scope $AzureResourceGroup.ResourceId

clip_image006

 

Pour s’en convaincre, il n’y a qu’à tester un déploiement depuis le portail avec une simple machine virtuelle sans configurer aucun Tag. Le processus de validation ne nous remonte aucune erreur, logique, du point de vue JSON, le déploiement est conforme.

clip_image007

 

Par contre, on voit bien que par la suite, cela ne se passe pas bien. En consultant le détail, on voit bien qu’il y a eu plusieurs erreurs :

clip_image008

 

On peut consulter chaque erreur, on a la même cause. C’est bien un refus (c’était le but de notre politique). Dans la capture ci-dessous, c’est la création du Storage Account qui a échoué à cause de notre politique Resource Manager Policy :

clip_image009

 

Le nom de l’opération va nous être utile si on veut filtrer pour retrouver les logs en question.

get-azurermlog | where {$_.OperationName –eq « Microsoft.Authorization/policies/deny/action »} | select ResourceGroupName,OperationName, Category, status

clip_image010

 

Si on sait l’identifier, on peut y associer des alertes Ces alertes peuvent :

  • Envoyer un mail sur l’évènement (bof)
  • Déclencher un WebHook sur l’évènement qui va lui-même déclencher un Runbook Azure Automation

Pour finir quelques scénarios intéressants à creuser autour de cette nouvelle fonctionnalité :

  • Exiger la présence de tags / Enforcer la présence de tags dans les déploiements pour la refacturation
  • S’assurer que les ressources ne soient déployées que dans certaines régions
  • Limiter les Resources Providers utilisables
  • Bloquer l’utilisation de certaines fonctionnalités (géo-réplication du stockage par exemple)
  • Bloquer l’utilisation d’éditions particulières d’un Resource Provider (notion de SKU)
  • Imposer notre convention de nommage des objets

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Consommer des secrets Azure Key Vault depuis Visual Studio 2015

Parfois, il y a des mises à jour qu’on voit pas passer et qui nous sauvent la vie quand on les découvre. Je dis découvre car c’est tellement petit en taille sur mon écran qu’on se rend pas compte qu’on passe devant tous les jours. La dernière mise à jour de Visual Studio Community Edition 2015 (L’update 2) est de celle-là. Je passe par là tellement souvent que c’est devenu un réflexe.

clip_image001

 

J’allais renseigner mes paramètres sans réfléchir, jusqu’à ce que ce petit icône attire mon attention.

clip_image002

 

Oh magie, une intégration cachée de l’Azure Key Vault. Premier point qui attire mon attention, une indication d’avertissement sur mon Key Vault.

clip_image003

 

C’est que mon instance du service Key Vault n’est pas encore configurée pour être utilisable pendant les déploiements. Recherche rapide, la configuration actuelle ne permet pas d’utiliser le Key Vault lors d’un déploiement de templates.

clip_image004

 

Je me disais que cela allait être une formalité mais on est toujours en Preview. L’aide de la commande New-AzureRmKeyVault nous indique que c’est pas encore possible de le configurer en PowerShell.

clip_image005

 

En attendant le passage en General Availability, je triche, moi propriétaire du précieux coffre-fort numérique va corriger cela en déclarant un secret directement depuis Visual Studio Community 2015.

clip_image006

 

Y a plus qu’à laisser Visual Studio mettre à jour les fonctionnalités de mon coffre-fort numérique.

clip_image007

 

Par ce que je ne suis pas préteur de mes précieux, je ne donne l’accès qu’au précieux secrets dont mon développeur a besoin. Et encore, uniquement le droit de les consommer­. La subtilité, c’est qu’il doit pouvoir accéder aux clés et aux secrets. Pas plus que la permission Get. C’est suffisant.

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -UserPrincipalName ‘test@XXXXXXXXXX.onMicrosoft.com’ -PermissionsToKeys ‘Get’ -PermissionsToSecrets ‘Get’

clip_image008

 

Une évolution intéressante serait de pouvoir filtrer précisément la clé concernée. C’est pas encore possible à ce jour.Après, y a plus qu’à shooter comme d’habitude. On remarquera qu’on fait référence à une secret qui vient juste d’être mis au coffre-fort numérique.

clip_image009

 

Pour ceux que cela intéresse, le détail de mes paramètres de déploiement. Cela fait bien référence à la variable nouvellement créée.

clip_image010

 

Conclusion, mes développeurs peuvent provisionner des machines virtuelles sans connaitre le mot de passe Administrateur de la machine virtuelle. On peut même pousser la mécanique pour réaliser la jointure au domaine. Combiné avec un truc comme LAPSI alias ADMPWD, c’est parfait.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Injecter un certificat dans une machine virtuelle avec Azure Key Vault

Après ma première exploration de l’Azure KeyVault avec la preview d’Azure Disk Encryption, j’ai décidé de m’attarder sur un autre usage du coffre-fort numérique. Un sujet récurrent dans la gestion des infrastructures, c’est la mise à disposition de certificats dans les machines virtuelles.

Du point de vue de la sécurité, c’est compliqué car cela implique de mettre à disposition le certificat avec sa clé privée sous forme d’un fichier PFX. La seule sécurité, c’est le mot de passe nécessaire pour pouvoir installer le certificat sur un nouveau système. Certes, on peut masquer ce mot de passe, c’est un sujet que j’avais traité dans ce billet : Cacher les mots de passe dans les scripts PowerShell. C’est une approche, mais on peut faire mieux en stockant le couple PFX et mot de passe dans l’Azure Key Vault. C’est le sujet de ce billet.

Pour la démonstration, j’ai réutilisé le coffre-fort numérique que j’avais mis en œuvre dans le billet Cacher les mots de passe dans les scripts PowerShell, ainsi que la machine virtuelle utilisée dans le billet Découverte d’Azure Disk Encryption (Preview).

Un peu de cuisine

Dans les prérequis, il me faut un certificat qui soit exportable. Je viens de l’exporter tout chaud avec sa clé privée.

clip_image001

 

Azure, on commence à connaitre, ce n’est pas la première fois que j’aborde le module PowerShell qui lui est associé. Donc première étape : Authentification. En toute logique, il serait fort judicieux d’avoir activé Azure Multifactor Authentication (MFA) pour sécuriser l’accès à notre coffre-fort numérique.

clip_image002

 

Puis nous devons sélectionner la souscription que nous allons utiliser.

clip_image003

 

Dans mon dernier billet, j’avais mis en œuvre un KeyVault dans le ressource group ‘AzureDiskEncrypt’, nous allons le réutiliser.

$Vault = Get-AzureRmKeyVault -ResourceGroupName ‘AzureDiskEncrypt’

$Vault.VaultName

clip_image004

 

C’est pour l’exemple. Dans la pratique, je recommanderais de séparer les coffre-fort numériques en fonction des usages. D’un point de vue facturation, il n’y a pas de coût à mettre en place un coffre-numérique, nous ne payons que l’usage, l’accès aux secrets protégés.

 

Le stockage des secrets

C’est maintenant que cela commence à se compliquer. On ne doit pas référencer un secret mais bien deux :

  • Le fichier PFX
  • Le mot de passe nécessaire pour accéder à la clé privée

C’est un couple indissociable que nous devons stocker dans notre coffre-fort numérique. Après quelques recherches, c’est un peu plus compliqué que pour les mots de passe. La solution est venue du White Paper Azure Disk Encryption for Windows and Linux Azure Virtual Machines. Pour faire court, nous allons devoir créer un objet JSON contenant :

  • Le certificat encodé en base 64
  • Le type de certificat (PFX, impliquant donc une clé privée sécurisée par un mot de passe)
  • Le mot de passe en lui-même

 

Cet objet JSON sera lui-même encodé en base 64.

$CertFile = ‘C:\Temp\certificat.PFX’

$CertPassword = « Password123 »

$ResourceGroupName = ‘AzureDiskEncrypt’

$fileContentBytes = get-content $CertFile -Encoding Byte

$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)

$jsonObject = @ »

{

« data »: « $filecontentencoded »,

« dataType » : »pfx »,

« password »: « $certPassword »

}

« @

$jsonObjectBytes = [System.Text.Encoding]::UTF8.GetBytes($jsonObject)

$jsonEncoded = [System.Convert]::ToBase64String($jsonObjectBytes)

 

Le secret doit lui aussi faire l’objet d’un encodage mais cette fois, il est tout à fait classique.

$secret = ConvertTo-SecureString -String $jsonEncoded -AsPlainText -Force

clip_image006

 

Maintenant, on a plus qu’à enregistrer notre objet JSON dans le coffre-fort numérique avec la commande suivante.

Set-AzureKeyVaultSecret -VaultName $vault.VaultName -Name ‘SecureCertificate’ -SecretValue $Secret

clip_image008

 

Quelques précisions :

  • Pour raison de sécurité, l’opération nécessitera la confirmation de notre identité
  • La commande permet de spécifier une date interdisant l’usage avant une date donnée
  • La commande permet de spécifier une date interdisant l’usage passé une date donnée

 

Bref, nous, responsable de la sécurité pouvons gérer le cycle de vie de ces secrets en étant assurés qu’ils ne seront utilisables que pendant la période de temps autorisée ou jusqu’à ce qu’ils doivent être annulés.

A ce stade, je conseille d’aller faire un tour dans l’aide de la commande Set-AzureRmKeyVaultAccessPolicy pour comprendre comment nous allons accorder à un utilisateur tiers (le propriétaire de la machine virtuelle par exemple) d’accéder à notre conteneur numérique pour y récupérer le secret positionné. On découvre que bientôt on pourra accorder ce droit à une application référencée dans le portail (soon).

L’injection du secret dans la machine virtuelle

La dernière étape c’est d’injecter ce secret sans avoir accès au secret lui-même. Mieux sans avoir à manipuler ni le fichier PFX et encore moins le mot de passe associé. Pour la suite de ce billet, je pars du principe que le propriétaire de la machine virtuelle s’est vu accordé une permission pour accéder au secret. Ce que nous devons injecter, c’est l’URL de notre secret. Dès lorsqu’on connait le nom du coffre-fort numérique et le nom du secret, la commande ci-dessous va nous retourner l’URL de la dernière version du secret :

$certUrl = (Get-AzureKeyVaultSecret -VaultName $keyVaultName -Name ‘SecureCertificate’).ID

clip_image010

 

Il ne nous reste plus qu’à mettre à jour notre machine virtuelle pour que sa définition fasse référence à ce secret. On va donc commencer par récupérer sa configuration dans une variable pour l’enrichir et mettre à jour la machine virtuelle :

$vm = Get-AzureRmVM -ResourceGroupName ‘AzureDiskEncrypt’ -Name ‘AzureVM01’

$vm = Add-AzureRmVMSecret -VM $vm -SourceVaultId $vault.ResourceId -CertificateStore « My » -CertificateUrl $CertURL

Update-AzureRmVM -VM $vm -ResourceGroupName « AzureDiskEncrypt »

clip_image011

 

Explorons un peu la nouvelle configuration de la machine virtuelle :

$Vm.OSProfile.Secrets | Format-List

$Vm.OSProfile.Secrets.SourceVault

$Vm.OSProfile.Secrets.VaultCertificates

clip_image012

 

On retrouve bien la référence à notre coffre-fort numérique et au secret injecté. Dans la machine virtuelle, je retrouve bien le certificat :

Get-ChildItem Cert:\Localmachine\My

clip_image014

 

Y a même la clé privée qui va avec

clip_image016

Que demander de plus?

En fait pas grand-chose. Si on dispose bien d’une commande pour injecter un certificat dans une machine virtuelle, nous n’avons pas la possibilité de le retirer. Il faudra donc révoquer le certificat.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Azure Stack Incremental release for Technical preview 1

    J’avais un peu laisse de côté ma plateforme MAS (Microsoft Azure Stack) par manque de temps. Ce matin, j’ai eu l’heureuse surprise de découvrir ce billet de l’équipe MAS : Announcing incremental release for Azure Stack Technical Preview 1.

    MAS est une plateforme encore en cours de développement et l’équipe produit attend beaucoup de nos retours. Cette mise à jour incrémentielle inclus :

  • Une amélioration du temps de déploiement des machines virtuelles
  • Une amélioration des performance dans les actions d’arrêt, démarrage et suppression des machines virtuelles
  • Des améliorations sur la stabilité du portail (c’était nécessaire)
  • L’intégration des VM extensions pour DSC et Docker pour la cohérence avec Azure.

 

    Bref, que du bon. Le seul bémol, c’est que c’est une mise à jour incrémentielle de la TP1. Cela signifie que ce n’est pas une mise à jour à installer mais bien une réinstallation de ma plateforme avec les sources disponibles ici. Tout cela pour rappeler que MAS est encore en cours de développement, qu’il n’est pas encore assez mature pour un usage en production.

    BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Découverte d’Azure Disk Encryption (Preview)

Le billet « Cacher les mots de passe en Powershell » ayant eu beaucoup de succès, j’ai décidé de passer un peu plus de temps sur Azure Key Vault. En creusant un peu, on comprend qu’elle permet de stocker un grand nombre de secrets, y compris les clés de chiffrement de Bitlocker, ce qui nous amène au service Azure Disk Encryption, encore en Preview au moment où je rédige cet article. Linux n’étant pas encore ma tasse de thé, ce sera donc à Windows que je vais consacrer mon billet.

Le couplage d’Azure Disk Encryption avec Azure Key Vault est une évidence : Remplacer le TPM que nous avions On- Premises pour y stocker notre secret. Azure Key Vault étant un service Cloud, il est capable de stocker bien plus qu’un secret avec un niveau de sécurité bien plus élevé. Pour information, les instances « Premium » du service Azure Key Vault sont hébergées sur des boitiers HSM Thales certifiés FIPS 140-2 Level 2. Pourquoi s’en priver?  La mise en place s’effectuera selon les étapes suivantes :

  • Mise en place des prérequis
  • Activation pour le disque OS de notre VM IaaS
  • Constats dans la machine virtuelle

 

Mise en place des prérequis

Azure Disk Enryption nécessite la version 1.1.0 du module Powershell Azure Active Directory. Une rapide commande « Get-Module Azure -ListAvailable » nous inique que j’ai bien la version minimale.

clip_image001

 

Ceci vérifié, on peut s’attaquer au grand classique de l’authentification avec Login-AzureRmAccount.

clip_image002

 

Et sélectionner la souscription que nous allons utiliser avec les commandes Get-AzureRMSubscription et Select-AzureRMSubscription.

clip_image003

 

Pour travailler, nous allons avoir besoin d’une machine virtuelle qui a été provisionnée dans le groupe de ressources AzureDiskEncrypt, ce que j’ai bien avec les commandes suivantes :

Get-AzureRMresourceGroup -Name AzureDiskEncrypt

Get-AzureRMVM -Resourcegroupname ‘AzureDiskEncrypt’ | Select ResourcegroupName, Name, Location, ProvisioningState

clip_image004

 

Dans mon dernier billet, j’avais mis en œuvre un Key Vault dans son édition standard. Cette fois, j’utilise l’édition Premium, juste pour bénéficier du stockage sur un HSM certifié FIPS 140-2 Level 2. Comme indiqué plus tôt, à ce tarif, ce serait criminel de ne pas l’utiliser. La commande suivante va nous permettre de créer mon coffre-fort numérique dans le même groupe de ressources pour raisons de simplicité. Donc allons y :

New-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEnrypt’ -Location ‘North Europe’ -SKU ‘Premium’.

clip_image005

 

Remarque: Une limite à connaitre, le Key vault que nous allons utiliser pour la fonctionnalité Azure Disk Encryption doit nécessairement dépendre de la même région Azure que les machines virtuelles sur lesquelles nous allons activer la prise en charge. Dans un sens c’est logique, ou alors on devrait accepter que les secrets sortent d’une région et donc d’un Datacenter.

Notre coffre à secrets est en place et accessible via une URL. Pour l’instant, je suis le seul à avoir tous les privilèges, ce qui est normal en tant que créateur. A ce stade, on peut constater que notre coffre-fort numérique n’est pas éligible aux fonctionnalités qui nous intéresse. Nous allons y remédier avec les commandes Powershell suivantes :

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEncrypt’ -EnabledForDiskEncryption -EnabledForDeployment

Get-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEncrypt’

clip_image006

 

Je vois tout de suite qu’il y en a qui se demandent pourquoi l’option ‘-EnabledForTemplateDeployment’ n’a pas été utilisée. La réponse est venue de la documentation de la commande New-AzureRmKeyVault : « Note: This parameter is not currently implemented. ». On est bien en Preview.

 

On arrive bientôt à la fin des prérequis, plus que deux. Pour que nos machines virtuelles puissent utiliser notre coffre-fort numérique, il nous faut deux choses :

  • Une identité que nos machines virtuelles pourront utiliser pour accéder à notre coffre-fort numérique (plus précisément l’extension de machine virtuelle)
  • Une ressource à laquelle nous allons accorder des accès.

Il m’a fallu un peu de temps pour comprendre le modèle mais c’est logique. Pour piloter la mise en place de la fonctionnalité Azure Disk Encryption, nous allons injecter un agent dans la machine virtuelle. Du point de vue de Windows Azure Active Directory, notre machine virtuelle n’a pas d’identité, il faut donc l’aider en lui fournissant une identité, laquelle sera utilisée pour accéder au coffre-fort numérique.

Au moment où je rédige ce billet, Windows Azure Active Directory est encore disponible uniquement depuis l’ancien portail. C’est donc depuis celui-ci que nous allons déclarer une nouvelle application dans notre tenant Windows Azure Active Directory.

clip_image007

 

L’application référencée pointera directement sur l’URL de la ressource de notre coffre-fort numérique.

clip_image008

 

C’est là qu’intervient une subtilité. Pour configurer notre agent, il va avoir besoin de deux informations :

  • Un Client ID
  • Une clé.

clip_image009

 

C’est un peu comme un login & Mot de passe. Nous allons garder ces informations dans un coin. On va commencer par autoriser l’accès au coffre-fort numérique pour cette identité avec la commande Powershell suivante : Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -ServicePrincipalName ‘<ClientID>’ -PermissionsToKeys All -PermissionsToSecrets All

clip_image010

 

Pour vérifier que cela fonctionne, il suffit s’afficher les caractéristiques de notre coffre-fort numérique avec la commande Get-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’. On constate que le ClientID que nous avons fourni a été reconnu. Pour simplifier, j’ai volontairement simplifié la mise en œuvre. Dans un véritable déploiement, on limiterait l’accès à certains types de secrets, voire jusqu’à segmenter en plusieurs coffre-fort numériques en fonction des usages. Si ça vous intéresse, l’aide en ligne de la commande PowerShell Set-AzureRmKeyVaultAccessPolicy est un bon point de départ.

Activation pour le disque OS de notre VM IaaS

C’est maintenant que cela commence à devenir intéressant. Pour commencer on va personnaliser le portail pour faire apparaitre une nouvelle colonne. Pour l’instant, le service Azure Disk Encryption est bien désactivé.

clip_image011

 

On peut avoir le même résultat avec la commande Powershell suivante  : Get-AzureRMVMDiskEncryptionStatus -ResourceGroupName ‘AzureDiskEncrypt’ -VMName AzureVM01

clip_image012

 

L’information est ici plus précise puisqu’on sépare le statut du disque OS des éventuels disques de données. Dernière étape, l’activation de l’agent de chiffrement dans notre machine virtuelle. Pour commencer, on va mettre de côté quelques informations sur notre coffre-fort numérique avec la commande Powershell suivante : $Vault = Get-AzureRMKeyVault -Resourcegroupname ‘AzureDiskEncrypt’ -VaultName ‘MyKeyVaultHSM’

clip_image013

 

On a tout ce qu’il nous faut, on passe au tour de magie. L’installation de l’agent va nécessiter le redémarrage de notre machine virtuelle ainsi qu’un peu de temps pour activer Bitlocker. Voilà la formule magique :

Set-AzureRMVMDiskEncryptionExtension -ResourceGroupName ‘AzureDiskEncrypt’ -VMName ‘AZUREVM01’ -AadClientID ‘<Identifiant Client ID de l’application dans le portail>’ -AadClientencryptionKeyVaultURL $vault.VaultUri -DiskEncryptionKeyVaultID $Vault.ResourceId

clip_image014

 

Après quelques minutes et un redémarrage de la machine virtuelle, la commande Powershell rend la main en nous indiquant un succès. Un rapide Get-AzureRMVMDiskEncryptionStatus -ResourceGroupName ‘AzureDiskEncrypt’ -VMName AzureVM0’1 nous confirme que le chiffrement est bien activé, au moins pour le disque OS pour lequel on a maintenant un secret dans le coffre-fort numérique.

Logiquement, si on a activé la fonctionnalité Bitlocker, on devrait avoir des secrets dans notre coffre-fort numérique. Je dis bien des secrets car au minimum, une machine virtuelle est composée de deux disques dur :

  • Le disque OS
  • Le disque temporaire

C’est pour cela que la commande Get-AzureKeyvaultSecret -VaultName ‘MyKeyVaultHSM’ nous indique deux secrets.

clip_image015

 

Constats dans la machine virtuelle

On a passé assez de temps dans les nuages, allons constater que notre système d’exploitation a bien activé Bitlocker. Juste après l’authentification, un joli message nous indique que cela se présente bien :

clip_image016

 

Dans le détail, effectivement, ça se présente même très bien dans le panneau de configuration.

clip_image017

 

Pour finir, comme j’aime de moins en moins des interface graphiques, je repasse en Powershell avec la commande Get-BitlockerVolume :

clip_image018

 

Là, les résultats sont sans appel. On a bien deux volumes pour lesquels Bitlocker est activé (dont un en cours d’activation). Y a juste une subtilité qui m’échappe. Le KeyProtector indique ‘ExternalKey’. Elle est ou cette clé. Pour rappel, n’a pas de TPM. La réponse m’est apparue quelques minutes plus tard en regardant l’explorateur Windows.

clip_image019

 

Ce nom ne m’est pas inconnu, allons revoir les secrets dans notre coffre-fort numérique

Get-AzureKeyVaultSecret -Vaultname ‘MyKeyvaultHSM’ | Select Name

Get-AzureKeyVaultSecret -Vaultname ‘MyKeyvaultHSM’ -name ‘EBCAF0E6-3AAB-4234-9B64-AB84DCC1A0DA’

clip_image020

 

C’est la clé Bitlocker. La VM Extension utilise donc un disque additionnel pour y placer le secret qu’elle a extrait de mon coffre-fort numérique.

 

Conclusion

La fonctionnalité est encore en Preview mais vu que seul l’accès aux secrets est facturé 0,8433€ par secret par mois, ce sera une fonctionnalité obligatoire lorsqu’elle passera en General Availability. 1€ pour stocker des clés de chiffrement dans des boitiers HSM Thales certifiés FIPS 140-2 Level 2, ce serait criminel de s’en passer. Pour rappel dans le Cloud, la responsabilité de vos ressources et contenu de votre tenant est sous votre responsabilité. Microsoft fournit les moyens de sécuriser nos ressources, nous seuls sommes responsables en cas d’incident de sécurité.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Gabarit de certificat pour utiliser CMSMessage de Powershell 5.0

Honte à moi. Un certificat auto-signé dans mon dernier billet. J’avoue, je l’ai écrit sur mon canapé, et uniquement survolé la page Technet avant de me rendre compte de mon impardonnable erreur. Vu que le Technet ne donne pas les spécifications du gabarit de certificat à utiliser pour ADCS, je m’y colle en pénitence.

Comme base de travail, j’ai retenu le gabarit user. Pourquoi? Car je compte limiter ce type de certificats aux seuls comptes de services membres d’un groupe spécifique. Pas besoin que tous mes systèmes disposent de ce type de certificat. En plus avec ce choix, je vais limiter l’accès à ce certificat aux seuls comptes de service et non la totalité des comptes qui peuvent accéder au magasin personnel de l’ordinateur avec des privilèges administrateur ou supérieur.

Après, vu que pour utiliser la fonctionnalité CMSMessage, il faut PowerShell 5.0, j’ai choisi de limiter les systèmes éligibles en conséquences. Pour installer de Windows Management Framework 5.0, il faut au minimum un système d’exploitation de génération Windows 7 / Windows 2008 R2.

clip_image001

Dans l’onglet général, on nomme notre nouveau gabarit de certificat « CMS Message », pas grand-chose à dire sinon que ça ne sert à rien de publier le certificat dans l’Active Directory dans notre cas.

clip_image002

Dans l’onglet « Request Handeling », une seule chose compte, la capacité à exporter la clé privée. C’est grâce à elle qu’on sera en mesure de déchiffrer notre CMSMessage.

clip_image003

Pour la construction du Subject Name, il y a eu un peu de travail. Par défaut, le gabarit de certificat était prévu pour construire l’attribut en utilisant les informations issues de l’annuaire Active Directory. Bien, mais le problème, il est rare qu’un compte de service ou même un ordinateur se voit affecté une adresse de messagerie. Pour cela, j’ai dû procéder à quelques adaptations :

  • Ne pas inclure l’adresse de messagerie dans l’attribut Alternate Subject Name
  • Ne pas inclure l’attribut E-Mail
  • Ne pas inclure le DNS Name (pas de sens pour un utilisateur)
  • Mais bien inclure un UPN

clip_image004

C’est maintenant qu’il faut introduire la subtilité. Pour que la commande Protect-CMSMessage accepte d’utiliser notre certificat, il doit avoir un rôle bien particulier. Pas de bol, il est pas dans le gabarit de certificat que nous avons utilisé comme base de travail. Qu’à cela ne tienne, on va le personnaliser.

clip_image005

Pour être sûr que notre certificat ne soit pas détourné pour un autre usage, on va faire le ménage dans les EKU et ne positionner que « Document Encryption ».

clip_image006

Maintenant, c’est mieux.

clip_image007

On approche de la fin. Ne pas limiter la capacité d’enregistrement de certificat, c’est la porte ouverte à toutes les fenêtres, des certificats délivrés à gogo sans se soucier qu’un jour il faudra les renouveler, ce qui bien sûr arrive toujours au pire moment. En limitant la capacité d’enrôlement aux seuls membres d’un groupe, on saura déjà à qui on a délivré ces certificats.

clip_image008

Y a plus qu’à publier notre gabarit de certificat et Zou, à la signature.

clip_image009

Une fois la session ouverte avec notre compte de service, on peut réaliser la demande.

clip_image010

C’est fini. Pour s’assurer que cela fonctionne, une rapide commande Powershell « Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert » nous confirme que nous avons bien un certificat prévu pour cet usage dans le magasin. Vu que c’est le cas, y a plus qu’à chiffrer notre message :

$Cert = Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

$CMSMessage = Protect-CMSMessage -Content « Ilachangé! » -To $Cert/Thumbprint

clip_image011

 

Aller, je retourne me punir, j’ai du python sur le feu. Je ne déconne pas

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Cacher les mots de passe dans les scripts Powershell

Nous passons tous beaucoup de temps à industrialiser avec PowerShell. Il n’est pas rare que je retrouve les mots de passe codés en dur dans les scripts. Pour éviter ces dérives, j’ai compilé dans ce billet quelques méthodes pour cacher ces mots de passe, du plus simple, au plus sexy

En PowerShell, la gestion des credentials est quelque chose que nous semble très simple. On sait tous que l’on peut « sécuriser » les mots de passe avec le fameux ConvertTo-SecureString. Le problème, c’est que cette fonction est réversible avec la méthode « Get-NetworkCredential ». Pour vous donner une idée, une rapide démonstration :

clip_image002

Le problème, c’est que dans l’exemple ci-dessous, PowerShell utilise Windows Data Protection API (DAPI). Cela signifie que seul le même compte est capable de chiffrer/déchiffrer notre secret. Stocker l’information dans un fichier ou dans le registre. On va devoir ruser pour ne pas utiliser une clé de chiffrement locale au système d’exploitation. Si on creuse un peu la commande ConvertFrom-SecureString, on trouve deux paramètres intéressants :

clip_image004

Donc si on utilise une clé externe de taille assez grande, on devrait être capable de chiffrer nos données en étant indépendant du système d’exploitation. Commençons par chiffrer notre information avec notre nouvelle clé.

$ScriptPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

[Object] $Cred = $null

[Guid] $Key = « e8bdc7c5-a62c-4fa3-9228-5abe22488141 »

[String] $CredFile = « $ScriptPath\CredData.ps1xml »

if ( $Cred -isnot [System.Management.Automation.PSCredential] )

{

[Object] $Cred = (Get-Credential -Message « Service Account »)

[Object] $CredData = $Cred | Select-Object -Property UserName,@{Name= »SecurePassword »; Expression={ ConvertFrom-SecureString -SecureString $_.Password -Key $Key.ToByteArray() }}

$CredData | Export-CliXml -Path $CredFile -Encoding Unicode -Force

Remove-Variable -Name CredData -Force

}

Get-Content $CredFile

clip_image006

Logiquement, on doit pouvoir faire l’inverse facilement avec le script suivant :

$ScriptPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

[Guid] $Key = « e8bdc7c5-a62c-4fa3-9228-5abe22488141 »

$CredFile = « CredData.ps1xml »

[Object] $CredData = Import-CliXml -Path ($ScriptPath + »\ » + $CredFile)

if ( $? )

{

$SecurePassword = ConvertTo-SecureString -String $CredData.SecurePassword -Key $Key.ToByteArray()

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList ($CredData.UserName, $SecurePassword)

$Credential.GetNetworkCredential() | Format-Table *

}

clip_image008

Note : On m’a fait remarqué cette semaine que cela aurait été encore mieux d’utiliser le paramètre « -SecureKey ». Notre clé aurait alors été encodée dans un System.Security.SecureString. Merci Sylvain.

Le problème, c’est que ma clé est lisible dans le script. Ce qu’il faudrait, c’est de pouvoir la disposer d’un mécanisme me permettant de chiffrer des données avec une clé qui soit reconnue d’autres systèmes mais qu’on ait pas besoin de la même clé. Un truc comme une clé asymétrique. Chiffrer des données avec un certificat, c’est utiliser la clé publique pour cela. Pour déchiffrer, on aura besoin de la clé privée. Nous allons avoir besoin d’un certificat qui devra être présent :

  • Sur le système qui assure le chiffrement du message (en l’occurrence un mot de passe)
  • Sur les systèmes qui devront accéder à cette information

Cela implique que le certificat que nous allons demander devra être :

  • Reconnu comme issu d’une autorité de certification reconnue de toutes les parties
  • Être exportable

Ces points techniques résolus, attaquons nous au chiffrement de notre message avec quelques lignes de PowerShell :

$cert=Get-ChildItem Cert:\LocalMachine\my | where {$_.Subject -like « CN=Powershell Authentification* »}

$Password = ‘Il a changé!’

$EncodedPassword = [System.Text.Encoding]::UTF8.GetBytes($Password)

$EncodedBytes = $Cert.PublicKey.Key.Encrypt($EncodedPassword, $True)

$EncryptedPassword = [System.Convert]::ToBase64String($EncodedBytes)

clip_image010

Quelques explications s’imposent. On commence par localiser le certificat que nous allons utiliser et encoder notre mot de passe au format UTF8. Ceci-fait, on encode notre mot de passe à l’aide de la clé publique de notre certificat et con convertit le tout en Base 64. Ca ressemble plus du tout à notre mot de passe. On peut communiquer cela tel que, aucun risque que cela puisse être décodé sans la privée. Justement, allons voir comment décoder cela sur un autre système avec un peu de PowerShell :

$cert=Get-ChildItem Cert:\LocalMachine\my | where {$_.Subject -like « CN=Powershell Authentification* »}

$Encryptedcontent = Get-Content .\secret.txt

$Encryptedcontent

$EncryptedBytes = [System.Convert]::FromBase64String($Encryptedcontent)

$DecryptedBytes = $Cert.PrivateKey.Decrypt($EncryptedBytes, $True)

$DecryptedPassword = [System.text.Encoding]::UTF8.GetString($DecryptedBytes)

clip_image012

Si on a compris la logique, on commence par reconvertir notre contenu en une chaine de caractères pour laquelle on va utiliser la clé privée de notre certificat pour déchiffrer notre message. L’avantage de cette approche est qu’elle est indépendante du système d’exploitation, même Cross-Plateforme. Autre avantage, on peut limiter l’accès à la clé privée. Il faut juste décider qui à accès à la clé privée.

clip_image014

Ça c’était bien avec les vieilles versions de PowerShell, ça fonctionne super, même avec Orchestrator, c’est pour dire, … On ne peut pas faire plus sexy avec des versions plus récentes ? Oui, car depuis la version 5.0, on dispose de la fonctionnalité CMSMessage. L’aide intégrée de PowerShell ne vas pas vous aider beaucoup.

clip_image016

Avec la version en ligne de Protect-CMSMessage, c’est déjà mieux. On utilise toujours un certificat, sauf que cette fois, notre certificat devra comprendre l’EKU « Document_Encryption » pour qu’on puisse l’utiliser avec la commande Protect-CMSMessage. J’ai donc préparé une demande de certificat en bonne et due forme ou presque. En fait, ce sera un certificat auto-signé (j’ai fait court pour la démonstration).

clip_image018

Au passage, un switch bien pratique que je ne connaissais pas pour filtrer les certificats : Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

En une seule commande on va être capable de chiffrer notre message : $Message = Protect-CmsMessage -Content $Password -To « *benoit@simplebydesign.fr ». Après, y a plus qu’à empaqueter et transmettre.

clip_image020

De l’autre côté, même principe. On commence par localiser le certificat que nous allons utiliser pour déchiffrer à l’aide de la commande Get-ChildItem Cert:\CurrentUser\My DocumentEncryptionCert. Reste plus qu’à déchiffrer.

clip_image022

Jusque-là, on parlait On-Premises, Old-School IT. Et si on regardait comment faire de même dans Azure. Y a forcément un service pour cela. Oui, C’est Azure Key Vault. Avant cela, faut un peu préparer le terrain. On peut faire cela en PowerShell assez rapidement :

Install-Module AzureRM

Install-AzureRM

clip_image024

Justement, le dernier installé nous intéresse. Continuons notre mise en place, on y reviendra. Continuons avec l’installation du module PowerShell Azure, chargeons tous les modules Azure Resource Managers et celui d’Azure avec les trois commandes suivantes :

Install-Module Azure

Import-AzureRM

Import-module Azure

clip_image026

La première étape d’Azure, c’est l’authentification. Ça se règle en deux commandes PowerShell :

$Cred = get-Credential

Login-AzureRMAccount -Credential $Cred

clip_image028

La commande Get-AzureRMSubscription nous indique que j’ai accès à plusieurs souscriptions. Nous allons nous fixer sur l’une d’entre elle.

clip_image030

Les prérequis sont en place. Nous devons mettre en place notre Azure Key Vault au sein d’un groupe de ressources dédié (sécurité oblige)

New-AzureRmResourceGroup -Name ‘MyKeyVault’ -Location ‘North Europe’

New-AzureRMKeyVault -VaultName ‘MesPrecieux’ -ResourceGroupName ‘MyKeyVault’ -Location’North Europe’

clip_image032

A noter que lors de la création, il faudra prouver son identité. A ce niveau, nous sommes le seul à y avoir accès via l’URL suivante : https://MesPrecieux.vault.azure.net. Stockons notre mot de passe avec les commandes PowerShell suivantes :

$Password = « Ilachangé! »

$SecretValue = ConvertTo-SecureString $Password -AsPlaintext -Force

Set-AzureRMKeyVaultSecret -VaultName ‘MesPrecieux’ -Name « Password » -SecretValue $SecretValue

clip_image034

Nous pouvons vérifier que nous avons bien un secret dans notre coffre aux précieux :

Get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’

clip_image036

Jusque-là, ça casse pas trois pattes à un canard. Montons un peu le niveau. Si on a un coffre-fort pour nos secrets, la moindre des choses, ce serait de pouvoir retrouver l’historique de notre mot de passe, voyons le résultat de la commande Get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -IncludeVersions.

clip_image038

La ça devient intéressant. Non seulement, on a l’historique des valeurs mais on peut aussi filtrer pour utiliser le dernier disponible. Voyons comment retrouver la dernière version de notre mot de passe :

$liste = get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -IncludeVersions

$Password = $liste | Sort-object -property updated -Descending | select -first 1

$secret = get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -Version $password.Version

$Secret | Get-member

$Secret.SecretValue

$Secret.SecretValueText

clip_image040

Nous avons retrouvé le dernier mot de passe associé. Entre temps, il a été changé (sécurité oblige). OK, c’est pas mal. Le problème, c’est de partager nos secrets. La, Azure Key Vault fait fort car grâce à Azure Resource Manager, on peut déléguer l’accès. La commande ci-dessous délègue l’accès à un utilisateur, uniquement pour lire le contenu de mon coffre.

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MesPrecieux’ -UserPrincipalName ‘test@XXXXXXXXXX.onMicrosoft.com’ -PermissionsToSecrets ‘Get’

Get-AzureRmKeyVault -VaultName ‘mesprecieux’

clip_image042

Après, j’aurai pu pousser le vice de déléguer uniquement l’accès à mon mot de passe. On peut même autoriser des applications à accéder aux précieux.

Pour les amateurs, quelques lectures supplémentaires :

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Windows Azure Pack connector: two clouds, one portal

Alors que Microsoft Azure Stack (MAS) pointe le bout de son nez avec la TP1 sorti en ce début d’année 2016, on pourrait penser que les développements autour de Windows Azure Pack sont limités aux Update Rollup. Et bien non. Ce n’est pas l’équipe produit mais un développement de l’IT Microsoft autour de Windows Azure Pack qui est maintenant disponible sur GITHUB.

L’idée de ce développement est de permettre à des locataires de Windows Azure Pack de consommer des souscriptions Azure pour le service des machines virtuelles IaaS. Attention, même si c’est intégré aux portails, cela n’offre pas la cohérence de service que propose Microsoft Azure Stack. De plus, c’est une première version pour laquelle il n’est pas encore possible de l’installer sur une installation distribuée de Windows Azure Pack.

Si le test vous tente, la version actuelle est disponible ici. Effectivement, ça s’interface très bien avec le portail :

clip_image001

Même si l’approche est limitée, c’est une première version. Après, le code source est disponible, très intéressant pour comprendre Windows Azure Pack.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Architecture WAP – Design infrastructure IAAS

Le service IaaS de Windows Azure Pack est un monde à part. C’est un sujet que j’avais déjà abordé dans la série de billet Windows Azure Pack – IaaS : Introduction. On est à la frontière entre deux mondes. Le problème, c’est que ces deux univers ne parlent pas le même langage. On a donc besoin d’un interprète. D’un côté Windows Azure Pack cause le JSON nativement et de l’autre SCVMM, ben il cause PowerShell. On ne peut pas dire que ça aide. Service Provider Foundation sera notre traducteur universel (Alias C3PO). Du point de vue de Windows Azure Pack, il sera vu comme un ensemble de Resource Provider.

clip_image001

 

Dans le diagramme ci-dessus, on constate que du point de vue de Windows Azure Pack, la seule notion qui l’intéresse, c’est celle de VM Clouds. C’est la ressource que nous allons mettre à disposition de nos futurs locataires, à savoir un Cloud SCVMM. SCOM et SCVMM sont totalement inconnus, pourtant, ils fournisseur des services. Plus précisément, le Service Provider Foundation assure la mise en place des souscriptions de ce service, son statut et son état de santé. Ça match juste avec les Resources Providers au cœur de Windows Azure Pack que nous venons de voir. Dans les faits, c’est un peu plus compliqué que cela mais pour commencer, on va se contenter de cela.

 

Windows Azure Pack n’a aucune idée de ce qu’est SCVMM. Il ne voit que la ressource mise à disposition. Derrière ce terme, il faut y voir une unité de gestion, on y reviendra plus tard. Pour l’instant, on va se concentrer sur les Resources Providers mis à disposition de Windows Azure Pack, ils sont au nombre de trois :

  • SystemCenter
  • CloudServices
  • Gallery

 

Donc on doit installer Service Provider Foundation. Le comment a déjà été traité ici : Windows Azure Pack – IaaS : Installation du Service Provider Foundation. Les questions qui nous intéressent ici c’est :

  • Ou l’installer ?
  • Comment le rendre hautement disponible?
  • Comment être sûr que ce sera scalable dans le temps ?

 

La réponse la plus évidente à la première question peut sembler facile. On peut l’installer sur l’unique instance de notre infrastructure SCVMM, c’est la solution la plus simple. Problème, adieu la haute disponibilité, idem pour la scalabilité. On n’y coupera pas, il faudra lui dédier un serveur pour notre première instance. Vu que ce sont des Web Services, pour la haute disponibilité, c’est juste une histoire de load-Balancers, voilà pour la seconde question.

clip_image003

 

Dernier point, la scalabilité. Au niveau du Service Provider Foundation, c’est une histoire de configuration matérielle. Selon le Capacity Planning for Service Provider Foundation, avec le bonne configuration on est prêt à tout :

Nombre de VM

CPU

RAM

Moins de 5000 4 cœurs 8 Go RAM
Entre 5 000 et 12 000 VM 8 cœurs 8 Go RAM
Entre 12 000 et 25 000 VM 16 cœurs 8 Go RAM

25 000 machines virtuelles, c’est aussi la limite de notre infrastructure SCVMM. Ça tombe bien. Revenons à nos Resources Providers. Pour les deux premiers (Gallery et CloudServices), il faut comprendre que le Resource Provider se limite à fournir des services au portail des locataires. Pour le dernier, c’est lui qui porte les fonctions principales du Service Provider Foundation. Si on regarde sur le serveur en question, cela correspond aux Web Services exposés, à savoir :

 

Nous avons l’interface entre Windows Azure Pack et Service Provider Foundation. La suite est assez simple puisqu’il nous reste plus qu’à déclarer notre instance SCVMM voire jusqu’qu’à cinq instances. Ce sont des sujets que j’avais déjà abordé dans cet article : Windows Azure Pack – IaaS : Intégration de Service Provider Foundation ainsi que celui-ci Windows Azure Pack – IaaS : Déclaration du VM Cloud.

Pour l’architecture IaaS, il ne nous reste plus qu’un sujet à traiter, à savoir l’accès aux machines virtuelles via RDP. Ce service est mis à disposition par la Remote Desktop Gateway. Le service repose sur la fonctionnalité « Enhanced session mode » de Windows Server 2012 R2. La fonctionnalité est intéressante car elle propose un accès RDS à la machine virtuelle via l’hôte Hyper-V. Cela signifie que même si la machine virtuelle ne dispose pas de connectivité Internet, c’est le mode console. Sous la moquette, cela ressemble à cela :

clip_image005

 

Techniquement, on utilise un certificat (avec un FQDN public) qui est présent sur :

  • La Remote Desktop Gateway
  • Virtual Machine Manager

 

Il est aussi présent sur tous les hôtes Hyper-V mais c’est SCVMM qui se charge de le mettre à disposition de tous les hôtes Hyper-V. Lorsque l’utilisateur va demander l’accès RDP à une de ses machines virtuelles, un fichier RDP sera généré et mis à disposition de l’utilisateur. Il va ensuite le présenter à la Remote Access Gateway. Normalement, le rôle de la RDS Gateway est d’authentifier les utilisateurs avant qu’ils n’accèdent aux sessions RDS. Problème, dans le contexte de Windows Azure Pack, notre RDS Gateway n’a aucune idée du fournisseur d’identité à solliciter. Le package va donc modifier le mode de fonctionnement de la RDS Gateway pour réaliser une authentification à base de certificat.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)