PD-1 — Provisionner infrastructure VPS DEV avec Terraform + Ansible¶

Métadonnées¶

• ID : PD-1
• Epic : PD-193 — INFRASTRUCTURE-SOUVERAINE
• Type : Infrastructure / Réseau
• Priorité : Critique (fondation)
• Région OVH : GRA11 (Gravelines, France)

1. Résumé¶

Cette User Story vise à provisionner l'infrastructure réseau de base sur OVH Cloud à l'aide de Terraform, constituant le socle souverain de l'architecture ProbatioVault. Cette infrastructure hébergera les composants backend, bases de données et services applicatifs dans un environnement isolé, sécurisé et scalable.

2. Objectifs¶

Objectif principal¶

Créer un VPC OVH Cloud complet, isolé et prêt à accueillir l'ensemble des briques ProbatioVault (API, workers, bases de données, HSM), conformément aux exigences de souveraineté, de sécurité et de résilience.

Sous-objectifs¶

• Isolation réseau stricte via sous-réseaux dédiés
• Accès Internet sortant contrôlé via NAT Gateway
• Sécurisation par Security Groups (principe du moindre privilège)
• Observabilité réseau (logs, métriques, alertes)
• Déploiement reproductible, auditable et versionné (Terraform)

3. Contexte¶

ProbatioVault repose sur une architecture bi-cloud souveraine, où OVH Cloud constitue le socle principal :

• Hébergement en France / UE (RGPD, CNIL)
• Contrôle opérationnel complet (réseau, accès, monitoring)
• Support d'une architecture distribuée, stateless et scalable

Cette User Story est fondatrice et conditionne l'ensemble des développements infrastructure et backend ultérieurs.

4. Architecture réseau cible¶

Plan d'adressage¶

• VPC principal : 10.0.0.0/16

Sous-réseaux¶

• Subnet Public — 10.0.1.0/24
• NAT Gateway
• Load Balancer

• Bastion (optionnel)

• Subnet Privé Backend — 10.0.2.0/24

• API NestJS
• Workers BullMQ

• Redis

• Subnet Privé Database — 10.0.3.0/24

• PostgreSQL Managed OVH

• Subnet Privé HSM — 10.0.4.0/24 (Phase 2)

• HSM Cloud OVH (FIPS 140-2 L3)

5. Portée¶

Inclus¶

• Création du VPC et des subnets
• Déploiement NAT Gateway
• Configuration des routes et Security Groups
• Scripts d'initialisation NAT
• Observabilité réseau

Exclus¶

• Déploiement applicatif (API, DB, Redis)
• Load Balancer managé
• HSM Cloud (Phase 2)

6. Sécurité & conformité¶

Principes appliqués¶

• Zero Trust Network
• Aucun accès direct Internet depuis subnets privés
• NAT Gateway comme unique point de sortie
• Security Groups stricts et minimaux

Conformité¶

• RGPD (article 32)
• Hébergement UE (OVH France)
• Préparation SecNumCloud

6 bis. Diagrammes Mermaid¶

6.1 Diagramme d'états — Cycle de vie du provisionnement VPC¶

Le VPC traverse plusieurs états lors du provisionnement Terraform. L'invariant Zero Trust (§6) impose qu'aucun subnet privé ne soit accessible depuis Internet à aucun moment du cycle de vie.

stateDiagram-v2
    [*] --> INIT : terraform init
    INIT --> PLANNING : terraform plan
    PLANNING --> PROVISIONING_VPC : terraform apply (VPC + subnets)
    PROVISIONING_VPC --> PROVISIONING_ROUTES : routes + NAT Gateway
    PROVISIONING_ROUTES --> PROVISIONING_SG : Security Groups (moindre privilège, §6)
    PROVISIONING_SG --> VALIDATION : tests réseau (§9)
    VALIDATION --> OPERATIONNEL : tous tests OK
    VALIDATION --> ROLLBACK : échec tests
    ROLLBACK --> PLANNING : correction + re-plan
    OPERATIONNEL --> MISE_A_JOUR : terraform plan (drift)
    MISE_A_JOUR --> PROVISIONING_SG : apply changements SG
    MISE_A_JOUR --> PROVISIONING_ROUTES : apply changements routes
    OPERATIONNEL --> DESTRUCTION : terraform destroy
    DESTRUCTION --> [*]

    note right of PROVISIONING_SG
        INV: Aucun port exposé inutilement (§8 Sécurité)
        INV: Flux limités par Security Groups
    end note

    note right of OPERATIONNEL
        INV: VPC Flow Logs actifs (§7 Observabilité)
        INV: State Terraform stocké sur OVH Object Storage
    end note

