151 lines
5.3 KiB
Markdown
151 lines
5.3 KiB
Markdown
# 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 : __________________
|
||
|