Je suis rentré dans Azure Function un peu par hasard. Je cherchais une alternative aux Webhooks de Azure Automation. Le principe est bien mais pose quand même quelques contraintes :

• Impossibilité de retrouver l’URL du WebHook une fois créée, faut avoir conservé l’information
• Pas d’authentification. Si on connait l’URL, c’est accessible en mode open-bar
• Impossibilité de personnaliser paramètres une fois le WebHook créé (le plus problématique pour moi)

C’est pour cette raison que je suis arrivé à Azure Function. En plus, je n’étais pas en terrain inconnu avec du PowerShell :

Certes, c’est encore expérimental mais de ce que j’ai pu tester, c’est assez stable pour envisager l’utiliser. Mon besoin était de disposer d’un mécanisme équivalent aux WebHooks mais avec :

• Une méthode d’authentification un peu plus évoluée
• La capacité à passer des paramètres pour exécution
• La possibilité de retourner les résultats d’exécution du Runbook Azure Automation

Mise en œuvre

Côté mise en œuvre, nous devons commencer avec la mise en place d’une instance du service Function App. On retrouve pas mal de paramètres connus, on ne va s’attarder sur l’un d’entre eux :

 

Pour le Hosting Plan. On a le choix entre :

• Consumption Plan
• App Service Plan

Avec Azure Function, on est capable de fonctionner sans infrastructure aussi dit « server-less ». Dans le mode  » App Service Plan », les Azure Functions seront exécutées dans le contexte d’un App Service Plan. Si on paie déjà pour pour héberger un site web pourquoi pas mais mon besoin, c’est juste de pouvoir exposer une API pour exécuter un Runbook Azure Automation. J’ai donc retenu le mode « Consumption Plan ». Une instance du service App Service Plan sera mise à disposition uniquement quand un appel à mon API sera réalisé. Pour les coûts, c’est bien. Par contre, ce n’est pas forcément le mode de fonctionnement qui offrira les performances les plus élevées.

Le mode « App Service Plan » présente certains avantages. Vu que c’est un App Plan, on peut configurer toutes ses fonctionnalités (scale-out, sauvegarde, authentification, …). Personnellement en dessous de S1, ce n’est pas pour de la production.

Créer une Azure Function

On a le choix du langage. Ce qui est intéressant, c’est qu’une Azure Function a nécessairement un déclencheur :

• Un Trigger HTTP (Déclencher l’appel sur une URL donnée)
• Un trigger Timer (Déclencher l’appel selon une planification horaire)
• Un Trigger EventGrid (tout nouveau avec le service Event grid)
• L’arrivée du message dans une Azure Queue
• L’arrivée d’un message dans topic Service Bus
• Autres déclencheurs

En PowerShell, tout ça c’est encore expérimental, nos choix sont pour l’instant limités :

 

Pour mon besoin, le HttpTrigger fera parfaitement l’affaire. Il ne nous reste qu’à trouver un nom à notre première Azure Function.

 

