L'une de nos principales activités chez Claranet est de fournir des services d'infogérance, aussi bien sur notre cloud privé que pour les fournisseurs de cloud public comme AWS ou Azure, pour lesquels nous sommes un MSP reconnu et considéré comme un leader par le Gartner Magic Quadrant.
Dans ce cadre, nous sommes responsables de nombreux workloads IaaS sur Azure que nous maintenons et exploitons pour nos clients.
Une partie importante de ces workloads sont des VM "classiques" (c'est-à-dire non incluses dans un Scale Set) qui ont été déplacées ou construites sur Azure.
Avec ces VMs, vient la galaxie obligatoire d'outils pour la sauvegarde, la surveillance, la gestion des mises à jour, la gestion des configurations, la gestion des logs, etc. Pour certains d'entre eux, le passage d'un service patrimonial à un service de fournisseur de cloud est assez facile et semble tout à fait logique. Par exemple, l'utilisation d'Azure Backup comme solution de sauvegarde et de restauration peut être une décision évidente.
La gestion des mises à jour, en revanche, est un sujet sensible, et passer d'une solution établie et maîtrisée à un service de fournisseur de cloud peut être un peu effrayant. Sera-t-on capable de la contrôler aussi bien qu'avant, de pousser rapidement une mise à jour de sécurité critique, d'éviter de déployer un patch qui fait planter notre application ? Ce sont des questions légitimes, découvrons si les services Azure ont des réponses.
Pourquoi devrais-je m'y intéresser ?
La première chose qui vient à l'esprit lorsqu'on choisit une solution de gestion des mises à jour est d'utiliser les outils déjà déployés dans l'entreprise, comme WSUS, SCCM ou Red Hat Satellite. Cela peut s'avérer être une stratégie efficace car les VM Azure seraient intégrées dans un processus bien connu et (dans la plupart des cas) bien géré. L'équipe IT gère donc les mises à jour sur Azure VM comme elle le fait sur d'autres plates-formes (c'est-à-dire sur site).
Il y a quelques éléments à prendre en compte avec cette approche :
- Les VM Azure doivent se connecter aux serveurs / référentiels de mise à jour sur site, en sortant d'Azure pour leur rendre compte et en entrant dans Azure pour télécharger les mises à jour via une connexion VPN ou Express Route.
- Ces solutions fournissent rarement une planification des mises à jour sur la VM cible, de sorte que les configurations de mise à jour sur les VM sont déployées avec un autre outil (AD GPO, Puppet, ...), les planifications ou les exécutions sont gérées par un autre (comme Ansible) et l'équipe informatique doit également maintenir ces outils liés.
- Les VMs Azure n'exploitent pas les services cloud construits pour alléger les tâches administratives redondantes.
Azure fournit un ensemble de solutions pour faciliter la gestion des mises à jour avec un état d'esprit légèrement différent. Elles sont destinées à réduire l'effort administratif de l'équipe informatique en fournissant un service automatisé aux fonctionnalités plus légères. Il faut garder à l'esprit que ces services sont conçus pour que les entreprises se concentrent sur leur travail principal, et perdent donc un peu de précision sur des actions techniques de faible valeur. Faire simple : l'équipe informatique délègue la gestion des mises à jour à Azure et gagne du temps pour se concentrer sur des tâches plus complexes.
Pour envisager un monde sans serveur de mise à jour / référentiel géré par l'entreprise, une question qui mérite d'être posée est de savoir combien de mises à jour défectueuses ont été rencontrées et quels ont été leurs impacts ? Si le ratio est assez faible, alors les solutions Azure valent la peine d'être essayées - avec une adaptation du processus de mise à jour si nécessaire, toujours dans le but de réduire les risques de déployer une mise à jour défectueuse sur une VM de production.
Deux services peuvent aider les entreprises à déployer les mises à jour, chacun avec un niveau de contrôle différent. Azure Update Management permet de créer des planifications pour définir le quand (heure et récurrence), le qui (VM cibles) et le quoi (mises à jour). Azure Automatic Updates by Platform gère le quand et le quoi, vous laissant décider des VM qui doivent en bénéficier. Voyons un peu plus en détail ces services.
Note : ces services ne déploient que des mises à jour pour le système d'exploitation sur Windows, pas pour les middlewares ni les applications. Sur Linux, toutes les mises à jour gérées par le gestionnaire de paquets (comme yum ou apt) peuvent être incluses.
Azure Update Management (Automation)
Aperçu
La principale fonctionnalité pour gérer les mises à jour est Azure Update Management, une solution gratuite basée sur Azure Automation et dépendant d'un Log Analytics Workspace.
Le comportement est simple : on peut le voir comme un planificateur qui envoie l'ordre aux VM de se mettre à jour avec quelques contraintes (comme les classifications de mise à jour). Lorsque la commande est reçue par la VM, son service de mise à jour utilise la configuration locale de la VM pour télécharger et installer les mises à jour. Plus de détails sont disponibles sur la documentation Microsoft : https://docs.microsoft.com/en-us/azure/automation/update-management/mana....
Cela signifie que si un WSUS est configuré comme serveur de mise à jour, ou si un dépôt de mise à jour Linux spécifique est déclaré, la VM Azure interagira toujours avec lui. L'utilisation d'un serveur ou d'un dépôt de mise à jour personnalisé en plus d'Azure Update Management est un point à atténuer : vaut-il mieux garder le contrôle et le reporting par le biais d'un serveur de mise à jour, avec les inconvénients mentionnés plus haut, ou relâcher légèrement le contrôle sur les mises à jour en utilisant une source de mise à jour publique et se "déconnecter" de l'ancien outil pour minimiser l'interaction humaine ? Une autre caractéristique de ce service est la possibilité de cibler des VM non-Azure. Cette solution peut donc être propagée sur des VMs déployées sur site ou sur un autre Cloud public, devenant ainsi un point de gestion central des mises à jour.
Le déploiement de la solution est facile et peut se faire via le portail Azure ou avec un outil Infra as Code comme Terraform (le fournisseur AzureRM ne supporte pas encore une ressource explicite pour cela mais permet un déploiement de modèle comme solution de contournement).
Prérequis :
- Un espace de travail Log Analytics
- Un compte d'automatisation dans la même région
- Compte d'automatisation et Log Analytics Worskapce liés ensemble (peut être fait pendant la phase de déploiement)
- Des VMs cibles connectées à l'espace de travail Log Analytics.
Le service peut être indisponible dans certaines régions Azure, car la fonctionnalité permettant de lier un Log Analytics Workspace et un Automation n'est pas encore disponible partout.
Déploiement - Portail Azure
Étapes du déploiement :
Sur le compte Automation, allez dans la partie Gestion des mises à jour et cliquez sur Activer (vous pouvez lier le compte Automation à l'espace de travail Log Analytics à cette étape).
Ajoutez des VM avec le bouton dédié en haut ou activez-le pour toutes les VM connectées à l'espace de travail, y compris les futures, en cliquant sur Manage machines et sélectionnez Enable on all available and future machines.
Après quelques minutes, les VMs apparaîtront et partageront leur statut de mise à jour. Toute mise à jour manquante sera exposée ici. Après avoir été signalées à cette solution, les VM peuvent être incluses dans une planification en tant que cibles pour l'application de correctifs.
Configuration du portail d'une planification
Pour chaque groupe de machines virtuelles, un programme de déploiement doit être créé avec les cibles correspondantes (préférez l'utilisation du regroupement dynamique pour ajouter toutes les machines virtuelles dans un groupe de ressources spécifique ou avec une étiquette commune) et la configuration (temps / classifications / exclusions / comportement de redémarrage).
En utilisant les groupes, vous définissez les critères qu'Azure utilisera pour sélectionner les VM. Il y a même un bouton de prévisualisation pour s'assurer que le ciblage est configuré correctement.
Deployment - Terraform sample
Bien qu'il n'existe pas de ressource Terraform dédiée à utiliser pour déployer une solution de gestion des mises à jour, il est possible de le faire avec la ressource azurerm_template_deploymentresource pour inclure ARM dans Terraform. Considérant que les conditions préalables sont en place, le service est activé en tant que solution d'analyse des journaux et les planifications sont déployées. Il s'agit d'un exemple assez simple et le code peut évidemment être amélioré. Nous utilisons nos propres modules pour déployer d'autres ressources, comme indiqué dans cet article, une liste complète des modules publics de Claranet est maintenue ici.
Donc, tout d'abord, activez la solution avec ce qui suit :
# Create solution for Update Management
resource "azurerm_log_analytics_solution" "update_management" {
solution_name = "Updates"
location = module.azure-region.location
resource_group_name = module.rg.resource_group_name
workspace_resource_id = module.run-common.log_analytics_workspace_id
workspace_name = module.run-common.log_analytics_workspace_name
plan {
publisher = "Microsoft"
product = "OMSGallery/Updates"
}
}Ensuite, déclarez et configurez chaque horaire :
# Standard Production Windows Servers Update schedule
resource "azurerm_template_deployment" "update_config_standard_windows-prod" {
name = "update-config-standard-windows-prod"
resource_group_name = module.rg.resource_group_name
deployment_mode = "Incremental"
template_body = <<DEPLOY
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate...",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.Automation/automationAccounts/softwareUpdateConfigurations",
"apiVersion": "2017-05-15-preview",
"name": "${module.run-iaas.automation_account_name}/Prod Standard Windows Update Schedule",
"properties": {
"updateConfiguration": {
"operatingSystem": "Windows",
"windows": {
"includedUpdateClassifications": "Critical, Security, UpdateRollup, Updates",
"rebootSetting": "IfRequired"
},
"duration": "PT1H",
"targets": {
"azureQueries": [
{
"scope": ["${module.rg.resource_group_id}"]
}
]
}
},
"scheduleInfo": {
"startTime": "2021-01-01T03:00:00+01:00",
"expiryTime": "9999-12-31T23:59:00+01:00",
"isEnabled": "true",
"interval": 1,
"frequency": "Month",
"timeZone": "Romance Standard Time",
"advancedSchedule": {
"monthlyOccurrences": [
{
"occurrence": "4",
"day": "Wednesday"
}
]
}
}
}
}
]
}
DEPLOY
}Guidelines
Pour les mises à jour de sécurité urgentes, une solution de contournement consiste à créer une planification dédiée avec une date d'exécution unique et à déployer uniquement les mises à jour de sécurité. Lorsqu'une mise à jour de sécurité doit être déployée rapidement, la modification de l'heure et de la date d'exécution de la planification est la seule action requise. Comme toujours, le cas échéant, ciblez d'abord les VM de non-production pour vous assurer que les mises à jour ne perturbent pas l'application.
À ce stade, nous devons garder à l'esprit que même si Azure nous aide à planifier les mises à jour, il ne choisit pas quelle VM doit être patchée en premier. Plusieurs planifications doivent être déployées à des moments différents pour déployer les mises à jour sur des VMs de non-production afin de les tester avant qu'elles ne soient déployées sur la production ou pour mettre à jour les VMs hébergeant la même application à des moments différents pour maintenir la haute disponibilité. Chaque solution de mise à jour devrait inclure au moins 2 programmes, un pour la non-production - exécuté juste après le patch MS tuesday par exemple - et un pour la production une ou deux semaines plus tard pour détecter toute erreur ou mauvais comportement causé par un patch défectueux.
Le mode de fonctionnement de la gestion des mises à jour facilite également les déploiements de mises à jour bleues/vertes. Si une application est hébergée sur plusieurs machines virtuelles, les mises à jour peuvent être déployées sur certaines d'entre elles à l'aide d'une balise "bleue" tandis que les machines virtuelles dotées de la balise "verte" ne sont pas concernées et continuent de servir l'application. Une deuxième planification visant les VM "vertes" se produit après un certain temps afin de vérifier l'état des VM "bleues" avant de propager les mises à jour. De cette façon, une charge de travail répartie entre les VM reste disponible pendant la phase de mise à jour, comme c'est le cas dans tous les processus bleu/vert.
Reporting et logs
Après l'exécution, un rapport est disponible avec les détails. Les logs peuvent également être analysés dans l'espace de travail Log Analytics, à condition que les paramètres de diagnostic aient été configurés sur le compte d'automatisation.
Les journaux peuvent être utilisés pour exposer les résultats sur un tableau de bord Azure ou comme événement source pour arrêter la surveillance pendant que la VM est en train de se mettre à jour et très probablement de redémarrer pour éviter toute alerte d'astreinte pour l'équipe informatique. Voici l'un des exemples les plus simples de leur utilisation pour un tableau de bord Azure : l'affichage du ratio succès/échec. Exécutez cette requête et épinglez le résultat à un tableau de bord pour obtenir un aperçu rapide de l'état des mises à jour pour un projet, une région ou même dans une perspective globale.
La requête :
AzureDiagnostics
| where Category == 'JobLogs' and RunbookName_s == 'Patch-MicrosoftOMSComputer'
| summarize arg_max(TimeGenerated, *) by RunOn_s
| extend ['Result'] = case(ResultType == 'Started', 'Not finished', ResultType)
| summarize count() by ['Result']
Des alertes peuvent également être paramétrées pour envoyer un email avec le rapport des mises à jour échouées ou réussies : https://docs.microsoft.com/en-us/azure/automation/update-management/conf...
NB : Azure Update Management est également inclus dans la fonctionnalité Azure Automanage. Encore en version preview, elle permet d'activer un ensemble complet de services Azure sur une VM (Backup, Insights monitoring, Security Center, Antimalware, Update Management, Change Tracking & Inventory, Log Analytics) avec une configuration standardisée - et non modifiable.
Plus de détails ici : https://docs.microsoft.com/fr-fr/azure/automanage/automanage-virtual-mac...
Mises à jour automatiques Azure (pour Windows et Linux, en avant-première)
Cette fonctionnalité est encore en preview et offre une gestion des mises à jour entièrement gérée par Azure. Les principales caractéristiques sont :
- Applique uniquement les mises à jour de sécurité et critiques.
- Téléchargement et installation automatique des mises à jour tous les mois et redémarrage de la VM après application.
- Les mises à jour sont appliquées à tout moment, lorsqu'Azure détermine que la VM est dans une période " creuse ".
- Les VM situées dans différentes zones de disponibilité ou dans un ensemble de disponibilité ne sont pas mises à jour en même temps.
- Les machines virtuelles qui ne font pas partie d'un ensemble de disponibilités sont mises en lots au mieux afin d'éviter les mises à jour simultanées pour toutes les machines virtuelles d'un abonnement.
- Activé à la création de la VM (ou plus tard par CLI)
- Cet aperçu ne comprenait que Windows Server 2012 R2 et plus, maintenant RHEL 7.x et Ubuntu 18.04 sont également éligibles.
Plus de détails sur la documentation Microsoft : https://docs.microsoft.com/fr-fr/azure/virtual-machines/windows/automati...
Mises à jour automatiques Azure (pour Windows et Linux, en avant-première)
Cette fonctionnalité est encore en preview et offre une gestion des mises à jour entièrement gérée par Azure. Les principales caractéristiques sont :
- Applique uniquement les mises à jour de sécurité et critiques.
- Téléchargement et installation automatique des mises à jour tous les mois et redémarrage de la VM après application.
- Les mises à jour sont appliquées à tout moment, lorsqu'Azure détermine que la VM est dans une période " creuse ".
- Les VM situées dans différentes zones de disponibilité ou dans un ensemble de disponibilité ne sont pas mises à jour en même temps.
- Les machines virtuelles qui ne font pas partie d'un ensemble de disponibilités sont mises en lots au mieux afin d'éviter les mises à jour simultanées pour toutes les machines virtuelles d'un abonnement.
- Activé à la création de la VM (ou plus tard par CLI)
- Cet aperçu ne comprenait que Windows Server 2012 R2 et plus, maintenant RHEL 7.x et Ubuntu 18.04 sont également éligibles.
Plus de détails sur la documentation Microsoft : https://docs.microsoft.com/fr-fr/azure/virtual-machines/windows/automati...
Cela signifie que les correctifs critiques et de sécurité sont installés sans aucun contrôle administratif de l'entreprise. Azure "décide" quand les appliquer et redémarre la VM si nécessaire. Pour les autres classifications, il est recommandé d'utiliser Azure Patch Management ou une solution existante pour compléter la portée des mises à jour du système d'exploitation.
Cette nouvelle fonctionnalité semble idéale pour les machines virtuelles non productives qui n'ont pas de tâches planifiées spécifiques ou qui dépendent d'autres machines virtuelles, car elles peuvent devenir indisponibles sans préavis. Un candidat parfait serait une VM POC, où la sécurité doit être à jour mais où les mises à jour non critiques ne seraient pas manquées.
Le journal d'activité Azure sur une machine virtuelle dont la mise à jour automatique par plate-forme est activée montre les actions de correction :
Outro
Azure fournit ces services gratuitement. Azure Update Management devrait être considéré comme une solution potentielle pour remplacer progressivement les outils existants, afin de faciliter la gestion des correctifs, car il peut être configuré pour intégrer automatiquement de nouvelles machines virtuelles et utiliser les programmes existants pour les maintenir à jour. Les mises à jour automatiques par plateforme peuvent être une clé pour remettre la gestion des correctifs comme un rôle de "back office" pour les charges de travail non critiques. Les rapports de base ne sont pas aussi détaillés que ceux fournis par les serveurs de mise à jour comme WSUS, la sélection ou l'exclusion des mises à jour est assez lourde (par exemple, les KB de Microsoft doivent être déclarées une par une dans le calendrier), mais les avantages quotidiens pour l'équipe informatique valent la peine d'être essayés.
Pour lire l'article en anglais, rendez-vous sur Medium.