Archives de catégorie : Azure Automation

Ma session au Powershell Saturday 2018

Ce samedi s’est déroulé l’édition française du PowerShell Saturday dans les locaux de Cellenza. Pendant, cette édition, j’ai eu l’occasion de présenter l’avancement sur Resource Group As a Service. Resource Group As a Service est un sujet que j’avais déjà présenté lors du Global Azure Bootcamp de 2018.

clip_image001

A l’époque, on était plus proche du PoC of Concept, entre temps, le développement a beaucoup avancé. Aujourd’hui, nous sommes maintenant plus proche du Minimum Viable Product. L’objectif de cette session n’était pas de présenter la solution en elle-même mais ce que son développement m’a permis d’apprendre sur Azure Function, Azure Automation et sur PowerShell lui-même. C’est donc plus une session de retour sur expérience.

Pour ceux que cela intéresse, la présentation ainsi que les exemples PowerShell présentés sont disponibles à cette URL.

 

Benoît – Simple and Secure by Design but Business compliant

Azure Automation en panne de certificats?

Azure Automation, quand ça fonctionne, on ne s’en occupe plus. C’est un service que nous avons provisionné voilà presque un an, nous avons maintenant quantité de Runbooks qui s’exécutent régulièrement. C’est peut-être un service qui fonctionne tout seul mais de temps en temps y a un peu de maintenance et un matin, tout s’arrête de fonctionner. Bizarrement, tous les Runbooks semblent avoir le même problème d’authentification avec Azure, …

clip_image001

clip_image002

Tout de suite ça ressemble à un problème de certificat. Normalement, cela devrait faire tilt. Azure Automation référence des certificats (au moins deux) comme méthodes d’authentifications :

clip_image003

Et oui, même un certificat auto-signé ça expire. Le problème, c’est que ce sont ces certificats qui sont utilisés pour mettre en œuvre les objets connections que nous consommons dans le code PowerShell de nos Runbooks. Le portail Azure ne nous prévient pas (ou tout du moins pas encore) de l’imminence de la date fatidique. C’est une fois les certificats expirés qu’on constate le message suivant dans notre instance Azure Automation.

clip_image004

La solution la plus simple, c’est de suivre le processus pour renouveler les certificats pour chaque RunAs Accounts. Le portail vous proposera de renouveler les deux certificats.

clip_image005

C’est bien mais on peut faire mieux. Renouveler des certificats auto-signés, c’est prendre le risque d’oublier que l’année prochaine on va encore les oublier. Il est temps de reprendre en main le sujet et d’imposer nos propres dates de renouvellement de certificats auto-signés. Pour rappel, c’est un sujet que j’avais abordé dans le billet : Parlons d’identité avec Azure Automation. On peut même faire mieux, demander à notre équipe sécurité de nous fournir un certificat. Si leurs process sont bien faits, ils doivent vous prévenir de l’expiration des certificats qu’ils vous ont mis à disposition.

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

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)

Parlons d’identité avec Azure Automation

Azure Automation, est un composant avec lequel je passe beaucoup de temps en ce moment. C’est un composant intéressant qui mérite qu’on y passe un peu de temps, surtout lorsque celui-ci nous parle d’identité. C’est ce qui arrive lors de la création d’une instance de ce service si on ne dispose pas des privilèges nécessaires. C’est le cas illustré ci-dessous. Ce qu’il faut comprendre, c’est que nous ne pouvons pas créer un certain nombre d’objets dans le tenant Azure AD et positionner des permissions.

clip_image001

Pourquoi est-ce important ? Tout simplement parce que c’est sous cette identité que nous allons exécuter nos futurs Runbooks. Dans ma situation, j’ai bien le niveau de privilège « Owner » sur mon groupe de ressources mais absolument aucun privilège dans le tenant Azure AD lié à ma souscription Azure. Du point de vue Azure Automation, il m’indique bien qu’il a un problème avec les « Run As Accounts » ?

clip_image002

 

On notera qu’il existe deux type de « Run As Accounts » :

  • Azure Run As Account
  • Azure Classic Run As Account

Pour faire court, le premier est destiné à gérer les ressources de type ARM et le second les ressources de type ASM, donc l’ancien Azure. Dans mon cas, ça ne sera pas possible puisque je suis sur une souscription Azure CSP. Nous allons donc devoir créer un « Azure Run As Account ». C’est maintenant que cela commence à piquer un peu. Le portail Azure nous donne un indice, ce qui manque, c’est une identité, un Service Principal qui va être associé à une application dans Azure AD. Si nous n’avons pas les privilèges sur le Tenant Azure AD lié à notre souscription Azure, il faudra réaliser la création manuellement. L’opération comprendra plusieurs étapes :

  • La création d’un certificat
  • Créer une application Azure AD
  • Assigner un rôle RBAC
  • Déclaration du Certificat dans Azure Automation
  • Déclaration de la connexion dans Azure Automation
  • Consommer l’identité dans un Runbook

 

