Vagrant : Ansible vs Ansible_Local et le mythe du Control Node Windows

by Nicolas DELAHAYE | Jan 1, 2026 | DevSecOps

> diff vagrant_provisioners.txt --side-by-side_

Vagrant : Le duel Ansible vs Ansible_Local (et la vérité sur Windows)

Par Nicolas DELAHAYE | v.1974 | Architecte & Automation

STATUS: ARCHITECTURE_DECISION_REQUIRED

Dans un Vagrantfile, la différence tient à six lettres et un underscore : _local. Pourtant, choisir entre config.vm.provision "ansible" et config.vm.provision "ansible_local" n'est pas une question de goût. C'est une décision d'architecture qui définit qui peut (ou ne peut pas) exécuter votre code.

1. Le mode Classique : config.vm.provision "ansible"

C'est l'approche puriste. Ici, l'Hôte est le Maître, la VM est l'Esclave.

Le Flux :
[ VOTRE MAC/LINUX ] --(SSH)--> [ VM CIBLE ]

Vagrant va chercher l'exécutable ansible-playbook installé sur votre machine physique et lui demande de se connecter à la VM pour la configurer.

✅ Les avantages : C'est propre. Vous utilisez votre Ansible centralisé, vos secrets (Vault), vos clés SSH et vous ne polluez pas la VM avec l'installation d'Ansible.
❌ Le problème : Cela exige qu'Ansible soit installé sur la machine hôte. Et si votre collègue est sous Windows... vous êtes dans une impasse.

2. Le mode Pragmatique : config.vm.provision "ansible_local"

C'est l'approche "Contained". Ici, la VM est à la fois Maître et Esclave.

Le Flux :
1. Vagrant démarre la VM.
2. Vagrant installe Ansible DANS la VM (Guest).
3. Vagrant monte vos playbooks dans /vagrant.
4. La VM exécute Ansible sur elle-même (localhost).

✅ Les avantages : Zéro dépendance. Que vous soyez sur Mac, Linux ou Windows, ça marche. Le lab est 100% autonome et reproductible.
❌ Le problème : Le premier démarrage est plus lent (il faut installer Ansible) et c'est conceptuellement étrange pour un puriste de voir un serveur se configurer lui-même.

3. Le Mur de la Réalité : Pourquoi Ansible ne tourne pas sur Windows

J'entends souvent : "Mais pourquoi on n'installe pas juste Ansible sur Windows pour utiliser le mode classique ?".

La réponse est brutale : C'est impossible. Ce n'est pas un bug, c'est une conception.

Pourquoi ? (Le point technique)

Ansible est écrit en Python, mais son cœur repose sur des primitives système POSIX : le fork() de processus, la gestion des descripteurs de fichiers, les pseudo-terminaux (pty) et un modèle de permissions SSH spécifique.

L'API Win32 de Windows fonctionne différemment. Elle ne possède pas ces concepts nativement. Résultat : Ansible ne peut pas fonctionner en tant que Control Node (le cerveau) sur Windows. Il peut seulement gérer des cibles Windows.

Ce que dit la documentation officielle

"Running Ansible from a Windows control machine is not a goal of the project."
"Ansible cannot run on Windows as the control node due to API limitations on the platform."
-- Docs officielles Ansible & FAQ

// Note : Oui, WSL (Windows Subsystem for Linux) existe. Mais cela ajoute une couche de complexité réseau avec Vagrant et n'est pas "supporté officiellement" pour la production par Red Hat.

4. Le Verdict de l'Architecte

Dans mon contexte de préparation aux certifications CKA/CKS, je dois pouvoir casser et reconstruire mon environnement en 5 minutes, que je sois sur mon MacBook Pro M3 ou que je partage le code avec un collègue sous Windows.

Mon choix est donc sans appel : ansible_local.