Avant de poursuivre, arrêtons-nous sur la notion d’Authorization Level. C’est l’aspect authentification qui me manquait dans les WebHooks d’Azure Automation. Cela repose sur une clé qui peut être identique à toutes les Azure function (Admin level) ou une clé spécifique à chaque Azure Function (Function level). Je passe sur Anonymous, je pense que vous avez compris, … Ce que ne montre pas l’interface, c’est qu’il est aussi possible d’utiliser toutes les méthodes d’authentification disponibles dans un Web App (si on a choisi le mode de déploiement (App Service plan). Par exemple, il est possible de déporter l’authentification au niveau d’une Azure API management Gateway, .. Dans mon contexte le niveau « Function » sera amplement suffisant pour ce billet.

Par défaut, il nous est proposé un exemple gendre « Hello World ». A droite, on voit bien le paramètre passé en paramètre et le résultat de l’appel. Pour l’instant, à l’exception du passage de paramètre, cela ressemble beaucoup à Azure Automation.

 

On rentre dans le côté Sexy d’Azure Function. Mon déclencheur est une WebRequest mais on peut compléter cet appel en liant l’Azure Function à une source de données tel qu’Azure Table, Azure Queue, Service Bus ou même CosmoDB, même principe pour la sortie. Dans mon contexte, nous allons nous contenter des paramètres par défaut. Ils conviennent pour mon usage :

 

Dans la rubrique Manage, on gère la disponibilité de la fonction mais aussi les fameuses clés d’authentification utilisables. Certes, si on connait l’URL avec la clé, on a accès comme pour les WebHooks dans Azure Automation. Je suis d’accord mais c’est pour cela que l’intégration à un App Service plan est intéressante car on peut alors choisir la méthode d’authentification qui nous intéresse, voire jusqu’à aller utiliser Azure API Gateway.

 

Azure Function propose un mécanisme de supervision. Il a le mérite d’exister mais une intégration avec Azure Application Insight sera bien plus utile. On y reviendra plus tard.

 

Nous avons un socle pour poser notre Azure Function. Pour commencer, la première chose dont nous allons avoir besoin c’est d’authentification. Le code PowerShell que nous allons exécuter devra déclencher un Runbook dans Azure Automation. On va tout de suite commencer par bannir l’idée du compte et mot de passe en clair dans le code PowerShell, c’est juste moche. Nous avons rencontré la même problématique avec Azure Automation dans mon billet Parlons d’identité avec Azure Automation. Ce sera la même approche à deux différences près :

• Nous allons stocker les informations nécessaires non plus dans Azure Automation mais dans la Web Application, dans les Applications Settings
• On n’utilisera pas un certificat mais un secret pour l’authentification du Service principal

 

Préparer une identité pour notre Azure Function

Utiliser un certificat serait certainement possible mais faudra que je creuse plus la question. En tout cas, on sait déjà qu’il ne sera pas la peine d’essayer aller le chercher dans un Azure Key Vault. Accéder à un Key Vault implique une authentification préalable, … Ce sera donc une application tout ce qu’il y a de classique avec juste un secret. Nous verrons plus tard comment offusquer ce secret.

$ADApplicationName = « myazurefunction991 »

$ADHomePage = « https://$ADApplicationName.azurewebsite.net« 

$IdentifierUris = $ADHomePage

$azureADApplication = New-AzureRmADApplication -DisplayName $ADApplicationName -HomePage $ADHomePage -IdentifierUris $IdentifierUris -Password « MyVerySecureP@ssw0rd »

$azureADApplication

 

Ensuite, nous allons lier cette application Azure AD nouvellement déclarée à un Service Principal.

$ServicePrincipal = New-AzureRmADServicePrincipal -ApplicationId $azureADApplication.ApplicationId

$ServicePrincipal

 

Ne reste plus qu’à positionner des permissions à notre Service Principal. Dans mon contexte, les ressources que mon Service Principal doit pouvoir manipuler sont dans un groupe de ressources nommé « AzureFunctionLabs ».

New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $azureAdApplication.ApplicationId.Guid -Scope (Get-AzureRmResourceGroup -Name « AzureFunctionLabs »).resourceId

 

Pour finir, on se met de côté quelques informations. Nous en aurons besoin pour mettre en place l’authentification dans notre Azure Function :

$AzureApplicationID = $azureADApplication.ApplicationId.Guid

$AzureADTenantID = (Get-AzureRmTenant).tenantid

$SubscriptionId = (Get-AzureRmContext).Subscription.SubscriptionId

$AzureApplicationID

$AzureADTenantID

$SubscriptionId

 

Avant de passer à Azure Function, on va commencer par poser le code PowerShell. Nous sommes en présence d’un Azure AD Service Principal. Autant pour la construction de la chaine SecureString, rien de change, c’est au niveau de la commande Add-AzureRmAccount que cela change :

$AzureApplicationID = « 0eb602cc-4243-4104-815a-dda4b6f7378a »

$AzureADTenantID = « dfe6b267-4f0f-45e5-a9ed-d0540af967dd »

$subscriptionID = « 85e3593c-6a07-4e81-a447-a06d6f5e6f89 »

$azurePassword = ConvertTo-SecureString « MyVerySecureP@ssw0rd » -AsPlainText -Force

$psCred = New-Object System.Management.Automation.PSCredential($AzureApplicationID, $azurePassword)

$psCred

Add-AzureRmAccount -Credential $psCred -TenantId $AzureADTenantID -ServicePrincipal -SubscriptionId $SubscriptionID

 

L’authentification fonctionne, ne reste plus qu’à transposer cela dans notre Azure Function. Le code PowerShell est strictement identique, juste le Out-File pour retourner le contexte Azure :

$SubscriptionID = ’85e3593c-6a07-4e81-a447-a06d6f5e6f89′

$AzureApplicationID = ‘0eb602cc-4243-4104-815a-dda4b6f7378a’

$TenantID = ‘dfe6b267-4f0f-45e5-a9ed-d0540af967dd’

$azurePassword = ConvertTo-SecureString « MyVerySecureP@ssw0rd » -AsPlainText -Force

$psCred = New-Object System.Management.Automation.PSCredential($AzureApplicationID, $azurePassword)

Add-AzureRmAccount -Credential $psCred -TenantId $TenantID -ServicePrincipal -SubscriptionId $SubscriptionID

$context = Get-AzureRMContext

Out-File -Encoding Ascii -FilePath $res -inputObject $context

 

Nous avons quelque chose de fonctionnel mais qui d’un point de vue sécurité laisse à désirer. Laisser trainer des informations comme l’identifiant de l’application Azure AD ou même son secret associé, ce n’est pas génial. Nous allons déplacer ces informations dans des variables au niveau des Application Settings

Au lieu d’avoir nos paramètres dans le code de la fonction, l’ai retenu de les placer directement dans les Applications Settings, donc au niveau de l’Azure App Service.

 

Certains me dirons que ce n’est pas encore parfait. Tout de suite, on pense à Azure Key Vault mais encore une fois, il faut être authentifié pour accéder à Azure Key Vault. Dans l’état actuel des choses, la seule amélioration de sécurité envisageable serait de ne pas s’authentifier avec un secret mais un certificat. C’est un sujet que j’explorerai ultérieurement.

Pour notre code, ces variables sont disponibles dans PowerShell dans les variables d’environnements. C’est déjà beaucoup mieux pour notre code.

$AzureADPassword = $env:AzureADPassword

$SubscriptionID = $Env:SubscriptionID

$TenantID = $Env:TenantID

$AzureApplicationID = $env:AzureApplicationID

$SecureString = ConvertTo-SecureString $AzureADPassword -AsPlainText -Force

$psCred = New-Object System.Management.Automation.PSCredential($AzureApplicationID, $SecureString)

Add-AzureRmAccount -Credential $psCred -TenantId $TenantID -ServicePrincipal -SubscriptionId $SubscriptionID

$context = Get-AzureRMContext

Out-File -Encoding Ascii -FilePath $res -inputObject $context

 

Retour au besoin initial

Maintenant que nous sommes authentifiés dans Azure, revenons à mon besoin initial : Exécuter un Runbook dans Azure depuis une Azure Function avec passage de paramètre et pouvoir suivre l’avancement.

Pour le Runbook, j’ai pris ce qu’il y a de plus minimaliste possible pour ma démonstration :

param (

    [Parameter(Mandatory=$true)]

    [String]$Name

)

Write-Output « Hello $name »

Je vous laisse comprendre le paramètre en entrée, …

 

Pas grand-chose à dire de plus côté Azure Automation, ce qu’il nous faut maintenant, c’est d’intégrer l’appel du Runbook à notre Azure Function. J’ai commencé par ajouter un paramètre en entrée qui sera obligatoire. Après, ce n’est que du PowerShell tout ce qu’il y a de plus classique :

$requestbody = Get-Content $req -raw | ConvertFrom-JSON

$name = $requestBody.Name

If ($name -ne $null)

{

$AzureADPassword = $env:AzureADPassword

$SubscriptionID = $Env:SubscriptionID

$TenantID = $Env:TenantID

$AzureApplicationID = $env:AzureApplicationID

$SecureString = ConvertTo-SecureString $AzureADPassword -AsPlainText -Force

$psCred = New-Object System.Management.Automation.PSCredential($AzureApplicationID, $SecureString)

Add-AzureRmAccount -Credential $psCred -TenantId $TenantID -ServicePrincipal -SubscriptionId $SubscriptionID

$context = Get-AzureRMContext

$params = @{« Name »=$name}

$AutomationAccount = « MyAutomation992 »

$resourceGroup = « PersonalBackup »

$RunbookName = « HelloAutomationWorld »

$job = Start-AzureRmAutomationRunbook –AutomationAccountName $AutomationAccount –Name $RunbookName -ResourceGroupName $resourceGroup –Parameters $params

Out-File -Encoding Ascii -FilePath $res -inputObject $job

}

Else

{

Out-File -Encoding Ascii -FilePath $res -inputObject « Invalid Parameter. »

}

<Je suis un boulet, AKA Kevin le boulet> : A ceux qui se demandent pourquoi il utilise une instance Azure Automation qui n’est pas dans le groupe de ressources pour lequel le Service Principal créé a obtenu des permissions, c’est que je suis un boulet. En exécutant L’Azure Function la première fois il m’a été clairement indiqué un manque de permissions. J’ai donc ajouter les permissions uniquement sur l’instance Azure Automation référencé dans mon code </Je suis un boulet, AKA Kevin le boulet>.

C’est maintenant qu’on comprend pourquoi il y a deux boutons « Run » dans l’éditeur. Celui-qui se trouve en bas à droite permet d’appeler notre Azure Function avec le ou les paramètres nécessaires à l’exécution.

 

Volontairement, j’ai retenu de récupérer le JobID du job qui a exécuté le Runbook. Attendre la bonne exécution du Runbook n’a pas de sens avec Azure Function car vous êtes limités dans le temps (voir à la fin du billet). Par contre, ayant récupéré le JobID, rien ne vous interdit de revenir plus tard pour vérifier le bon déroulement de votre Job.

Test en condition réelle

Tester en condition réelle, c’est juste quatre lignes de PowerShell pour invoquer notre Azure Function. Pour cela, encore faut-il connaître l’URL de notre Azure Function avec sa clé.

 

Après, ce n’est que du PowerShell :

$url = « « 

$parameters = @{Name=’BenoitS’}

$json = $parameters |ConvertTo-Json

Invoke-RestMethod -Uri $Url -Method POST -ContentType ‘application/json’ -Body $json

 

Je vous laisse deviner le résultat de l’exécution du Runbook, …

 

Supervision

Pour ceux qui se sont demandé à quoi pouvait bien servir la variable APPINSIGHTS_INSTRUMENTATIONKEY dans les Application Settings, c’est la clé pour permettre de connecter Azure Function à Application Insight. L’intégration entre les deux composants est automatique. Le problème, c’est que pour le portail, cela veut dire de créer une nouvelle instance du service Application Insights ;). Je vous recommande donc de créer votre instance du service Azure Function App puis de la raccorder à Application Insights ultérieurement : Azure Functions now has direct integration with Application Insights. Une fois l’intégration en place, on peut suivre pas mal d’indicateurs de performance.

 