La création d’un certificat

L’instance du Service Azure Automation a besoin d’un certificat. Ce certificat sera référencé comme un « Asset » dans Azure Automation., nous y reviendrons. Pour le certificat en lui-même, il peut être auto-signé ou délivré par une autorité de certification. Lorsqu’on laisse faire le portail, il va générer un certificat auto-signé d’une durée de vie d’un an. C’est court. Est-ce qu’on va se souvenir que ce certificat va expirer si le portail a fait tout cela pour nous ? Non. Le portail Azure ne nous préviendra pas. La seule chose qu’il va nous proposer, c’est l’option « Rewnew certificate » comme illustré ci-dessous :

Celui-ci sera lié à notre Application Azure AD. Vu qu’on va avoir besoin du certificat pour créer notre Application Azure AD, on va commencer par lui. Notre première décision sera de définir les caractéristiques principales de ce certificat :

  • Nom
  • Date d’expiration

clip_image003

Par contre, ce qui est bien, c’est qu’on a maintenant sous les yeux tous les ingrédients. Pour notre démonstration, nous allons créer un certificat auto-signé d’une durée de vie de deux ans :

$CertName = « automation.simplebydesignlabs.fr »

$CurrentDate =Get-Date

$EndDate = $currentDate.AddYears(2)

$NotAfter = $endDate.AddYears(2)

$CertStore = “Cert:\LocalMachine\My”

$CertThumbprint =(New-SelfSignedCertificate -DnsName « $certName » -CertStoreLocation $CertStore -KeyExportPolicy Exportable -Provider « Microsoft Enhanced RSA and AES Cryptographic Provider » -NotAfter $notAfter).Thumbprint

$CertThumbprint

clip_image004

Ce n’est pas précisé mais le certificat est exportable et c’est vivement recommandé si on veut plus tard déployer des Hybrid Worker Group. Nous allons exporter ce certificat.

$pfxPassword = ConvertTo-SecureString -String « LeMotDePasseIlAChangé! » -AsPlainText -Force

$pfxFilepath = « C:\Temp\automation.PFX »

Export-PfxCertificate -Cert « $($certStore)\$($certThumbprint) » -FilePath $pfxFilepath -Password $pfxPassword

clip_image005

C’est maintenant que cela se complique. Pour permettre à notre instance Azure Automation de s’authentifier, il faut la référencer sous la forme d’une application Azure AD. Cette application devra présenter le certificat exporté. Ce sera sa méthode d’authentification. Nous devons donc préparer un objet « PSADKeyCredential » dans lequel nous allons référencer le certificat et ses principales caractéristiques :

Import-Module -Name AzureRM.Resources

$Cert =New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate -ArgumentList @($pfxFilepath, $pfxPassword)

$KeyValue =[System.Convert]::ToBase64String($cert.GetRawCertData())

$KeyId =[guid]::NewGuid()

$KeyCredential = New-Object -TypeName Microsoft.Azure.Commands.Resources.Models.ActiveDirectory.PSADKeyCredential

$KeyCredential.StartDate = $currentDate

$KeyCredential.EndDate = $endDate

$KeyCredential.KeyId = $keyId

$KeyCredential.CertValue = $keyValue

$KeyCredential

clip_image006

 

Créer une application Azure AD

Prochaine étape, déclarer notre application dans Azure AD et y associer un Service principal :

$AADAppName = « Automation_APP »

$adAppHomePage = « « 

$adAppIdentifierUri = « « 

$AADApp = New-AzureRmADApplication -DisplayName $AADAppName -HomePage $adAppHomePage -IdentifierUris $adAppIdentifierUri -KeyCredentials $KeyCredential

New-AzureRmADServicePrincipal -ApplicationId $AADApp.ApplicationId -KeyCredential $KeyCredential

clip_image007

 

Assigner un rôle RBAC

Nous avons maintenant une identité. Encore faut-il que celle-ci dispose de privilèges dans la souscription Azure. Dans mon contexte, j’ai fait au plus restreint, à savoir limité à un groupe de ressources nommé Gestion, pour lequel le Service principal dispose du niveau de privilèges « Contributor » (gestion des ressources existantes dans le groupe de ressources).

New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $($AADApp.ApplicationId) -ResourceGroupName Gestion

