Freigeben über

Azure, PowerShell et les certificats de gestion

  • Artikel

Lorsque l’on débute avec le couple PowerShell et Windows Azure, les documentations de Technet ou MSDN ne sont pas encore de nature à clarifier les choses. J’aimerais donc éclaircir un peu le sujet en pensant aux IT, ou administrateurs systèmes, qui ont besoin de tester et mettre en production des scripts d’automatisation, voire des runbooks pour Orchestrator.

Dans cet article j’indiquais comment installer le module Azure pour PowerShell. La seconde étape, avant de pouvoir utiliser le module, est d’installer un certificat qui vous permettra de vous authentifier sur votre abonnement Azure. Pour ce faire, quatre actions sont nécessaires :

  1. Créer le certificat et sa clé privée
  2. Installer le certificat sur votre abonnement Azure, dans le cloud
  3. Installer le certificat et sa clé privée sur le système local qui exécute PowerShell
  4. Déclarer dans PowerShell l’abonnement Azure, et le certificat à utiliser avec sa clé privée

Il en va de même pour d’autres outils d’automatisation d’Azure, comme System Center 2012 SP1 Orchestrator. Si l’on se débrouille bien, un seul certificat peut servir pour ces différents usages.

Il y a donc trois méthodes pour arriver à la même fin.

  1. Demander à Azure de générer une paire clé privée + certificat et l’importer depuis PowerShell
  2. Créer une paire clé privée + certificat autosigné grâce à l’outil makecert et la gérer soi-même
  3. Utiliser sa PKI d’entreprise pour générer une paire clé privée + certificat et la gérer soi-même

La première méthode a l’avantage d’être simple et rapide et de ne pas demander de connaissances particulières en PKI. Par contre, elle ne fonctionne que pour PowerShell (pas pour d’autres produits comme Orchestrator ou App Controller), et doit être répétée sur chaque machine à partir de laquelle on doit utiliser PowerShell pour accéder à Azure. Ce qui multiplie les certificats et ne donne pas une maîtrise complète du procédé.

La deuxième et la troisième méthode sont équivalentes, à ceci près qu’un certificat émis par une autorité de confiance est toujours préférable à un certificat autosigné. Leur avantage est de permettre la maîtrise complète du certificat par l’administrateur. En effet ce dernier dispose de sa clé privée exportable dans un fichier .pfx et de son certificat, il peut donc le réutiliser sur plusieurs machines et plusieurs produits de management d’Azure comme System Center Orchestrator et App Controller.

Certificat généré par Azure

Ce n’est pas la meilleure méthode, mais elle peut dépaner si vous utilisez une nouvelle machine et que vous n’avez pas votre pfx sous la main. Dans une session PowerShell, chargez le module Azure :

 Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1"

Puis exécutez la commande :

 Get-AzurePublishSettingsFile

Cette commande ouvre votre navigateur pour le téléchargement du certificat généré par Windows Azure :

image

Téléchargez le fichier (son extension est .publishsettings), puis, dans PowerShell, importez ce fichier pour créer un nouvel abonnement :

 Import-AzurePublishSettingsFile fichier.publishsettings

Pour vérifier que l’abonnement est créé, vous pouvez utiliser la commande :

 Get-AzureSubscription

Puis testez, par exemple avec la commande :

 Get-AzureVM

Dans la console web de Windows Azure, vous pouvez constater que le certificat a été automatiquement ajouté dans Settings – Management Certificates :

image

Eventuellement vous pouvez conserver le fichier .pusblishsettings et le ré-importer sur d’autres systèmes. Mais cela ne sera valable que pour PowerShell. En effet pour d’autres outils il faudra un pfx (certificat + clé privée), mais la clé privée du certificat importé par cette méthode n’est pas exportable vers un pfx. D’où la préférence pour les deux méthodes qui suivent.

Certificat autosigné avec makecert

Il s’agit de la méthode documentée ici :

https://msdn.microsoft.com/en-us/library/windowsazure/gg551722.aspx