Côté performance, avec un peu de tunning, on obtient des performances plus acceptables pour une API.

 

Quelques astuces pour finir

La liste des trucs sur lesquels j’ai buté avant de comprendre. Pour certains d’entre eux, ça a juste été des heures de perdues :

• La version actuellement supportée de PowerShell est la version 4.0. Pensez-y.
• Si un Runbook Azure Automation peut s’exécuter pendant 300 minutes, une Azure function, c’est limité à 300 secondes. Voilà pourquoi je ne voulais pas attendre le résultat de l’exécution de mon Runbook.
• Le paramètre NoNewLine pour Out-File qui n’existe qu’en PowerShell 5 : The PowerShell 5 NoNewLine Parameter (Grand merci Mr Scripting Guy pour toutes ces années depuis VbScript)
• Le contournement à l’absence du Paramètre NoNewLine en PowerShell 4.0 : HTTP Binding in PowerShell Azure Functions
• Ne cherchez pas à importer les modules Powershell, uploader les en FTP: Using PowerShell Modules in Azure Functions
• Penser à configurer votre App Service Plan pour la plateforme X64 et non comme par défaut, c’est meilleur pour les performances.

 

Conclusion

Maintenant avec Azure Function, je suis capable d’appeler un Runbook Azure Automation avec authentification et surtout en étant capable de passer aussi un paramètre. Ce qui va nous intéresser d’autant plus, c’est l’aspect facturation. Pour une instance Azure Automation 500 minutes d’exécution dans un mois, c’est juste 1€, soit dans mon échelle trois capsules de Nespresso :

 

