Comment automatiser le patch management et notamment la gestion des redémarrages et des vérifications de serveurs ? Dans un article précédent, nous avons vu le cas d’une infrastructure AWS avec EC2 System Manager. Dans cet article, nous allons détailler l’utilisation d’EC2 Systems Manager, l’utilisation de Jenkins, et la modification des “documents” Amazon avec l’implémentation des scripts.

EC2 Systems Managers

EC2 Systems Manager est utilisé pour gérer :

• Les mises à jours (patch management OS sécurité critique)
• L’inventaire des logiciels installés
• Le reporting des mises à jours et des logiciels installés
• Le reporting des erreurs (mises à jours en échec erreur d’exécution des scripts)

Toutes les actions sont réalisées automatiquement via l’ordonnanceur Jenkins, qui lance les scripts via l’outil Run_Command du Systems Manager Services. Ces scripts sont ensuite exécutés sur les instances EC2 Windows.

Orchestration – Jenkins

Jenkins joue le rôle d’ordonnanceur pour une intégration continue des mises à jours et des reportings de celles-ci. Voici quelques exemples des paramètres à renseigner dans la partie Jenkins

Le tag afin de récupérer les IDs des instances.

Les différents documents qui vont être exécutés

Un trigger pour l’exécution planifiée du Patch Management

Dans un premier temps, Jenkins va récupérer les IDs des instances en fonction du tag renseigné dans les paramètres, puis il va récupérer l’état de chacune des instances.

Ensuite avant toute exécution de documents, un snapshot est créé afin d’avoir un rollback possible. Une fois le snapshot terminé l’exécution des différents documents décrits ci-dessus sera effectuée. A la fin de chaque exécution de document, un fichiers est écrit sur S3. Avant d’exécuter le document suivant, Jenkins attend qu’un fichier soit bien présent sur S3 afin de s’assurer que la tâche précédente soit bien finalisée.

Dans la V1, à la fin du traitement les instances préalablement démarrées vont être redémarrées, les instances préalablement arrêtées vont être arrêtées.

Dans la V2, à la fin du Patch Management Jenkins va envoyer une demande au responsable applicatif via un outil ITSM (Service Now) afin de lui demander une plage pour redémarrer son instance. Une fois la demande approuvée, Service Now va organiser les tâches nécessaires, comme d’envoyer une demande à Jenkins afin de redémarrer l’instance ou une infra interdépendante. Des scripts de vérifications spécifiques par application et/ou instances vont être définis afin de vérifier l’état de l’instance. Par exemple la vérification du bon démarrage de services windows spécifiques. La partie Jenkins sera plus développée dans un article spécifique à Jenkins.

Documents

Nous les avons donc modifiés, voici ci-dessous les différents documents qui sont exécutés sur la partie Windows.

• UpdateSSMAgent : Met à jour l’agent SSM afin que la dernière version de l’agent soit installée, pour effectuer toutes les actions suivantes sur les instances. Ecrit un fichier sur S3 pour que Jenkins poursuive l’orchestration.
• UpdateWindows before update : Effectue un inventaire des mises à jour actuellement présentes sur le serveur, crée et envoie un fichier CSV sur S3 avec les information suivantes : ownername, Domain, tag application, Name Update, KB. Une gestion d’erreur est intégrée au script afin d’anticiper une erreur d’exécution du script. Écrit également un fichier sur S3 pour que Jenkins poursuive l’orchestration.
• UpdateWindows norestart : Installe les mises à jours Windows de sécurité critique sur les serveurs, sans redémarrer l’instance, Afin d’installer les mises à jour, les instances téléchargent des scripts fournis par AWS. Ces scripts sont modifiés afin de gérer les redémarrages des instances, et sont stockés dans un bucket S3. Il écrit également un fichier sur S3 pour que Jenkins poursuive l’orchestration.
• UpdateWindows after Update : Effectue un inventaire des mises à jour présentes sur l’instance, crée et envoie un fichier CSV sur S3 avec les informations suivantes : ownername, Domain, tag application, Name Update, KB. Une gestion d’erreur est intégrée au script afin d’anticiper une erreur d’exécution du script. Écrit également un fichier sur S3 pour que Jenkins poursuive l’orchestration.
• Compare Update : Effectue un comparatif des deux derniers fichiers de mises à jour afin de définir les derniers patchs installés sur chaque instance, crée et envoie un fichier CSV sur S3 avec les informations suivantes : ownername, Domain, tag application, Name Update, KB, date. Une gestion d’erreur est intégrée au script afin d’anticiper une erreur d’exécution du script. Écrit également un fichier sur S3 pour que Jenkins poursuive l’orchestration.
• Failed update check : Effectue un check des mises à jours en erreur sur l’instance, crée et envoie un fichier CSV sur S3 avec les informations suivantes : ownername, Domain, tag application, Name Update, KB, date. Une gestion d’erreur est intégrés au script afin d’anticiper une erreur d’exécution du script. Écrit également un fichier sur S3 pour que Jenkins poursuive l’orchestration.

Ces différents documents sont déployés via Terraform pour les intégrer sur les platformes AWS. Voici, ci-dessous un exemple de documents Json qui va être exécuté par Amazon.

Exemple documents JSON pour l’execution de script powershell

{    "schemaVersion":"1.2",
    "description":"Run a PowerShell script or specify the paths to scripts to run.",
    "parameters":{
        "commands":{
            "type":"StringList",
            "description":"(Required) Specify the commands to run or the paths to existing scripts on the instance.",
            "minItems":1,
            "displayType":"textarea"
        },
        "workingDirectory":{
            "type":"String",
            "default":"",
            "description":"(Optional) The path to the working directory on your instance.",
            "maxChars":4096
        },
        "executionTimeout":{
            "type":"String",
            "default":"3600",
            "description":"(Optional) The time in seconds for a command to be completed before it is considered to have failed. Default is 3600 (1 hour). Maximum is 172800 (48 hours).",
            "allowedPattern":"([1-9][0-9]{0,4})|(1[0-6][0-9]{4})|(17[0-1][0-9]{3})|(172[0-7][0-9]{2})|(172800)"
        }
    },
    "runtimeConfig":{
        "aws:runPowerShellScript":{
            "properties":[
                {
                    "id":"0.aws:runPowerShellScript",
                    "runCommand":"{{ commands }}",
                    "workingDirectory":"{{ workingDirectory }}",
                    "timeoutSeconds":"{{ executionTimeout }}"                }            ]        }    }}

Afin d’implémenter les scripts powershell dans cet exemple il suffit d’écrire le script powershell (converti en json) à la place de la commande (commands). Et de supprimer la partie parameters, afin de ne pas rendre obligatoire l’écriture du script powershell dans l’exécution de la Run Command. Nous pouvons également préciser un timeout et un répertoire ou les scripts vont être exécutés

Pour plus d’information sur le principe des documents, voir la documentation fournie par Amazon. Un reporting du patch management est également créé, qui sera détaillé dans un prochain article, Patch Management – Reporting.