6.2 Diagramme de séquence — Flux réseau nominal (Backend vers Internet via NAT)¶

Ce diagramme illustre le flux sortant HTTPS depuis le subnet privé Backend, qui transite obligatoirement par le NAT Gateway (unique point de sortie, §6). Le subnet Database reste isolé sans route sortante directe.

sequenceDiagram
    participant API as API NestJS<br/>(10.0.2.0/24)
    participant RT as Route Table<br/>(privée)
    participant NAT as NAT Gateway<br/>(10.0.1.0/24)
    participant SG as Security Group<br/>NAT
    participant EXT as Internet<br/>(HTTPS)

    Note over API,EXT: INV: Aucun accès direct Internet depuis subnets privés (§6 Zero Trust)

    API->>RT: Requête HTTPS sortante (0.0.0.0/0)
    RT->>NAT: Route vers NAT Gateway
    NAT->>SG: Vérification règles egress (port 443)
    SG-->>NAT: Autorisé
    NAT->>EXT: Requête HTTPS (IP publique NAT)
    EXT-->>NAT: Réponse HTTPS
    NAT-->>API: Réponse routée vers subnet Backend

6.3 Diagramme de séquence — Flux réseau nominal (Backend vers PostgreSQL)¶

Ce diagramme illustre la communication inter-subnets contrôlée par Security Groups, conformément au principe du moindre privilège (§6).

sequenceDiagram
    participant API as API NestJS<br/>(10.0.2.0/24)
    participant SG_BE as Security Group<br/>Backend
    participant SG_DB as Security Group<br/>Database
    participant PG as PostgreSQL<br/>(10.0.3.0/24)

    Note over API,PG: INV: PostgreSQL inaccessible depuis Internet (§8 Fonctionnels)

    API->>SG_BE: Connexion TCP port 5432
    SG_BE-->>API: Egress autorisé vers 10.0.3.0/24:5432
    API->>SG_DB: Connexion entrante
    SG_DB-->>SG_DB: Vérification source = 10.0.2.0/24
    SG_DB-->>PG: Ingress autorisé
    PG-->>API: Réponse PostgreSQL

7. Tâches techniques¶

Infrastructure¶

• Création du VPC OVH Cloud
• Création des subnets (public / backend / database / hsm)
• Mise en place des routes
• Déploiement du NAT Gateway

Sécurité¶

• Security Group API Backend
• Security Group Database
• Security Group NAT Gateway

Observabilité¶

• Activation des VPC Flow Logs
• Installation node_exporter sur NAT
• Alertes Prometheus / Grafana

8. Critères d'acceptation¶

Fonctionnels¶

• VPC 10.0.0.0/16 opérationnel
• Subnets isolés et routés correctement
• NAT Gateway fonctionnel (sortie HTTPS)
• PostgreSQL inaccessible depuis Internet

Techniques¶

• Terraform validate / plan / apply sans erreur
• State Terraform stocké sur OVH Object Storage
• Documentation générée automatiquement

Sécurité¶

• Aucun port exposé inutilement
• Flux réseau limités par Security Groups
• Secrets Terraform stockés dans OVH Vault

9. Tests¶

Tests Terraform¶

• Validation syntaxique
• Plan d'exécution
• Vérification des ressources créées

Tests réseau¶

• Accès Internet sortant depuis Backend via NAT
• Connexion Backend → PostgreSQL autorisée
• Accès Internet → PostgreSQL refusé

10. Dépendances¶

Prérequis¶

• PD-0 — Setup Terraform OVH
• Compte OVH avec droits Network / Compute
• OVH Vault opérationnel

Bloquant pour¶

• PD-2 — PostgreSQL Managed
• PD-3 — API NestJS
• PD-4 — Load Balancer

11. Livrables¶

• Code Terraform versionné
• State Terraform sécurisé
• Documentation réseau
• Schéma d'architecture

12. Definition of Done¶

• Infrastructure réseau déployée et fonctionnelle
• Tests d'intégration réseau validés
• Monitoring actif
• Documentation à jour
• Revue technique validée

User Story¶

• Implementation Plan
• Critères d'acceptabilité
• Retour d'expérience (à venir)