Alliance-Boreale/alliance-boreale
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
alliance-boreale/docs/architecture/10 - Stack opérateur de référence (C1-C5).md
Dan Allaire ef98fd8a3f Refonte
2026-03-09 18:23:06 -04:00

5.3 KiB
Raw Blame History

ADR-OPS-STACK-001 — Pile opérateur de référence (C1–C5)

Version : 1.1
Date : 26 janvier 2026
Statut : Adopté (référence vivante)
Portée : Opérateurs (C1–C5), Gouvernance, Audit interne/externe

1. Contexte

L’Alliance Boréale requiert une pile logicielle “Opérateur” stable, reproductible et audit-ready pour opérer les couches C1 à C5 :

  • C1 : capacité (compute) et stockage primaire
  • C2 : segmentation, edge, DNS autoritatif, accès opérateurs
  • C3 : identité et observabilité (SLA, métriques, logs)
  • C4 : forge, traçabilité, CI, artefacts, secrets (plan de vérité)
  • C5 : pivot/membrane (point d’entrée unique) et exécution contrôlée (plan d’exécution)

Cette standardisation vise :

  • réduction de la variabilité inter-opérateurs,
  • amélioration de l’auditabilité (preuves uniformes),
  • simplification du déploiement et de l’exploitation,
  • cohérence stricte avec le principe de membrane (C5).

2. Décision

La pile logicielle suivante est adoptée comme Pile opérateur de référence (C1–C5).

2.1 Stack par couche (C1–C5)

C1 — Compute & Storage

  • Proxmox VE
  • Ceph
  • TrueNAS

C2 — Segmentation, Edge, DNS autoritatif, Accès ops

  • OPNsense
  • PowerDNS Authoritative
  • WireGuard

C3 — IAM & Observabilité

  • Keycloak
  • OpenLDAP
  • Icinga2 + Icinga Web 2 + BPM
  • Prometheus + Alertmanager
  • Grafana
  • Loki

C4 — Forge, CI, Artefacts, Secrets (plan de vérité)

  • Forgejo
  • Forgejo Actions (CI de validation)
  • Harbor
  • Vault
  • Référentiels IaC : OpenTofu (modules) + Ansible (playbooks/inventaires)

C5 — Pivot / membrane (plan d’exécution)

  • NGINX + ModSecurity
  • FastAPI
  • Unbound
  • Exécution IaC : runner contrôlé (OpenTofu + Ansible)

3. Règles d’architecture associées

3.1 Membrane (point d’entrée unique)

  • NGINX + ModSecurity (C5) constitue le point d’entrée unique pour les accès utilisateurs/tenants vers les services exposés (portails, APIs, consultation dashboards).
  • Les composants internes (C2–C4) ne sont pas exposés directement aux tenants.

3.2 Cloisonnement “adjacent-only” (principe opérateur)

  • Le cloisonnement réseau impose une logique “default deny” et une segmentation par couches.
  • Tout contournement de C5 (bypass) est considéré comme une non-conformité sauf exception formalisée.

3.3 Traçabilité (PR + ΔLog)

  • Toute modification (config, infra, politiques, runbooks) est versionnée dans Forgejo via PR.
  • Chaque PR doit être reliée à une entrée ΔLog (trace de décision et de preuve).

3.4 Séparation IaC : référentiel vs exécution (invariant)

Cette séparation est un invariant (sécurité + gouvernance), pas une convention de mots :

  • C4 (plan de vérité) : contient et gouverne le code IaC (OpenTofu/Ansible), la validation CI (format/lint/tests/plan), et la traçabilité (PR/ΔLog).
  • C5 (plan d’exécution) : exécute les actions à privilèges (ex. tofu apply, ansible-playbook) via un runner contrôlé, afin de :
    • concentrer les privilèges au niveau de la membrane,
    • imposer des contrôles uniformes (RBAC, quotas, journalisation),
    • empêcher qu’une compromission de la forge/CI se transforme automatiquement en compromission infra.

Note : le runner d’exécution peut être techniquement un “Forgejo Actions runner”, mais son positionnement réseau et ses droits le rattachent à C5 (membrane).

4. Conséquences

4.1 Bénéfices

  • Standardisation : onboarding opérateur accéléré.
  • Auditabilité : preuves minimales uniformes (BPM, Grafana, Loki, exports OPNsense).
  • Réduction de la surface d’attaque : exécution IaC contrôlée et centralisée en C5.
  • Exploitabilité : séparation claire entre observabilité (C3) et exposition (C5).

4.2 Obligations

  • Discipline de changements : PR + ΔLog obligatoires.
  • Preuves : collecte structurée et indexée selon la politique POL-OPS-STACK-001.
  • Maintien : versions supportées, runbooks, et exécutions IaC traçables.

5. Critères d’acceptation

La pile est considérée en place pour un opérateur lorsque :

  1. Tous les composants (C1–C5) sont déployés et accessibles conformément au principe de membrane.
  2. Le cloisonnement réseau est démontré (OPNsense + tests de non-bypass).
  3. SSO (Keycloak) protège les portails (Grafana, Icinga Web) via C5.
  4. Les preuves minimales POL-OPS-STACK-001 existent, datées et indexées.
  5. Les changements IaC sont gouvernés en C4, et exécutés via C5 avec traçabilité complète.

6. Gouvernance des changements

Toute modification à la pile opérateur de référence exige :

  • PR + ΔLog,
  • mise à jour des runbooks et des preuves attendues,
  • ADR additionnel si changement de composant ou de rôle.

7. Références internes

  • POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5) — preuves attendues
  • ADR-OBS-001 — Loki comme backend de logs de référence
  • POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki

8. ΔLog (à compléter au commit)

  • Décision : Adoption de la pile opérateur de référence (C1–C5)
  • Auteur(s) : __________________
  • Référence PR : __________________
  • Date d’entrée : __________________