Scénario	Recommandation
Équipe 100% Linux/Mac	`ansible` (plus rapide)
Équipe mixte (Win/Lin/Mac)	`ansible_local` (obligatoire)
Lab pédagogique / Formation	`ansible_local` (zéro pré-requis)
CI/CD Pipeline	`ansible` (l'agent CI est sous Linux)

// SYNTHÈSE :

Utiliser ansible_local n'est pas un "hack" ou une "verrue". C'est un pattern de portabilité. En DevSecOps, la reproductibilité de l'environnement prime sur la pureté de l'implémentation. Mieux vaut un script qui tourne partout qu'un script "parfait" qui ne tourne que sur ma machine.

CVE, CVSS, EPSS : Le Guide Ultime pour Prioriser vos Vulnérabilités

by Nicolas DELAHAYE | Jan 1, 2026 | Systeme, DevSecOps

> ./explain_vuln_metrics.sh --verbose --deep-dive_

CVE, CVSS et EPSS : Comprendre, Trier et Prioriser

Par Nicolas DELAHAYE | v.1974 | DevSecOps & Architecture

STATUS: CRITICAL_KNOWLEDGE_LOADED

Le monde de la cybersécurité ne manque pas d'acronymes. Mais s'il y a bien une trinité que tout ingénieur, développeur ou architecte doit maîtriser pour ne pas sombrer sous le poids de la dette technique, c'est celle-ci : CVE, CVSS et EPSS.

Au quotidien, nos scanners CI/CD crachent des rapports rouges sang. Sans une compréhension fine de ces métriques, vous allez patcher des fantômes pendant que votre infra brûle par une porte dérobée que vous aviez classée "Medium". Voici le décodage complet.

1. CVE : L'Identité de la Menace

Définition : CVE signifie Common Vulnerabilities and Exposures.

Imaginez le CVE comme le numéro de sécurité sociale d'un bug de sécurité. C'est un identifiant unique, international, géré par le programme CVE (MITRE) et ses partenaires (CNA - CVE Numbering Authorities).

Structure d'un CVE :
CVE-2024-12345

CVE : Le préfixe standard.
2024 : L'année d'attribution de l'ID (pas forcément l'année de découverte).
12345 : Un numéro séquentiel unique.

À quoi ça sert ? À parler le même langage. Quand je dis "Log4Shell", c'est flou. Quand je dis CVE-2021-44228, tous les outils de la planète (firewalls, scanners, bases de données) savent exactement de quelle ligne de code on parle.

2. CVSS : La Gravité Théorique

Avoir un nom (CVE), c'est bien. Savoir si c'est dangereux, c'est mieux. C'est le rôle du Common Vulnerability Scoring System.

Attention : Le CVSS mesure la sévérité technique, pas le risque pour VOTRE entreprise. Il répond à la question : "Si cette faille est exploitée, quels sont les dégâts potentiels ?"

Le thermomètre (Score v3.1 / v4.0) :

[0.0 - 3.9] FAIBLE : Impact minime.
[4.0 - 6.9] MOYEN : Nécessite souvent une action locale ou des privilèges.
[7.0 - 8.9] ÉLEVÉ : Impact sérieux, souvent exploitable à distance.
[9.0 - 10.0] CRITIQUE : "Game Over". Prise de contrôle totale, souvent sans authentification.

Un score CVSS n'est pas un chiffre magique, c'est une formule complexe basée sur un Vecteur. Exemple pour Log4Shell :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Décryptage : AV:N (Réseau/Network) + AC:L (Complexité Faible) + PR:N (Aucun privilège requis) + C/I/A:H (Confidentialité/Intégrité/Dispo : Impact Haut). C'est le pire scénario possible.

3. EPSS : La Boule de Cristal (Probabilité)

C'est ici que la modernité entre en jeu. Vous avez 100 vulnérabilités "Critiques" (CVSS 9.8). Par laquelle commencer ?

