Seconde partie pour cet article consacré à la nouveauté Azure Auto Manage, Configuration management. La première partie est à retrouver sur ce lien : https://thierrybtblog.wordpress.com/2023/09/27/azure-automanage-configuration-de-machines-1-3/
Rappel Important de cette première partie, ce n’est plus le moteur de configuration intégré (LCM) de DSC qui va traiter LE fichier de configuration mais les Azure Policy qui vont traiter LES fichiers de configuration. Différence … importante !
Il y a lorsque l’on aborde ce nouveau sujet pas mal de documentations à lire et pas mal d’étapes à dérouler pour utiliser cette fonctionnalité. Rien de mieux qu’un schéma (peut-être un peu « copieux ») pour mieux comprendre les différentes étapes de mise en œuvre.
On trouve sur la partie basse (en gris) une mise en œuvre de type CI/CD réalisée avec Azure Devops ou avec Gitlab par exemple.
Mais c’est plutôt la partie haute qui va décrire les étapes de mise en œuvre. Dans cette partie 2 de l’artcile, la présentation théorique des différentes étapes.
Première étape, les prérequis pour pouvoir préparer ses configurations. Ici, on utilise Powershell Core dans sa version la plus récente si possible, ou à minima, une version 7 et +. A installer depuis le repo des releases dispo à cette adresse : https://github.com/PowerShell/PowerShell/releases
Version en cours, 7.3.9
Puis on ajoute le module dédié, GuestConfiguration, qui va permettre de préparer les configurations. Rien à signaler de ce côté. Rien à signaler jusqu’au prochain article ou on verra ensemble qu’il peut y avoir quelques surprises avec ce module.
Seconde étape, préparer une configuration de type DSC. C’est à dire une configuration déclarative, ce que l’on veut obtenir (et maintenir). Pour les utilisatrices / utilisateurs de DSC, pas de différence avec l’existant.
Si vous n’avez jamais utilisé DSC, voici une configuration passe partout que je présente dans un article dédié pour réaliser ses premiers pas avec DSC : https://thierrybtblog.wordpress.com/2018/06/18/votre-premiere-configuration-dsc-1-2/
Ce code va servir lors de la préparation des artefacts présentée prochainement en détail dans la partie 3/3.
Configuration Clef1 {
Node ‘DSC2’ {
Registry RegistryExemple
{
Ensure = "Present"
Key = "HKEY_LOCAL_MACHINE\SOFTWARE\Clef1"
ValueName = "Le nom de ma clef "
ValueData = "La valeur de ma clef"
}}}
Clef1
3 ème étape, faire de cette configuration, un Artefact.
Là, c’est assez nouveau. Une configuration DSC, c’est un fichier PS1 (Powershell) qui est compilé par des commandes DSC et qui devient un fichier Mof (Managed Object Format).
Il y a maintenant l’ajout d’une étape, ce mof devient avec des commandes du module GuestConfiguration un fichier Zip.
Pour résumer : PS1 => MOF => ZIP
Nous verrons que ce fichier est consommée façon assez particulière.
4 ème étape, valider la conformité du fichier. C’est à dire vérifier la présence des modules et dépendances par exemple. Ce n’est pas spécifique à GuestConfiguration mais plutôt à DSC.
Une parenthèse à ce sujet. DSC est livré de base avec quelques modules. Mais avec le temps, ce sont plusieurs milliers de modules qui sont disponibles. Si la configuration souhaitée fait appel à une module particulier, il faut qu’il soit disponible.
Valider la conformité, c’est donc vérifier ce point (et quelques autres) avant de pouvoir se dire que l’artefact est valide. Une autre exemple, jouer à blanc le fichier pour vérifier qu’il peut contrôler la configuration ou l’appliquer.
5 ème étape, publier l’artefact. Attention, cette partie sera présentée en détail (très en détail), c’est en fait une opération de copie des fichiers Zip de configuration sur un compte de stockage Azure. Si possible (même si cette étape est facultative), en utilisant un jeton SAS pour garantir un accès sécurisé au package stocké.
6 ème étape, créer une définition Azure Policy. Ici, il va falloir s’accrocher un peu. Un peu de teasing sur la 3 ème partie du sujet.
Au premier abord, pas très inspirant…!
Pourtant, on retrouve quelque uns des points dont il a été question un peu + haut. Par exemple, la variable $contentURI qui est l’URI HTTP(S) public du package de contenu configuration de machine.
Dans la ligne Path = './policies/auditIfNotExists.json', la définition de policy Azure. Rien de mystérieux, mais il faudra expliquer ce contenu pas à pas. Cette partie ne peut être correctement comprise sans une mise en œuvre complète, il faudra patienter un peu avant de retrouver cella dans la partie 3/3 de l’article.
Ce n’est pas tout avec cette 6ème étape.
Les commandes du module GuestConfiguration ne vont créer qu’un (petite) partie de la policy. Le cœur de la configuration. Mais toutes les données périphériques sont à ajouter directement dans le Json généré par le module.
Une Policy, c’est une règle ou un ensemble de règles qui vont identifier des ressources et certains de leurs paramètres. Puis y appliquer un effet, comme par exemple l’audit, le deny, la remédiation …etc.
Si la partie effet et contenu est bien traitée par le module, la règle d’application peut / doit être revue.
Le json va être enrichi du filtre d’application. Voir ci dessous un exemple fourni dans la documentation éditeur.
Si allOf (c’est à dire si toutes les conditions sont remplies), alors j’applique l’effet de la stratégie.
Dans l’exemple si tag Owner = BusinessUnit et si tag Role = Web, alors j’applique l’effet.
Dernier point pour terminer ce sujet, l’attribution des configurations ne reprend qu’une partie des effets disponible dans les policy Azure. Si les policy « historiques » sont capables d’appliquer les effets suivants (la liste a évoluée ces derniers temps) …
AddToNetworkGroup
Append
Audit
AuditIfNotExists
Deny
DenyAction
DeployIfNotExists
Disabled
Manual
Modify
Mutate
… les policy version GuestConfiguration sont un peu moins riches et même différentes dans le mode de fonctionnement.
Deux modes disponibles, AuditIfNotExists et DeployIfNotExists .
Mais complété par la valeur Type du package qui détermine si la configuration doit uniquement effectuer un audit ou si la configuration doit modifier l’état de l’ordinateur (AuditandSet ou Audit).
Surchargé du type d’attribution Audit, ApplyAndMonitor et ApplyAndAutoCorrect.
Bon, Ok, assez opaque, mais je le répète (ne fuyez pas), ce sera BEAUCOUP + clair lors de la mise en œuvre.
Toute dernière étape, mais qui n’en est pas vraiment une, la visualisation des résultats.
Là, c’est habituel, direction la console Policy Azure qui offre tout ce qu’il faut pour avoir un rapport clair et précis de ses configurations.
RDV dans quelques jours pour une première mise en application.
Et le moins que l’on puisse dire, c’est que c’est une solution qui DEPOTE ! Un peu subtile dans la mise en œuvre, mais ça vaut vraiment l’investissement 😉
Une techno, des infos. 