Archives par étiquette : Azure Automation

Automatiser Azure Update Management avec Azure Policy

Avoir de nombreuses machines virtuelles dans Azure implique de les gérer au niveau Patch Management. Sur le papier, on a un service nommé « Update Management » dans Azure Automation. Le problème, c’est que c’est nous qui devons associer chaque machine virtuelle à une politique de Patch Management. C’est une tâche rébarbative dont on se passerait bien. L’idéal serait que le propriétaire puisse inscrire lui-même sa machine virtuelle dans une politique de Patch Management sous forme de choix imposé.

 

Utilisation des tags dans le Patch Management des VM

Les tags permettent de gérer les ressources manière industrielle. Nous allons introduire un tag obligatoire sur les objets machines virtuelles nommé UpdatePolicy. Nous allons utiliser Azure Policy pour imposer deux règles :

  • La présence d’un tag UpdatePolicy
  • Les valeurs associées au tag UpdatePolicy doivent correspondre à une liste établie.

 

La première règle permet de m’assurer que toute machine virtuelle nouvellement créée ou mise à jour sera automatiquement associée à une politique de Patch Management. La seconde permet de s’assurer que seules les valeurs autorisées sont utilisées. Puis, nous allons réutiliser ces tags pour inscrire les machines virtuelles dans des Dynamic Groups au sein d’Update Management.

 

Imposer une politique de patching par défaut

Pour imposer une politique de Patching, nous avons besoin de mettre en place une Azure Policy en mode Append qui va vérifier que le tag UpdatePolicy est bien présent sur les ressources de Type VirtualMachines. Si ce n’est pas le cas, nous allons proposer une valeur par défaut. Une Azure Policy, c’est composé de deux parties. La première partie, c’est la règle en elle-même. La Policy en elle-même repose sur une double condition, à la fois sur le type de ressource impliquée (Microsoft.Compute/VirtualMachines) et l’absence d’un tag particulier dont son nom est précisé en paramètre. Si cette condition est remplie, un tag est ajouté avec une valeur par défaut.

clip_image002

 

Jusqu’à maintenant, on voit bien que la règle est générique, il nous manque des paramètres. C’est l’objectif du second fichier référençant les paramètres. Pas grand-chose à dire à son sujet.

clip_image003

 

Ne reste plus qu’à importer notre Policy au niveau du scope de notre souscription avec la commande New-AzPolicyDefinition

[String]$SubscriptionID = (Get-AzContext).Subscription.id

[String]$Scope = « /subscriptions/$SubscriptionID/ »

[String]$PolicyDefinitionFileURI = « https://raw.githubusercontent.com/Benoitsautierecellenza/DemoPolicy/master/Policies/AZ-DEFAULTTAG/AZ-DEFAULTTAG-01-RULE.json »

[String]$PolicyParameterFileURI = « https://raw.githubusercontent.com/Benoitsautierecellenza/DemoPolicy/master/Policies/AZ-DEFAULTTAG/AZ-DEFAULTTAG-01-PARAMETERS.json »

[String]$PolicyName = « DefautltValue4UpdatePolicy »

[String]$PolicyDisplayName = « $PolicyName »

New-AzPolicyDefinition -Name $PolicyName `

-DisplayName $PolicyDisplayName `

-Policy $PolicyDefinitionFileURI `

-Parameter $PolicyParameterFileURI `

-Subscription $SubscriptionID `

-Mode All

clip_image005

 

Notre Azure Policy est maintenant être à être assignée au niveau de la souscription (ou resource group au sein de la souscription) avec la commande New-AzPolicyAssignment.

[String]$UpdatePolicyTagName = « UpdatePolicy »

[String]$DefaultTagValue = « AlwaysReboot »

[String]$PolicyName = « DefautltValue4UpdatePolicy »

[String]$PolicyAssignname = « MGMT01-VM-P1 »

[String]$Scope = « /subscriptions/$SubscriptionID/ »

$PolicyDefinition = Get-AzPolicyDefinition -SubscriptionId $SubscriptionID -Custom | Where-Object {$_.name -eq $PolicyName}

$AssignParameters = @{

‘UpdatePolicyTagName’ = $UpdatePolicyTagName;

‘DefaultTagValue’=$DefaultTagValue

}

New-AzPolicyAssignment -Name $PolicyAssignname `

-PolicyDefinition $PolicyDefinition `

-Scope $Scope `

-PolicyParameterObject $AssignParameters

clip_image007

 