Avec Function App, pour un usage peu consommateur en mémoire et des API bien écrites, on a de grandes chances de ne même pas être facturé ou alors pas assez pour payer un café.

 

Ça change grandement la perception sur la conception d’applications, … A bientôt pour d’autres sujets Azure Function, toujours en PowerShell, …

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

Azure est un univers merveilleux. Le problème, c’est avant de pouvoir découvrir ses merveilles, il faut en revenir aux fondamentaux avec le premier d’entre eux : Le réseau. Sans lui pas de merveilles. Normalement, c’est une phase qui se passe à peu près bien dès lors que vos interlocuteurs réseau et sécurité sont de bonne composition. De temps en temps, il arrive que cette phase pose un challenge particulier. C’est le sujet de ce billet. Voilà ma situation de départ :

Côté expression de besoin, c’est assez simple : Permettre aux utilisateurs du siège d’accéder aux ressources (IaaS) de toutes les souscriptions en utilisant une future connexion qui pourrait être de type ExpressRoute (mais ce n’est pas obligatoire pour commencer). Histoire de corser le sujet, on a quelques contraintes :

• Les souscriptions ne sont pas liées au même tenant Azure Active Directory (sinon c’est pas drôle)
• Les souscriptions sont dans des régions Azure différentes
• L’extension du modèle avec de nouvelles souscriptions doit être simple