Le CVSS a une limite : il ne vous dit pas si des pirates exploitent réellement la faille. Peut-être que la faille est théoriquement catastrophique, mais techniquement impossible à exploiter sans un alignement des planètes improbable.

L'EPSS (Exploit Prediction Scoring System), géré par FIRST.org, répond à la question : "Quelle est la probabilité que cette faille soit exploitée dans les 30 prochains jours ?"

La logique de triage moderne :
Une CVE avec un CVSS de 9.8 mais un EPSS de 0.01% (peu probable) est MOINS prioritaire qu'une CVE avec un CVSS de 7.5 mais un EPSS de 95% (attaque en cours massive).

4. Comparatif : CVE vs CVSS vs EPSS

Acronyme	La question posée	Type de donnée
CVE	"C'est quoi le problème ?"	Identifiant unique (Catalogue)
CVSS	"À quel point ça fait mal ?"	Score de gravité (0-10)
EPSS	"Vais-je me faire attaquer ?"	Probabilité (0-100%)

5. L'Arsenal du DevSecOps : Les Scanners

Pour extraire ces données de vos images Docker ou de vos serveurs, vous avez besoin d'outils. Voici le Top 3 Open Source.

A. Aqua Trivy (Le Couteau Suisse)

C'est mon favori. Rapide, complet, sans base de données à gérer.

$ trivy image python:3.9-alpine
# Scan aussi le filesystem, les repos git et Kubernetes
$ trivy fs --scanners vuln,secret,config .

B. Grype & Syft (Le Duo Précis)

Développé par Anchore. Syft génère le SBOM (Software Bill of Materials) et Grype le scanne.

$ syft packages docker:nginx:latest -o json > sbom.json
$ grype sbom:./sbom.json

C. Clair (Le Pionnier)

Plus lourd, nécessite une base de données Postgres, mais très utilisé dans les registres d'entreprise comme Quay.io.

6. Scénario Concret : Faut-il fixer ?

Vous scannez votre image de production. Trivy remonte la CVE-2023-XXXX.

Analyse :

CVSS : 9.1 (Critique) -> Panique à bord ?
Vecteur : AV:N (Réseau) mais AC:H (Complexité Haute).
EPSS : 0.02% (Très faible).
Contexte : La librairie vulnérable est présente dans l'image, mais elle n'est utilisée que pour compiler des assets statiques et n'est pas chargée au runtime.

Décision DevSecOps :

Malgré le CVSS rouge vif, le risque réel est quasi nul. On peut accepter le risque temporairement ou supprimer la librairie de l'image finale (multi-stage build), plutôt que de bloquer la mise en production pour un patch urgent.
C'est ça, la puissance de l'analyse contextuelle combinée à l'EPSS.

// RESSOURCES OFFICIELLES :

Catalogue CVE : cve.org
Calculateur CVSS : nvd.nist.gov
Données EPSS : first.org
Trivy : trivy.dev

[ EOF - Security Scan Complete ]

Hébergement Helm Charts : Harbor, ArgoCD ou ChartMuseum pour votre Lab ?

by Nicolas DELAHAYE | Déc 31, 2025 | Kubernetes, Outils

> helm repo add chartmuseum http://localhost:8080_

Helm Charts : Pourquoi j'ai choisi ChartMuseum pour mon Lab local

Par Nicolas DELAHAYE | v.1974 | Architecte Solution STRATÉGIE: Simplicité vs Robustesse de production

1. Le dilemme de l'architecte

Je construis actuellement un environnement de développement pour une solution déployée sur Kubernetes. Pour l'infra, j'utilise Helm Charts (simple, efficace, facile à injecter via Ansible ou Terraform). Mon problème ? Je voulais un dépôt de Charts qui ne soit pas juste un dossier local (trop éloigné de la prod), mais sans pour autant lancer une "Death Star" comme ArgoCD ou Harbor sur mon MacBook. Je veux déclencher la mise à jour seulement quand mon Chart est "OK", et non à chaque micro-modification locale.

