alliance-boreale/docs/10-architecture/10 - Stack opérateur de référence (C1-C5).md

# 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 : __________________