Mon sujet c’est l’interconnexion des différents Virtual Networks et d’assurer le routage entre eux tout en gardant en tête que cela devra fonctionner lors de la mise en place de l’interconnexion avec les réseaux locaux composant le siège.

A première vue pour l’interconnexion des Virtual Networks, le VNet Peering, c’est mort. Les contraintes sont juste bloquantes (tout du moins à ce jour). La seule solution qui nous reste, c’est donc le VNET To VNET. Ça tombe bien car :

• VNET to VNET est capable d’interconnecter des Virtual Networks dépendant de souscriptions différentes
• VNET to VNET est capable d’interconnecter des Virtual Networks dans des régions Azure sans distinction

Ce qui était bien avec le VNET Peering, c’est qu’il s’occupait automatiquement du routage. Lors de la mise en œuvre, le réseau distant était déclaré automatiquement dans le routage. On peut le constater si on regarde les routes effectives pour une machines virtuelle comme dans l’exemple ci-dessous :

Remarque : A ce jour, le User-Defined Routing ne prend pas encore en charge le VNET Peering comme choix de Next Hop type. Faudra patienter de ce côté.

Avec VNET to VNET, nous allons devoir travailler un peu. Quand on pense routage dans Azure, on pense à la fonctionnalité Azure Route Table. Quand j’ai révisé le sujet des Azure Route Table, je suis tombé ce cet avertissement.