2. Analyse des forces en présence

Option	Avantages	Inconvénients
Harbor	Ultra complet, sécu (Trivy), signatures.	Très lourd à déployer en local.
ArgoCD	Le roi du GitOps en production.	Surdimensionné pour un simple test de Chart.
Web Serveur	Simplicité absolue (Nginx/Apache).	Pas d'API, pas de gestion de versions.
ChartMuseum	Léger, API de dépôt, stockage cloud.	Moins de fonctions de sécurité avancées.

3. Le choix du "Juste Milieu" : ChartMuseum

J'ai choisi ChartMuseum car c'est un projet officiel de l'univers Kubernetes (CNCF). C'est écrit en Go, c'est ultra-léger et cela fournit exactement ce dont j'ai besoin : un vrai dépôt de Helm Charts accessible via une API. Cela me permet de tester le cycle de vie réel de mes déploiements sans l'overhead d'un registre d'artefacts d'entreprise.

4. Tuto Rapide : Exploiter ChartMuseum

Une fois votre instance lancée (via Docker ou en binaire), voici le workflow minimaliste : Étape 1 : Packager votre Chart

$ helm package ./mon-beau-chart

// Cela génère un fichier .tgz prêt pour le dépôt.

Étape 2 : Envoyer au Chartmuseum

$ curl --data-binary "@mon-beau-chart-0.1.0.tgz" http://localhost:8080/api/charts

Étape 3 : Déployer votre chart

$ helm install mon-beau-chart chartmuseum/mon-beau-chart

// RÉFLEXION DE NICO : En tant qu'architecte, on est souvent tenté par les solutions "Rolls-Royce" (Harbor, ArgoCD). Mais le vrai Craftsmanship, c'est de savoir choisir l'outil proportionné au besoin. ChartMuseum me permet de simuler un flux de production tout en restant sur un environnement local fluide. C'est propre, c'est net, c'est efficace.

Cygwin vs MSYS2 : Quel environnement choisir pour Windows ?

by Nicolas DELAHAYE | Déc 30, 2025 | Outils, Systeme, virtualisation

> diff cygwin msys2 --brief_

Cygwin ou MSYS2 ? Mon arbitrage pour un Lab Kubernetes sous Windows

Par Nicolas DELAHAYE | v.1974 | Architecte Solution

CONTEXTE: Environnement Cross-Platform (Win/Linux)

1. Le Contexte : Réconcilier deux mondes

Dans mon équipe, nous avons deux clans : les puristes Linux et les utilisateurs Windows. Pour mon projet de lab Kubernetes (3 nodes, cassables et reconstructibles en moins de 5 minutes), l'environnement doit tourner de manière identique partout.

Le choix de la virtualisation s'est imposé, et comme vous le savez, j'ai opté pour QEMU (voir mon article précédent). C'est en cherchant le portage de QEMU sur Windows que je suis tombé sur MSYS2. Alors que j'avais déjà Cygwin et WSL2, j'ai voulu creuser. Voici pourquoi j'ai fini par changer mon fusil d'épaule.

2. Cygwin : Le vétéran POSIX

Cygwin est un monument. Son but : recréer un environnement Unix complet sous Windows via une couche de compatibilité (cygwin1.dll).

Forces : Collection immense d'outils, très proche d'un vrai Linux.
Faiblesses : Une couche d'émulation lourde qui impacte les performances. Les binaires produits sont "prisonniers" de la DLL Cygwin.

3. MSYS2 : La modernité et la performance

MSYS2 est arrivé avec une philosophie différente : fournir un shell Unix léger mais orienté vers le développement natif Windows.

