Archives mensuelles : avril 2016

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)