Pas de problème pour envoyer du trafic mais comment le traiter de l’autre côté? UDR (User-Defined Routing) ne s’applique pas au trafic réseau entrant, … Par expérience, je regarde toujours les sujets dans les feedbacks Azure. Un sujet a attiré mon attention : Allow a UDR to specify any routable « next hop » IP address (not limited to the VNet or Region) :

Bref, on passe au plan B. En plus, UDR n’est pas dynamique. C’est du déclaratif. Bingo, c’est du routage dynamique dont j’ai besoin. Encore une fois, c’est un retour aux bons vieux fondamentaux. C’est à partir de maintenant que cela devient fun. On repasse en mode matériel mais dans Azure !

Il faut recommencer

C’est ma première leçon apprise sur le sujet de BGP dans Azure. C’est possible mais :

• Ce n’est disponible que pour les Gateway de type Route-Based (routage dynamique)
• Ce n’est pas par ce que la Gateway a été provisionnée en Route-Based qu’elle est prête à accepter de nouvelles informations de routage et de les propager

Ci-dessous deux Gateway créées avec le portail Azure. Quand on regarde spécifiquement la configuration de BGP, on a un problème :

 

Nos deux Gateway ont été configurées pour annoncer le même ASN. Autant vous dire tout de suite que ça ne va pas le faire. Le problème, c’est que le portail ne permet pas de configurer l’ASN annoncé lors de la création de la Gateway. Il faut donc recommencer la création de la Gateway pour préciser notre configuration de BGP.

Dans les choix des ASN, faites attention à ne pas réutiliser un ASN utilisé pour un service Microsoft voire même un de ceux utilisés On-Premises par vos équipes réseau. La lecture de la FAQ Overview of BGP with Azure VPN Gateways vous apprendra que dans la liste des ASN réservés, on a :

• Azure Public ASNs: 8075, 8076, 12076
• Azure Private ASNs: 65515, 65517, 65518, 65519, 65520

Seconde leçon, ce n’est pas par ce qu’on annonce utiliser un ASN que BGP est activé. Là encore, le portail ne nous pose pas la question. C’est à nous de l’exiger à la création de la Azure Virtual Network Gateway. J’ai jamais créé autant de Gateway que ces jours-ci!

Le portail Azure évolue tous les jours. En ce jour du 24 Aout 2017, j’ai pu constater une évolution du côté du portail lors de la création dune Azure Virtual Network Gateway. Il est désormais possible d’activer le support de BGP et l’ASN annoncé :

Tout ce dont j’ai besoin, c’est de trois Virtual Networks :

• VNETLab1
• VNETLab2
• VNETInter

Bien entendu, pas d’overlaping des espaces d’adressage, sinon ce ne sera pas drôle pour la suite. Histoire d’être clair, notre socle réseau à mettre en œuvre est le suivant :

 

On va commencer par reconstruire la Gateway VNETLab1 avec un peu de PowerShell :

$Lab1PublicIPName = « LABVNET1-IP »

$Lab1ResourceGroupName = « VNETLAB1 »

$Lab1Location = « West Europe »

$Lab1gatewayIPConfigName = « LAB1GATEWAYIP »

$Lab1VnetName = « VNETLab1 »

$Lab1GatewayName = « LABVNET1Gateway »

$Lab1gatewayBGPASN = 65011

$Lab1GatewayIP = New-AzureRMPublicIpAddress -Name $Lab1PublicIPName -ResourceGroupName $Lab1ResourceGroupName -Location $Lab1Location -AllocationMethod Dynamic

$Lab1VNET = Get-AzureRmVirtualNetwork -ResourceGroupName $Lab1ResourceGroupName -Name $Lab1VnetName

$Lab1GatewaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name « GatewaySubnet » -VirtualNetwork $Lab1VNET