Le Graal : Il utilise pacman (le gestionnaire de paquets d'Arch Linux). C'est rapide, moderne et propre.
Intégration : Parfait pour piloter Vagrant, Ansible et QEMU sans les frictions de compatibilité de Cygwin.

4. Le Comparatif Synthétique

Critère	Cygwin	MSYS2
Performance	Moyenne (Émulation)	Excellente (Natif)
Gestion Paquets	Setup.exe manuel	Pacman (CLI)
Binaires produits	Dépendants DLL	100% Windows natifs
Usage CI/CD	Peu adapté	Idéal

5. Pourquoi MSYS2 gagne le match

Pour mon lab piloté par Vagrant et Ansible, MSYS2 l'emporte car :

Il ne nécessite pas de contraintes GPL lourdes sur les binaires.
Il s'aligne avec les outils modernes (CMake, Ninja, Git).
L'installation de QEMU y est d'une fluidité exemplaire.

// LE MOT DE L'ARCHITECTE :

Cygwin reste pertinent pour des scripts historiques ou des besoins POSIX très stricts. Mais aujourd'hui, pour monter des toolchains modernes et des pipelines DevSecOps robustes sur Windows, MSYS2 est le choix par défaut. C'est l'outil qui m'a permis de faire tenir mon lab Kubernetes dans ma poche (ou presque).

Mémento QEMU : Dompter vos VMs en ligne de commande (Guide)

by Nicolas DELAHAYE | Déc 28, 2025 | virtualisation

> man qemu-maintenance.sh_

Mémento : La maintenance QEMU en ligne de commande

Par Nicolas DELAHAYE | v.1974 | Architecture & Automation

OBJECTIF: Zéro interface graphique. 100% efficacité.

Installer QEMU sur son Mac via Brew, c'est une chose. Le piloter au quotidien sans s'emmêler les pinceaux, c'en est une autre. Voici mon "disque dur externe" de commandes pour gérer mes nodes Kubernetes sans passer par une GUI lourde.

1. Lister les VMs actives

Si vous utilisez QEMU seul ou via un wrapper, le plus simple pour voir ce qui tourne est de vérifier les processus systèmes (le bon vieux grep) :

$ ps aux | grep qemu-system

// Note : Si vous utilisez libvirt (souvent avec Vagrant) sur Linux, la commande est plus élégante : `virsh list --all`

2. Créer un disque virtuel (Storage)

Avant de lancer une VM, il faut un disque. Le format qcow2 est le standard : il est "thin provisioned" (il ne prend que la place réelle des données).

$ qemu-img create -f qcow2 mon-node-kube.qcow2 20G

3. Modifier la configuration (Tuning)

Pas besoin de menu "Settings". Tout se passe dans les flags au lancement. Pour ajouter de la RAM ou des CPU à la volée :

$ qemu-system-x86_64 -m 4G -smp 2 -hda mon-node-kube.qcow2

-m 4G : Alloue 4 Go de RAM.
-smp 2 : Alloue 2 cœurs CPU.

4. Sauvegarder (Snapshots)

L'avantage du format qcow2, c'est qu'il gère les snapshots en interne. Très utile avant de faire une mise à jour risquée sur un cluster Kubernetes.

Créer un point de restauration :

$ qemu-img snapshot -c backup_stable mon-node-kube.qcow2

Revenir en arrière :

$ qemu-img snapshot -a backup_stable mon-node-kube.qcow2

5. Supprimer proprement

Ici, pas de corbeille. On supprime l'image disque et, si elle était enregistrée dans libvirt, on l'efface de la base.

$ rm mon-node-kube.qcow2
$ # Ou via virsh :
$ virsh undefine mon-node-kube

// RÉFLEXION DE SENIOR :

Maîtriser ces commandes, c'est s'assurer que votre infrastructure est reproductible. Une fois que vous connaissez ces flags, vous pouvez les mettre dans un script Bash ou un playbook Ansible. C'est ça, le vrai DevSecOps : transformer la maintenance manuelle pénible en un processus automatisé et robuste.

[ LOGOUT - Session Ended ]