Automatisation et Infrastructure as Code¶

Concepts fondamentaux¶

Qu'est-ce que l'Infrastructure as Code ?¶

L'Infrastructure as Code (IaC) est la pratique de gerer et provisionner l'infrastructure informatique via des fichiers de configuration versionnes plutot que par des processus manuels. Chaque serveur, reseau et service est decrit dans du code source, versionne dans Git, revise par des pairs et deploye de maniere reproductible.

Imperatif vs declaratif¶

Approche	Principe	Exemple	Outil
Imperative	Decrit comment arriver au resultat, etape par etape	"Installe nginx, copie le fichier de config, demarre le service"	Scripts shell, Ansible (partiellement)
Declarative	Decrit l'etat desire final, l'outil determine les actions	"Il doit y avoir une VM avec 4 vCPU et 8 Go de RAM"	Terraform, Kubernetes manifests

Mutable vs immutable¶

Approche	Principe	Avantage	Inconvenient
Mutable	L'infrastructure existante est modifiee sur place	Rapide pour les petits changements	Derive de configuration, "snowflake servers"
Immutable	Toute modification detruit et recree la ressource	Reproductibilite parfaite	Plus lent, necessite une strategie de donnees

Idempotence¶

Un processus est idempotent s'il produit le meme resultat, qu'il soit execute une ou plusieurs fois. C'est une propriete essentielle en IaC : relancer un playbook Ansible ou un terraform apply sur une infrastructure deja conforme ne doit rien changer.

Gestion d'etat¶

Les outils IaC declaratifs maintiennent un fichier d'etat (state) qui represente l'infrastructure reelle. Cet etat permet de calculer les differences entre l'etat desire (code) et l'etat actuel, puis d'appliquer uniquement les changements necessaires.

Strategie "Everything as Code"¶

L'objectif est d'atteindre 95% d'automatisation des operations recurrentes :

flowchart TB
    subgraph IaC["Infrastructure as Code"]
        TF["Terraform<br/>Provisioning VMs"]
        PK["Packer<br/>Golden images"]
    end

    subgraph CaC["Configuration as Code"]
        AN["Ansible<br/>Configuration systeme"]
        DK["Docker Compose<br/>Stacks applicatives"]
    end

    subgraph PaC["Pipeline as Code"]
        GL["GitLab CI<br/>Pipelines CI/CD"]
    end

    subgraph SaC["Security as Code"]
        VL["Vault<br/>Secrets et certificats"]
        WZ["Wazuh<br/>Regles de detection"]
    end

    PK -->|Image de base| TF
    TF -->|VMs provisionees| AN
    AN -->|Systemes configures| DK
    GL -->|Deploie| DK
    VL -->|Secrets| AN
    VL -->|Certificats| GL
    WZ -->|Monitoring| AN

    style IaC fill:#1565C0,color:#fff
    style CaC fill:#E65100,color:#fff
    style PaC fill:#2E7D32,color:#fff
    style SaC fill:#B71C1C,color:#fff

Terraform¶

Principes¶

Terraform (HashiCorp) est un outil IaC declaratif qui permet de provisionner et gerer l'infrastructure sur differentes plateformes (cloud, on-premise, SaaS) via le langage HCL (HashiCorp Configuration Language).

Concepts cles¶

Concept	Description
Provider	Plugin qui communique avec l'API d'une plateforme (vsphere, vault, dns)
Resource	Element d'infrastructure a gerer (VM, disque, reseau)
Module	Bloc reutilisable de ressources (notre module vm-rocky9)
State	Fichier (terraform.tfstate) qui mappe le code a l'infrastructure reelle
Plan	Preview des changements avant application
Apply	Application effective des changements

Workflow Terraform¶

flowchart LR
    CODE["Code HCL<br/>(etat desire)"] --> PLAN["terraform plan<br/>(calcul du diff)"]
    PLAN --> REVIEW["Revue humaine<br/>(verification)"]
    REVIEW --> APPLY["terraform apply<br/>(execution)"]
    APPLY --> STATE["State file<br/>(etat reel)"]
    STATE -->|Drift detection| CODE

    style PLAN fill:#FF9800,color:#fff
    style APPLY fill:#2E7D32,color:#fff

Terraform pour vSphere¶

Notre module vm-rocky9 lit des fichiers YAML qui servent de source unique de verite (SSOT) pour la definition des VMs :

Module vm-rocky9¶

Le module abstrait la complexite de creation d'une VM vSphere en un appel simple :

Parametre YAML	Description	Exemple
name	Nom de la VM	soc-master-01
cpu	Nombre de vCPU	4
memory	RAM en Mo	8192
disk_size	Disque en Go	100
ip	Adresse IP	10.15.80.11
gateway	Passerelle	10.15.80.1
vlan	VLAN de rattachement	800
dns	Serveurs DNS	10.15.100.74

Structure par zones¶

Les fichiers Terraform sont organises par zone reseau, chacune correspondant a un ou plusieurs VLANs :

Zone	VLANs	Fichier YAML	Nombre de VMs
infra	100, 106	infra.yaml	Services fondamentaux
soc	800	soc.yaml	Cluster SOC complet
dmz	200	dmz.yaml	Services exposes
monitoring	108	monitoring.yaml	Zabbix, Grafana, Prometheus
services	110, 112	services.yaml	Applications metier
dev	114	dev.yaml	Environnement de developpement

Le fichier environments/prod/main.tf orchestre le deploiement de toutes les zones.

Ansible¶

Principes¶

Ansible (Red Hat) est un outil d'automatisation agentless qui configure les systemes via SSH. Il utilise des playbooks YAML declaratifs et des roles modulaires.

Concepts cles¶