$GatewayIpConfigLab1 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $Lab1gatewayIPConfigName -Subnet $Lab1GatewaySubnet -PublicIpAddress $Lab1GatewayIP

New-AzureRmVirtualNetworkGateway -Name $Lab1GatewayName -ResourceGroupName $Lab1ResourceGroupName -Location $Lab1Location -IpConfigurations $GatewayIpConfigLab1 -GatewayType Vpn -VpnType RouteBased -GatewaySku VPNGW1 -Asn $Lab1gatewayBGPASN -EnableBGP $True

 

C’est lors de la création de la Gateway qu’on associe le numéro d’ASN et qu’on active le support de BGP. Pas après. Ceci dit, faisons de même pour notre seconde Gateway :

$Lab2PublicIPName = « LABVNET2-IP »

$Lab2ResourceGroupName = « VNETLAB2 »

$Lab2Location = « North Europe »

$Lab2gatewayIPConfigName = « LAB2GATEWAYIP »

$Lab2VnetName = « VNETLab2 »

$Lab2GatewayName = « LABVNET2Gateway »

$Lab2gatewayBGPASN = 65012

$Lab2GatewayIP = New-AzureRMPublicIpAddress -Name $Lab2PublicIPName -ResourceGroupName $Lab2ResourceGroupName -Location $Lab2Location -AllocationMethod Dynamic

$Lab2VNET = Get-AzureRmVirtualNetwork -ResourceGroupName $Lab2ResourceGroupName -Name $Lab2VnetName

$Lab2GatewaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name « GatewaySubnet » -VirtualNetwork $Lab2VNET

$GatewayIpConfigLab2 = New-AzureRmVirtualNetworkGatewayIpConfig -Name $Lab2gatewayIPConfigName -Subnet $Lab2GatewaySubnet -PublicIpAddress $Lab2GatewayIP

New-AzureRmVirtualNetworkGateway -Name $Lab2GatewayName -ResourceGroupName $Lab2ResourceGroupName -Location $Lab2Location -IpConfigurations $GatewayIpConfigLab2 -GatewayType Vpn -VpnType RouteBased -GatewaySku VPNGW1 -Asn $Lab2gatewayBGPASN -EnableBGP $True

 

Entre les deux, on va avoir notre Gateway d’interconnexion nommée LABVNETInterGateway :

$LabInterPublicIPName = « LABVNETINTER-IP »

$LabInterResourceGroupName = « VNETLabInterconnect »

$LabInterLocation = « West Europe »

$LabIntergatewayIPConfigName = « LABINTERGATEWAYIP »

$LabInterVnetName = « VNETLabInterconnect »

$LabInterGatewayName = « LABVNETInterGateway »

$LabIntergatewayBGPASN = 65013

$LabInterGatewayIP = New-AzureRMPublicIpAddress -Name $LabInterPublicIPName -ResourceGroupName $LabInterResourceGroupName -Location $LabInterLocation -AllocationMethod Dynamic

$LabInterVNET = Get-AzureRmVirtualNetwork -ResourceGroupName $LabInterResourceGroupName -Name $LabInterVnetName

$LabInterGatewaySubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name « GatewaySubnet » -VirtualNetwork $LabInterVNET

$GatewayIpConfigInter = New-AzureRmVirtualNetworkGatewayIpConfig -Name $LabIntergatewayIPConfigName -Subnet $LabInterGatewaySubnet -PublicIpAddress $LabInterGatewayIP

New-AzureRmVirtualNetworkGateway -Name $LabInterGatewayName -ResourceGroupName $LabInterResourceGroupName -Location $LabInterLocation -IpConfigurations $GatewayIpConfigInter -GatewayType Vpn -VpnType RouteBased -GatewaySku VPNGW1 -Asn $LabIntergatewayBGPASN -EnableBGP $True

 