Je n’entrerai donc pas trop dans le détail. Il suffit de récupérer makecert.exe dans les outils de développement de Windows, et d’exécuter une commande du type :

makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"

Cette commande crée la paire de clés, le certificat, et les stocke dans votre magasin personnel de certificats. Au passage elle crée également le fichier .cer du certificat, à conserver.

Pour conserver le certificat et sa clé privée et ainsi les réutiliser sur d’autres systèmes, voire d’autres applications, il suffit d’exporter le certificat depuis la console certmgr.msc, avec sa clé privée, dans un fichier .pfx.

Pour la suite, il faut envoyer le certificat dans votre abonnement Windows Azure, puis l’importer dans PowerShell. Ces manipulations sont les mêmes pour la 3ème méthode ci-dessous, je vous renvoie donc à la section “Utilisation du certificat avec Windows Azure” ci-dessous.

Certificat d’une PKI d’entreprise

Création du certificat

Voici finalement la méthode la plus adaptée à un environnement d’entreprise, du moment que vous les postes clients sont dans un domaine et qu’une PKI (Certificate Service) est en place.

Tout d’abord il faut demander et récupérer un certificat de type User :

  • Lancer certmgr.msc.

  • Dans la partie gauche, cliquer à droite sur Personal et choisir All Tasks – Request New Certificate.

    image

  • Dans l’assistant : <Next>, puis choisir <Active Directory Enrollment Policy> <Next>

    004

  • Dans la liste des modèles de certificats, cocher <User> puis cliquer sur <Enroll>

    005

    006

  • <Finish>

Puis il faut exporter le certificat, une fois avec sa clé privée (fichier .pfx), et une fois sans sa clé privée (fichier .cer).

image

Il faut donc faire cette manipulation deux fois, avec et sans la clé privée.

Il reste alors à utiliser ce nouveau certificat avec Windows Azure et PowerShell.

Utilisation du certificat avec Windows Azure

La première chose à faire est d’envoyer le certificat dans Windows Azure : Dans la console Azure, aller dans Settings – Management Certificates, cliquer sur Upload, et envoyer le fichier .cer.

016

Du côté de PowerShell, il faut créer l’abonnement en l’associant avec le certificat. Pour ce faire il faut disposer de l’identifiant de votre abonnement. Celui-ci a la forme d’un GUID et se trouve dans le portail d’administration de Windows Azure.

Il faut également disposer du thumbprint (empreinte) du certificat. Pour cela, ouvrir ses propriétés depuis la console certmgr.msc, et, dans l’onglet Details, afficher le thumbprint :

018

Sélectionner et copier sa valeur. Attention avant d’utiliser cette valeur dans PowerShell, il est préférable de la coller dans notepad par exemple, et de supprimer les espaces entre les valeurs d’octets en hexa.

il suffit alors, dans PowerShell, d’exécuter ceci, après avoir inséré l’ID d’abonnement, le thumbprint du certificat, et remplacé ‘mysub’ par le nom de l’abonnement désiré.

 # Chargement du module Azure

Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1"

# ID de l'abonnement Azure
$subid = "ca8358b6-1ae3-4ccd-860e-82c9dc9a9539"
# Thumbrint du certificat
$thumbprint = "8F6B76DE2F6A93DF73A78C512D8BAA23C17690EE"
# Certificat
$cert = Get-Item Cert:\CurrentUser\My\$thumbprint
# Initialisation de l'abonnement
Set-AzureSubscription -SubscriptionName mysub -Certificate $cert `
    -SubscriptionId $subid

# Test

Select-AzureSubscription -SubscriptionName msysub
Get-AzureVM

Une fois l’abonnement créé et testé, vous êtes prêts à utiliser PowerShell pour automatiser vos traitements dans Windows Azure.

image

Consultez l’aide de Set-AzureSubscription, pour des options permettant par exemple de spécifier un compte de stockage par défaut, l’abonnement par défaut si vous en avez plusieurs, ou d’exporter un abonnement vers un fichier XML.