Concept	Description
Inventaire	Liste des hotes cibles, organises en groupes
Playbook	Fichier YAML orchestrant l'execution de roles et taches
Role	Unite reutilisable de configuration (tasks, handlers, templates, defaults)
Task	Action unitaire (installer un paquet, copier un fichier, demarrer un service)
Handler	Action declenchee par un changement (restart service apres modif config)
Facts	Variables collectees automatiquement sur chaque hote (OS, IP, RAM)
Templates Jinja2	Fichiers de configuration parametres dynamiquement

37 roles Ansible¶

Les roles sont organises par fonction :

Roles fondamentaux (deployes sur toutes les VMs)¶

Role	Description
common	Configuration de base (hostname, NTP, DNS, proxy, repos Nexus)
hardening-anssi	Durcissement ANSSI-BP028 complet
lvm-setup	Configuration LVM et partitionnement securise
wazuh-agent	Installation et configuration de l'agent Wazuh
zabbix-agent	Installation et configuration de l'agent Zabbix
freeipa-client	Enrolement au domaine FreeIPA

Roles identite et acces¶

Role	Description
freeipa-server	Serveur FreeIPA (annuaire LDAP + Kerberos)
vault	HashiCorp Vault (PKI, secrets, SSH CA)

Roles monitoring¶

Role	Description
zabbix-server	Serveur Zabbix (supervision infrastructure)
grafana	Dashboards de visualisation
prometheus	Collecte de metriques
node-exporter	Export des metriques systeme

Roles SOC -- collecte et detection¶

Role	Description
rsyslog-server	Collecte centralisee des logs
haproxy	Load balancer pour la HA
keepalived	VIP et basculement VRRP
logstash	Parsing et enrichissement des logs
elasticsearch	Cluster de stockage et indexation
kibana	Interface de visualisation
wazuh-manager	Manager Wazuh (regles, decoders, alertes)
elastalert2	Moteur d'alertes sur Elasticsearch

Roles SOC -- orchestration et outils¶

Role	Description
shuffle	Plateforme SOAR
thehive	Gestion d'incidents
cortex	Moteur d'analyse et enrichissement
misp	Partage d'IoC
opencti	Plateforme CTI
opencanary	Honeypots de deception
ollama	LLM local pour assistance analyse
n8n	Automatisation de workflows
ntfy	Notifications push

Roles infrastructure¶

Role	Description
squid	Proxy web HA
bind	DNS interne
chrony	Serveur NTP
nexus	Gestionnaire de repositories
gitlab	Forge logicielle
docker	Runtime Docker CE
sonarqube	Analyse de code statique
gitlab-runner	Runners CI/CD

Deploiement en 6 phases (site.yml)¶

Le playbook maitre site.yml orchestre le deploiement complet en 6 phases sequentielles :

flowchart TB
    P1["Phase 1 -- Fondations<br/>common, lvm-setup, docker"]
    P2["Phase 2 -- Durcissement<br/>hardening-anssi"]
    P3["Phase 3 -- Identite et acces<br/>freeipa-server/client, vault"]
    P4["Phase 4 -- Infrastructure<br/>squid, bind, chrony, nexus, gitlab"]
    P5["Phase 5 -- Monitoring + SOC<br/>zabbix, prometheus, grafana<br/>elasticsearch, wazuh, kibana"]
    P6["Phase 6 -- Orchestration<br/>shuffle, thehive, cortex, misp<br/>opencti, opencanary, ollama"]

    P1 --> P2 --> P3 --> P4 --> P5 --> P6

    style P1 fill:#1565C0,color:#fff
    style P2 fill:#B71C1C,color:#fff
    style P3 fill:#E65100,color:#fff
    style P4 fill:#2E7D32,color:#fff
    style P5 fill:#7B1FA2,color:#fff
    style P6 fill:#F57F17,color:#000

Packer¶

Concept de Golden Image¶

Packer (HashiCorp) cree des images de base (golden images) qui servent de point de depart pour toutes les VMs. L'image contient le systeme minimal, pre-configure et durci, ce qui reduit le temps de deploiement et garantit l'homogeneite.

Etape	Description
Kickstart	Installation automatisee de Rocky 9 avec partitionnement, paquets de base, compte initial
Provisioning	Configuration minimale (cloud-init ready, VMware tools, agent SSH)
Template	Conversion en template vSphere reutilisable

Information	Valeur
Derniere image	rocky9-template-2026-03-23
OS	Rocky Linux 9.x minimal
Format	Template VMware vSphere
Contenu	Partitionnement LVM, VMware tools, cloud-init, SSH keys, repos Nexus

Workflow complet de deploiement¶

flowchart LR
    subgraph PACKER["Packer"]
        P["Golden image<br/>rocky9-template"]
    end

    subgraph TERRAFORM["Terraform"]
        T["Provisioning<br/>VMs vSphere"]
    end

    subgraph ANSIBLE["Ansible"]
        A["Configuration<br/>37 roles, 6 phases"]
    end

    subgraph DOCKER["Docker"]
        D["Stacks applicatives<br/>9 compose files"]
    end

    P -->|Template de base| T
    T -->|VMs provisionees| A
    A -->|Systemes configures| D

    style PACKER fill:#1565C0,color:#fff
    style TERRAFORM fill:#7B1FA2,color:#fff
    style ANSIBLE fill:#E65100,color:#fff
    style DOCKER fill:#2E7D32,color:#fff

Structure du depot¶

Repertoire	Contenu	Volume
infra/terraform/	Modules, zones, environments	43 fichiers, 6 zones
infra/ansible/	Inventaire, playbooks, roles	37 roles, 3 playbooks
infra/docker/	Stacks Docker Compose	9 stacks
infra/packer/	Templates Packer et kickstart	2 templates