C’est lors de l’assignation qu’on renseigne les valeurs des paramètres que nous allons utiliser. Dans notre contexte, nous avons deux paramètres :

  • UpdatePolicyTagName : UpdatePolicy
  • DefaultTagValue : AlwaysReboot

 

Imposer un choix de politique de Patching

Si on laisse faire les consommateurs, ils peuvent renseigner une valeur pour notre tag UpdatePolicy mais encore faut-il que celle-ci correspondre à une liste de valeur préétablies que l’on pourra reconnaître. Problème, les valeurs des tags sont sensibles à la case, donc « AlwaysReboot » est différent de « Alwaysreboot ». Pour éviter ce type de problème, nous allons utiliser une seconde Azure Policy pour imposer une des valeurs ci-dessous pour notre tag « UpdatePolicy » :

  • AlwaysReboot
  • RebootIfRequired
  • OnlyReboot
  • NeverReboot

 

Notre Azure Policy reprend le même principe que pour la première avec la double condition. La subtilité, c’est que cette fois, nous savons que le tag existe forcément. Nous devons refuser toute mise à jour de celui-ci qui ne contiendrait pas une des valeurs correspondant à cette autorisée (d’où l’usage du « In »). Si les deux conditions sont remplies alors on refuse l’opération.

clip_image009

 

Le fichier de réponse correspond à peu de choses près à la Policy précédente, si ce n’est l’utilisation du type « Array » pour décrire non pas une chaine de caractère mais une liste.

clip_image011

 

Le processus d’importation de notre Azure Policy ne change pas.

[String]$SubscriptionID = (Get-AzContext).Subscription.id

[String]$Scope = « /subscriptions/$SubscriptionID/ »

[String]$PolicyDefinitionFileURI = « https://raw.githubusercontent.com/Benoitsautierecellenza/DemoPolicy/master/Policies/AZ-ALLOWEDTAGVALUES/AZ-ALLOWEDTAGVALUES-02-RULE.json »

[String]$PolicyParameterFileURI = « https://raw.githubusercontent.com/Benoitsautierecellenza/DemoPolicy/master/Policies/AZ-ALLOWEDTAGVALUES/AZ-ALLOWEDTAGVALUES-02-PARAMETERS.json »

[String]$PolicyName = « AllowedTagValues4UpdatePolicy »

[String]$PolicyDisplayName = « $PolicyName »

New-AzPolicyDefinition -Name $PolicyName `

-DisplayName $PolicyDisplayName `

-Policy $PolicyDefinitionFileURI `

-Parameter $PolicyParameterFileURI `

-Subscription $SubscriptionID `

-Mode All

clip_image013

Tout comme son assignation. La seule subtilité à ce niveau concerne le passage de la liste des valeurs autorisées pour notre tag.

[String]$PolicyAssignname = « Assign-$PolicyName »

$UpdatePolicyTagName = « UpdatePolicy »

$AllowedValues = @(« AlwaysReboot », »RebootIfRequired », »OnlyReboot », »NeverReboot »)

$PolicyDefinition = Get-AzPolicyDefinition -SubscriptionId $SubscriptionID | Where-Object {$_.Properties.displayname -eq $PolicyDisplayName}

$AssignParameters = @{

‘UpdatePolicyTagName’ = $UpdatePolicyTagName;

‘UpdatePolicyTagAllowedValues’=($AllowedValues)

}

New-AzPolicyAssignment -Name $PolicyAssignname `

-PolicyDefinition $PolicyDefinition `

-Scope $Scope `

-PolicyParameterObject $AssignParameters

clip_image015

 

Associer nos machines virtuelles à des groupes dynamiques

Maintenant, cela se passe dans Azure Automation. Je pars du principe que la fonctionnalité Update Management a été activée sur l’instance Automation. Nous allons créer des Deployment Schedules pour chaque type d’OS et chaque type de Policy. Finalement, on doit créer huit Deployment Schedules. Vu que c’est toujours les mêmes opérations, j’ai industrialisé avec le scripts CreateDeploymentSchedules.ps1. Je vous laisse le personnaliser mais dans l’ensemble, il fait le job et on obtient le résultat ci-dessous :

clip_image017

 

A ce stade, nous n’avons plus qu’à patienter un peu que les groupes dynamiques se peuplent

clip_image019

 

Conclusion

Félicitation, vous avez un exemple fonctionnel de service Patching as A Service. Le procédé est déclinable pour imposer la sauvegarde, il faudra juste un peu d’huile de coude et de Runbooks pour gérer l’enregistrement dans Azure Backup mais c’est le même principe. Ce sera certainement le thème du prochain billet.

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)

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)