clip_image008

Au passage, si on laisse faire le portail, c’est le niveau de privilège « Owner » qui est positionné sur la souscription. Votre RSSI appréciera, ou pas.

 

Déclaration du Certificat dans Azure Automation

La première opération qu’un Runbook Azure Automation, c’est de s’authentifier auprès d’Azure. Cette authentification sera faite sous l’identité du Service Principal. Pour que l’authentification fonctionne, encore faut-il qu’Azure Automation dispose du certificat. Azure Automation va mettre à disposition le certificat lors de chaque exécution de Runbook. On va donc référencer cet « Asset » dans notre instance du service Azure Automation sous le nom « AzureRunAsCertificate ». On verra plus tard que le nom a son importance.

$AutomationCertAsset = « AzureRunAsCertificate »

$AutomationAccountName = « Automation »

$AutomationResourceGroupname = « Gestion »

New-AzureRmAutomationCertificate -Name $AutomationCertAsset -Path $pfxFilepath -Password $pfxPassword -AutomationAccountName $AutomationAccountName -ResourceGroupName $AutomationResourceGroupname

clip_image009

On notera que ce certificat est maintenant impossible à exporter. C’est une bonne chose d’un point de vue sécurité.

Déclaration de la connexion dans Azure Automation

C’est maintenant qu’on va créer le « Run As Account ». Dans notre cas, nous allons créer un « Run As Account » pour un Service Principal qui utilise un certificat pour s’authentifier. Nous devons disposer d’un certain nombre de paramètres :

  • L’identifiant unique de l’application Azure AD précédemment créée
  • L’identifiant unique du tenant Azure AD dans lequel l’Application Azure AD a été créée
  • L’empreinte numérique du certificat que nous avons associé à l’Application Azure AD
  • La souscription Azure dans laquelle l’application Azure AD va se connecter

$ConnectionAssetName = « AzureRunAsConnection »

$ConnectionFieldValues = @{« ApplicationId » = $AADApp.ApplicationId; « TenantId » = (Get-AzureRmContext).Tenant.Id; « CertificateThumbprint » = $CertThumbprint; « SubscriptionId » = (Get-AzureRmContext).Subscription.Id}

$ConnectionFieldValues

New-AzureRmAutomationConnection -ResourceGroupName $AutomationResourceGroupname -AutomationAccountName $AutomationAccountName -Name $ConnectionAssetName -ConnectionTypeName AzureServicePrincipal -ConnectionFieldValues $ConnectionFieldValues

clip_image010

 

Si tout se passe bien, voilà ce que vous devriez avoir dans les « Run As Accounts » de votre instance Azure Automation :

clip_image011

 

On retrouve bien toutes les informations que nous avons renseigné.

clip_image012

 

Maintenant le truc sur lequel j’ai passé le plus de temps. Si vous avez scrupuleusement respecté les étapes indiquées, cela fonctionne. Par contre, si vous avez eu le malheur de changer le nom de l' »Asset » du certificat, le portail n’est pas d’accord. Il vous indique que votre configuration est incomplète. Pour le portail, c’est clairement le certificat qui est en cause.

clip_image013

 

C’est un problème lié au portail, ce qui n’empêche pas le fonctionnement des Runbooks. Le problème a été remonté chez Microsoft car si la configuration est considérée comme incomplète, le portail Azure ne nous permet pas de renouveler notre certificat.

 

Consommer l’identité dans un Runbook

Créer une identité, c’est bien, la consommer c’est mieux. J’ai fait au plus court avec un Runbook PowerShell des familles :

[OutputType([String])]

$connectionName = « AzureRunAsConnection »

try

{

# Get the connection « AzureRunAsConnection « 

$servicePrincipalConnection=Get-AutomationConnection -Name $connectionName

« Logging in to Azure… »

Add-AzureRmAccount `

-ServicePrincipal `

-TenantId $servicePrincipalConnection.TenantId `

-ApplicationId $servicePrincipalConnection.ApplicationId `

-CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

« Logged to Azure »

}

catch {

if (!$servicePrincipalConnection)

{

$ErrorMessage = « Connection $connectionName not found. »

throw $ErrorMessage

} else{

Write-Error -Message $_.Exception

throw $_.Exception

}

}

Get-ChildItem cert:\currentuser\my

 

Lors de l’exécution, vous allez découvrir que le certificat utilisé est dans le magasin de l’utilisateur et non de l’ordinateur :

clip_image014

 

Voilà tout ce qui se cache derrière le portail Azure lors de la création d’une instance du service Azure Automation en mode « Click Next Finish ».

 

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