Documentation Infrastructure Indio¶

Présentation¶

Indio est une infrastructure complète gérée en Infrastructure as Code : provisioning Terraform (providers VMware vSphere/NSX, NetBox, AWS, Elastic) et configuration Ansible, sur un socle VMware (vCenter + vSAN, 2 hôtes ESXi + witness) avec micro-segmentation réseau NSX-T. Toutes les VM sont clonées depuis un template durci unique et suivent une convention de nommage commune par segment réseau.

Cette documentation couvre l'ensemble des briques du projet : plateforme de virtualisation et stockage, réseau, identité/sécurité, données, supervision, pipeline de logs SOC/SIEM, Kubernetes, services métiers et intégration cloud AWS — plateforme, procédures manuelles reconstituées, explication du code Terraform/Ansible, schémas, pièges rencontrés et dette technique résiduelle.

Source de vérité vivante

Cette documentation décrit l'architecture telle qu'elle ressort du code IaC (Terraform/Ansible) versionné sur GitLab, complétée par l'historique opérationnel du projet et par des vérifications en direct (lecture seule) contre l'infrastructure réelle. Pour l'état live de l'inventaire (VM existantes, IP attribuées), NetBox reste la référence — l'infrastructure évolue par itérations rapides et certaines VM documentées ici peuvent avoir été redéployées ou décommissionnées depuis. Voir Historique des décommissionnements.

Avant toute reprise d'exploitation, lire le registre de dette technique

État résiduel & points de vigilance consolide tout ce qui est connu comme non corrigé, incomplet ou incertain à date de fin de projet (dont un finding critique sur le bastion Guacamole) — à lire avant d'agir sur l'infrastructure, pas seulement pour la comprendre.

Vue d'ensemble de l'infrastructure¶

flowchart TB
    Internet(["Internet"]) --- Forti["FortiGate<br/>(SNAT 10.15.91.14)"]
    Forti --- T0["T0-Edge (NSX, BGP)"]

    subgraph Admin["Zone Admin (T1-Admin) — DFW allow par défaut"]
        Plateforme["Plateforme<br/>vCenter · ESXi ×2 + witness · vSAN<br/>vSAN File Service · Nexus"]
        Identite["Identité<br/>FreeIPA/AD · Vault-PKI · Keycloak<br/>Bastion Guacamole"]
        Donnees["Données<br/>PostgreSQL+repmgr · MySQL"]
        Supervision["Supervision<br/>Zabbix HA · Grafana · NTP"]
        K8s["Kubernetes<br/>kubeadm + Calico"]
        Services["Services métiers<br/>NetBox · GLPI · OCS · Veeam · Postfix"]
    end

    subgraph DMZ["Zone DMZ (T1-DMZ) — deny-all scopé"]
        Proxy["Squid + unbound<br/>(2 nœuds, VIP, NIC admin dédié)"]
    end

    subgraph SOC["Zone SOC (T1-SOC) — deny-all scopé"]
        Kafka["Kafka<br/>(cluster réel, 5 topics)"]
        Syslogng["syslog-ng<br/>(archivage froid)"]
        ELK["ELK<br/>(Elasticsearch/Logstash/Kibana)"]
        SOCTools["MISP / TheHive / Cortex<br/>(VM nues)"]
    end

    T0 --- Admin
    T0 --- DMZ
    T0 --- SOC

    Proxy -.->|"HTTPS whitelisté"| Internet
    Plateforme -->|AWS KMS auto-unseal + S3| AWS[("Cloud AWS")]

    Admin -->|logs, ~53 VM| Kafka
    Kafka --> Syslogng
    Kafka -.->|pont Logstash<br/>non construit| ELK
    Syslogng -.->|rsync .gz<br/>statut au 07-19 incertain| Plateforme

Diagramme simplifié — cardinalités et détails complets sur les pages de chaque brique.

Organisation des dépôts¶

Chaque brique fonctionnelle vit dans son propre dépôt GitLab, sous le groupe indio/iac/ (https://gitlab.infra.indio/indio/iac/<projet>.git), cloné localement sous /root/<projet>/ avec la structure :

<projet>/
├── *.tf                  # Provisioning Terraform (VMs, réseau, ressources cloud)
├── terraform.tfvars.example   # Modèle de variables (le .tfvars réel est gitignoré)
└── ansible/
    ├── site.yml / *.yml  # Playbooks
    ├── roles/
    └── group_vars/

Deux projets n'ont aucune trace git locale ni distante (haproxy, aws-s3-siem) — voir État résiduel & points de vigilance.

Grandes briques¶

Domaine	Composants	Page
Plateforme	vCenter, ESXi, vSAN, vSAN File Service, template Packer, configuration de base, Nexus	vCenter & hôtes ESXi
Réseau	NSX, HAProxy, Squid/unbound (DMZ)	NSX
Identité & Sécurité	FreeIPA, trust AD, durcissement AD, Vault/PKI, Keycloak, bastion Guacamole	FreeIPA & trust AD
Données	PostgreSQL (repmgr + keepalived), MySQL	PostgreSQL
Supervision	Zabbix (HA), Grafana, NTP	Zabbix
SOC / SIEM	Vue d'ensemble du pipeline, ELK, Kafka, syslog-ng, MISP, TheHive, Cortex	Vue d'ensemble SOC
Kubernetes	Cluster kubeadm + Calico	Cluster k8s
Services métiers	NetBox, GLPI, OCS Inventory, Veeam, n8n, Postfix	NetBox
Cloud	AWS (S3, KMS)	AWS

Zones réseau (NSX)¶

L'infrastructure est découpée en zones NSX (T1 dédiés, tous raccordés à un T0-Edge en BGP) :

Zone	Politique DFW par défaut	Segments
Admin (T1-Admin)	Allow par défaut	seg-service, seg-data, seg-supervision, seg-identite, seg-sauvegarde, seg-storage, seg-admin
DMZ (T1-DMZ)	Deny-all scopé (allow ciblés)	seg-proxy, seg-proxy-dns
SOC (T1-SOC)	Deny-all scopé (allow ciblés)	seg-soc-admin, seg-soc

Détails complets : NSX.

Convention de nommage¶

Les VM suivent le schéma IND<SEGMENT><NNN> (ex. INDSOC001, INDDATA002). Voir Convention de nommage.

Gestion des secrets¶

Aucun secret (mot de passe, clé privée, token) n'est versionné en clair dans les dépôts IaC, ni reproduit dans cette documentation. Voir Gestion des secrets pour le mécanisme (Vault, ansible-vault, gitignore).

Comment lire cette documentation¶

Chaque page suit autant que possible la même structure : Rôle (à quoi ça sert dans l'infra Indio), Architecture (schéma + description), Provisioning Terraform / Configuration Ansible (explication du code, pas juste une liste de fichiers), Procédure manuelle (étapes faites à la main, non capturées par l'IaC — souvent la partie la plus utile pour reproduire un composant), Procédure de déploiement, Contrôle de santé, et Points d'attention (pièges réels, incidents, limites connues). Les incertitudes et divergences constatées entre l'historique et l'état vérifié en direct sont signalées explicitement plutôt que masquées — voir par exemple vSAN File Service pour un cas concret.