A la découverte d’Hybrid Worker dans Azure Automation

Après avoir abordé le sujet identité Azure Automation, continuons dans ce domaine avec le mode Hybride d’Azure Automation. Ci-dessous un rappel de Azure Automation pour poser le décor. Par défaut, un Runbook est exécuté dans Azure Automation donc dans Azure. C’est parfait pour manipuler des ressources Azure. Par contre, quand on essaie de l’utiliser pour manipuler les machines virtuelles, cela implique que celles-ci soient accessibles sur Internet. C’est faisable mais d’un point de vue sécurité, c’est tout sauf sexy que ce soit dans Azure ou On-Premises.

clip_image001

 

C’est là que le mode hybride prend tout son intérêt. Azure Automation Hybrid Worker permet d’exécuter nos Runbooks sur un serveur qui a accès à Internet et qui sera le seul à accéder aux machines virtuelles à administrer. Cette approche présente beaucoup d’avantages :

  • L’hôte sur lequel on installe le Hybrid Worker n’a pas besoin d’une adresse IP publique. En fait, l’hôte a juste besoin de pouvoir accéder à Internet
  • D’un point de vue réseau, les flux partent du Hybrid Worker pour aller vers Azure mais l’inverse. Il n’y a donc pas de flux entrant vers nos infrastructures
  • Possibilité de configurer le Hybrid Worker pour utiliser un proxy pour accéder Azure
  • L’hôte sur lequel on installe le Hybrid Worker sera le seul qui devra accéder aux machines virtuelles que l’on va gérer. On peut donc limiter les flux réseau au strict minimum.

 

Mise en œuvre d’un Hybrid Worker

Côté mise en œuvre, il y a quelques prérequis à respecter au niveau OMS Log Analytics :

  • Une instance du service Azure Automation à laquelle on va raccorder notre Hybrid Worker
  • Une instance du service OMS Log Analytics
  • La solution Automation Hybrid Worker préalablement activée dans OMS Log Analytics

 

Pour notre futur Hybrid Worker, nous avons besoin :

  • Une machine virtuelle avec 2VCPU et 4Go de mémoire vive
  • D’un OS Windows Server 2012 minimum disposant d’un Accès Internet
  • L’agent OMS Log Analytics préalablement installé sur notre futur serveur Hybrid Worker

 

Normalement avec le socle Windows Server 2012, on a automatiquement PowerShell 4.0. Ça ne coute rien de vérifier en regardant ce que nous retourne la variable $PSVersionTable.

clip_image002

 

PowerShell 4.0, c’est bien mais en ce qui me concerne je préfère avoir la même version de PowerShell, que nos Runbooks se comportent de la même manière dans Azure que sur notre future instance du Hybrid Worker. On va donc commencer par installer le Management Framework 5.1 disponible ici.

clip_image003

 

Une fois l’installation terminée, on peut constater la nouvelle version de PowerShell qui est maintenant 5.1.

clip_image004

 

Prochaine étape, les modules PowerShell. C’est un prérequis à l’installation qui va suivre mais aussi un process qu’on va devoir gérer. Dans Azure Automation, on est capable de maîtriser les modules PowerShell (modules & version) qui sont utilisés. Au moment de l’écriture de ce billet, il n’est pas encore possible de gérer les modules sur le Hybrid Worker. J’en ai fait l’amère expérience pendant un développement de Runbook. Un des avantages de PowerShell 5.0 (ou supérieur), c’est la capacité à utiliser la PowerShell Gallery comme unique repositoy de nos modules. On doit juste autoriser son utilisation :

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

clip_image005

 

Etant donné que je vais manipuler beaucoup de ressources Azure, il est logique de demander l’installation des modules PowerShell en relation avec Azure. N’oubliez pas d’installer vos propres modules sinon ça va poser quelques problèmes.

C’est maintenant que commence la configuration de notre futur Hybrid Worker. L’avantage est que tout le paramétrage est prévu dans le script « New-OnPremiseHybridWorker ». Nous n’avons qu’à le télécharger depuis la PowerShell Gallery avec la commande suivante :

Install-Script -Name New-OnPremiseHybridWorker -RequiredVersion 1.0

clip_image006

 

Nous devons accepter l’installation des PowershellGet NuGet.

clip_image007

 

Ne reste plus qu’à réaliser l’installation de notre Hybrid Runbook Worker avec le code ci-dessous :

$AutomationAccountName = « <nom instance Azure Automation> »

$AutomationResourceGroupName = « <groupe de ressources> »

$AzureSubscriptionID = « <Identifiant unique de votre souscription> »

$OMSWorkSpace = « <Nom de votre instance OMS> »

New-OnPremiseHybridWorker.ps1 -AutomationAccountName $AutomationAccountName -ResourceGroupName $AutomationResourceGroupName -HybridGroupName « Hybrid01 » -SubscriptionId $AzureSubscriptionID -WorkspaceName $OMSWorkSpace

clip_image008

 

Comme tout s’est bien passé, on doit pouvoir constater l’arrivée d’une instance Hybrid Worker group dans Azure Automation. C’est à ce groupe qu’a été associé notre serveur. Un groupe peut regrouper plusieurs instances Hybrid Worker, histoire de proposer de la haute disponibilité et la répartition de l’exécution des Runbooks.

clip_image009

 

Maintenant, un sujet sécurité. Dans le billet identité Azure Automation, nous avons abordés le sujet de l’identité sous laquelle nos Runbooks sont exécutés sous Azure. Dans l’état actuel de la configuration, notre Hybrid Worker ne dispose d’aucune identité pour faire fonctionner les Runbooks.

clip_image010

 