Personnaliser les policies IPSEC, ce n’est pas obligatoire mais par expérience, quand plusieurs équipements réseau On-Premises vont venir se connecter sur une Gateway, on a pas toujours les mêmes capacités sur tous les équipements. Là encore, c’est pas possible à configurer depuis le portail. Dans le cadre de ce billet, c’est optionnel :

$ipsecpolicy2 = New-AzureRmIpsecPolicy -IkeEncryption AES128 -IkeIntegrity SHA1 -DhGroup DHGroup14 -ipsecEncryption GCMAES128 -IpsecIntegrity GCMAES128 -PfsGroup PFS24 -SALifeTimeSeconds 7200 -SADataSizeKilobytes 4096

 

Vu qu’on va mettre en place des connections, on va travailler au niveau de nos Virtual Network Gateway, commençons par récupérer les informations en vue de construire les connections :

$gatewayLab1 = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $Lab1ResourceGroupName -Name $Lab1GatewayName

$gatewayLab2 = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $Lab2ResourceGroupName -Name $Lab2GatewayName

$gatewayLabInter = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $LabInterResourceGroupName -Name $LabInterGatewayName

 

On commence par les connections entre Lab1 et LabInterGateway

$ConnectionLabOneToLabInter = « ConnectionLab1toLabInter »

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabOneToLabInter -ResourceGroupName $Lab1ResourceGroupName -VirtualNetworkGateway1 $gatewayLab1 -VirtualNetworkGateway2 $gatewayLabInter -Location $Lab1Location -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

$ConnectionLabInterToLabOne = »ConnectionLabIntertoLab1″

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabInterToLabOne -ResourceGroupname $LabInterResourceGroupName -VirtualNetworkGateway1 $gatewayLabInter -VirtualNetworkGateway2 $gatewayLab1 -Location $LabInterLocation -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

 

Puis on poursuit avec les connections entre Lab2 et LabInterGateway

$ConnectionLabTwoToLabInter = « ConnectionLab2toLabInter »

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabTwoToLabInter -ResourceGroupName $Lab2ResourceGroupName -VirtualNetworkGateway1 $gatewayLab2 -VirtualNetworkGateway2 $gatewayLabInter -Location $Lab2Location -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

$ConnectionLabInterToLabtwo = »ConnectionLabIntertoLab2″

New-AzureRmVirtualNetworkGatewayConnection -Name $ConnectionLabInterToLabtwo -ResourceGroupname $LabInterResourceGroupName -VirtualNetworkGateway1 $gatewayLabInter -VirtualNetworkGateway2 $gatewayLab2 -Location $LabInterLocation -ConnectionType Vnet2Vnet -IpsecPolicies $ipsecpolicy2 -SharedKey ‘AzureA1b2C3’ -EnableBGP $True

 

Voilà, c’est en place.

Ce qui est intéressant, ce sont les effectives routes annoncées. Ci-dessous celles liée à une interface réseau liée à un sous-réseau dépendant de VNETLab1. La route vers VNETLab2 est bien annoncée avec la Virtual Network Gateway de VNETLab1 pour passer par la Gateway LABVNETInterGateway.

 

Même réponse depuis le Network Watcher : pour joindre une machine virtuelle dépendant de VNETLab2. Il annonce la Gateway de VNETLab1 :

 

Prochaine étape, quand j’aurai un peu de temps, l’intégration du VPN vers les réseaux On-Premises, toujours avec BGP.

 

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

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.

 

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.

 

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.

 

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

 

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

 

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

 

Nous devons accepter l’installation des PowershellGet NuGet.

 

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

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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 :

 

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 :

 

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.

 

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

 

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 :

• Configurer l’agent Hybrid Worker pour utiliser un proxy pour accéder aux seules URL des services nécessaires dans Azure : Azure Automation Hybrid Runbook Worker supports proxy environments
• S’authentifier sur les systèmes distance avec un certificat : How to use WSMan config provider for certificate authentication

 

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

• https://blogs.technet.microsoft.com/ashleymcglone/2016/06/29/whos-afraid-of-powershell-security/

 

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