On peut tenter de fonctionner dans ces conditions mais on n’ira jamais plus loin que le Hybrid Worker. Le problème c’est qu’avec le contexte d’exécution par défaut, c’est celui du contexte d’exécution du Hybrid Worker. On va donc commencer par mettre en place un contexte d’exécution pour nos Runbooks. Dans Azure Automation, cela prend la forme d’un objet credential. Ce contexte de sécurité, nous le référençons dans Azure sous la forme d’un credential.

clip_image011

 

Inutile de rappeler que le compte devra exister sur toutes les machines virtuelles que l’on voudra manipuler depuis un Runbook exécuté avec notre instance du Hybrid Worker. Ne reste plus qu’à configurer ce contexte d’exécution pour notre instance du Hybrid Worker.

clip_image012

 

Remarque : N’oubliez pas le bouton « Save », …

 

Un dernier détail pour notre Hybrid Worker. Nous allons l’utiliser comme pivot pour exécuter du code PowerShell sur des systèmes distants. Erreur classique en PowerShell, on tente de faire du Remote PowerShell sur un système qui ne peut pas être approuvé (pas membre du domaine), ça échoue. Pourtant, un simple « Get-ChildItem WSMAN:LocalHost\Client » aurait dû vous faire comprendre qu’il y allait avoir un problème.

clip_image013

 

Dans le cadre de ce billet, on va faire au plus simple, en autorisant toutes destinations depuis le serveur Hybrid Worker. Après, d’un point de vue sécurité, c’est très discutable. Les bonnes pratiques de sécurité voudraient qu’on référence la liste des adresses IP vers lesquelles notre serveur va communiquer.

clip_image014

 

Remarque : Volontairement, je suis laxiste sur ce point de sécurité. J’y reviendrai plus tard.

 

Un client pour tester

Pour valider le bon fonctionnement de tout cela, il nous faut un client. J’ai donc mis en œuvre une nouvelle machine virtuelle, sur le même réseau que notre Hybrid Worker. Le Runbook que nous allons créer va s’exécuter sur le Hybrid Worker et devra accéder à notre nouvelle machine virtuelle en PowerShell (Donc du Remote PowerShell). C’est un sujet connu, on va donc aller très vite. Nous avons besoin de :

  • Disposer d’un certificat (auto-signé pour les besoins de ma démonstration)
  • Activer la fonctionnalité PowerShell Remoting
  • Associer le certificat à WINRM pour faire du PowerShell avec un peu de sécurité
  • Créer une règle de pare-feu

Pour faire simple, le code ci-dessous réalise toutes ces opérations. Ici encore, il reste très perfectible d’un point de vue sécurité mais il fonctionnera pour notre démonstration.

$fqdn = $env:computername

$cert = New-SelfSignedCertificate -DNSName $fqdn -certStorelocation « cert:\LocalMachine\My »

Enable-PSRemoting -SkipNetworkProfileCheck -Force

New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $Cert.Thumbprint –Force

New-NetFirewallRule -DisplayName « RemotePowerShell » -Direction Inbound –LocalPort 5986 -Protocol TCP -Action Allow -RemoteAddress 10.0.0.5

clip_image015

 

Pour finir on va introduire un peu de sécurité au niveau réseau. Mon client étant une machine virtuelle dans Azure, ci-dessous un extrait des règles entrantes du Network Security Group associé à la carte réseau :

clip_image016

 

Globalement le seul moyen pour joindre cette machine virtuelle, ce sera PowerShell (et en mode sécurisé seulement), uniquement depuis une seule adresse IP, celle de notre Hybrid Worker. Pour les règles sortantes, c’est encore plus strict, aucun moyen de joindre Internet :

clip_image017

 

Un Runbook magique

Notre client est prêt, ne nous manque plus que le Runbook « magique ». En fait, point de magie, juste du Remote PowerShell à l’ancienne. On va juste ajouter un peu d’Azure Automation en récupérant le « SecureString » contenant le compte de service que nous avons mis en œuvre et construire une authentification WSMAN pour exécuter du PowerShell sur une machine virtuelle distante désignée par son adresse IP qui a été passée en paramètre du Runbook.

param (

    [Parameter(Mandatory=$true)]

    [String] $RemoteIP

)

[OutputType([String])]

#

# Récupération des credentials dans un objet SecureString

#

$credential = Get-AutomationPSCredential -Name ‘Hybrid01_Credential’

« Host d’exécution : $env:computername. »

#

# Construction de l’authentification

#

$sessionOptions =New-PSSessionOption -SkipRevocationCheck -SkipCACheck -SkipCNCheck

$session = New-PSSession -ComputerName $RemoteIP -SessionOption $sessionOptions -Credential $Credential -UseSSL

$session

#

# Exécution de code Powershell à distance

#

$retour = Invoke-Command -Session $session -scriptblock { « Host d’exécution : $env:computername. » }

$retour

Remove-PsSession $Session

A l’Exécution de notre Runbook, on constate qu’il est possible de l’exécuter dans Azure et aussi sur un Hybrid Worker que nous pouvons sélectionner dans la liste de liste.

clip_image018

 

En fin d’exécution, on devrait avoir le résultat ci-dessous :

clip_image019

 

Le Runbook a bien commencé son exécution sur le Hybrid Worker pour ensuite créer une session WSMAN distante sur le second serveur et exécuter du code.

 

Bonus : Un peu plus de sécurité

Si vous avez suivi mon billet sur l’identité dans Azure Automation, vous savez comment créer un Service principal qui sera mis en œuvre uniquement pour un Hybrid Worker. Avantage si vous avez plusieurs instances d’Hybrid Worker, chaque instance dispose de sa propre identité pour se connecter à Azure avec un certificat. Pour améliorer la sécurité, on peut aussi :

 

Et continuer avec quelques saines lectures sur la sécurité PowerShell :

 

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

Benoit

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

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

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

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