154 lines
No EOL
6.7 KiB
Markdown
154 lines
No EOL
6.7 KiB
Markdown
# ADR-C5-CTRL-001 — ERPLibre “cockpit” en tenant opérateur et FastAPI comme plan de contrôle C5
|
||
|
||
**Version :** 1.1
|
||
**Date :** 31 janvier 2026
|
||
**Statut :** Adopté
|
||
**Portée :** Pile opérateur de référence (C1–C5), Gouvernance, Admission tenants, Sécurité, Audit
|
||
|
||
---
|
||
|
||
## 1) Contexte
|
||
|
||
La pile opérateur de référence fixe **C5** comme **membrane** (point d’entrée unique) entre la Fédération (C1–C4) et les tenants (C6–C8).
|
||
C5 doit porter un **plan de contrôle** : admission, quotas, RBAC, orchestration (runner), production de preuves.
|
||
|
||
Dans le même temps, un besoin fort émerge : disposer d’un **cockpit** (portail “au premier plan”) pour piloter la gouvernance opérationnelle (demandes, onboarding, changements, approbations), sans compromettre la membrane.
|
||
|
||
---
|
||
|
||
## 2) Problème
|
||
|
||
Deux impératifs doivent coexister :
|
||
|
||
1. **C5 doit rester minimal, durci, audit-friendly** : la membrane ne doit pas se transformer en suite applicative riche.
|
||
2. **Le pilotage opérationnel doit être ergonomique et fédérateur** : un portail/cockpit central améliore l’adoption et la cohérence.
|
||
|
||
Le risque à éviter : déplacer des privilèges infrastructurels et des intégrations sensibles dans une application riche exposée, au détriment du non-bypass, de l’auditabilité et de la surface d’attaque.
|
||
|
||
---
|
||
|
||
## 3) Décision
|
||
|
||
### 3.1 ERPLibre est “aux commandes” comme cockpit — mais en tant que tenant
|
||
|
||
ERPLibre est positionné comme **cockpit de gouvernance** **dans un tenant de l’opérateur fédéré** (tenant dédié “Gouvernance/Back-office”).
|
||
Il pilote le workflow humain (demandes, approbations, dossiers, suivi), et déclenche les actions **par contrat**, sans privilèges directs sur les couches internes.
|
||
|
||
> ERPLibre est **au premier plan** (UX, orchestration métier), mais **pas** le plan de contrôle de la membrane.
|
||
|
||
### 3.2 FastAPI demeure le plan de contrôle en C5
|
||
|
||
FastAPI est maintenu en **C5** comme **Pivot API / Plan de contrôle** pour :
|
||
|
||
- l’admission (validation des descripteurs),
|
||
- l’application des politiques (quotas, conformité),
|
||
- l’orchestration d’exécution (runner C5 OpenTofu/Ansible),
|
||
- la gestion d’accès (RBAC via Keycloak et services fédérés),
|
||
- la production et l’indexation des preuves (audit).
|
||
|
||
### 3.3 Règle d’intégration : “Commander par le contrat, pas par des accès directs”
|
||
|
||
ERPLibre **commande** via des mécanismes traçables et contrôlés :
|
||
|
||
- PR + ΔLog (Git comme source de vérité),
|
||
- appels API C5 (demande d’exécution et suivi),
|
||
- lecture d’état / preuves (status/evidence).
|
||
|
||
ERPLibre **ne** doit **pas** disposer d’accès directs à C2/C3/C4 (DNS autoritatif, IAM admin, secrets admin, forge admin, etc.).
|
||
|
||
---
|
||
|
||
## 4) Architecture cible (rôle et flux)
|
||
|
||
### 4.1 Déploiement et exposition
|
||
|
||
- ERPLibre est déployé comme **workload applicatif** dans le **tenant “Gouvernance/Back-office”** de l’opérateur.
|
||
- Il est exposé **via C5** (NGINX+ModSecurity) et protégé par **SSO** (Keycloak), conformément à la membrane.
|
||
- ERPLibre n’est pas un composant de C5 : il est un **consommateur** du plan de contrôle.
|
||
|
||
### 4.2 “Git comme source de vérité” (flux recommandé)
|
||
|
||
1. Une demande est créée et approuvée dans ERPLibre (onboarding / changement).
|
||
2. ERPLibre génère/édite un **TenantDescriptor** (YAML) et ouvre une **PR** dans Forgejo avec ΔLog.
|
||
3. CI (Forgejo Actions) valide : schéma/politiques, lint, et `tofu plan` (si applicable).
|
||
4. Sur merge, FastAPI (C5) récupère le YAML (commit SHA), **revalide**, puis :
|
||
- déclenche le runner C5 (OpenTofu/Ansible),
|
||
- orchestre RBAC et intégrations nécessaires,
|
||
- produit `run_id`, journaux, et preuves (evidence pack).
|
||
5. ERPLibre consulte l’état via C5 (status/runs/evidence) et présente le suivi au demandeur.
|
||
|
||
### 4.3 Flux API (complémentaire)
|
||
|
||
ERPLibre peut appeler C5 pour :
|
||
|
||
- demander l’exécution d’un changement référencé par `tenant_id + commit_sha`,
|
||
- suivre un `run_id`,
|
||
- afficher les preuves disponibles.
|
||
|
||
---
|
||
|
||
## 5) Contraintes de sécurité et de conformité (non négociables)
|
||
|
||
### 5.1 Membrane / non-bypass
|
||
|
||
- Tous les flux exposés passent par C5 (NGINX+ModSecurity).
|
||
- Aucun accès direct tenant → C2/C3/C4.
|
||
|
||
### 5.2 Principe du moindre privilège
|
||
|
||
- ERPLibre n’obtient jamais de privilèges “infra” larges.
|
||
- Les actions à privilèges sont exécutées **uniquement** via le runner C5, sous contrôle C5.
|
||
|
||
### 5.3 Traçabilité
|
||
|
||
- Tout changement : PR + ΔLog obligatoires.
|
||
- Tout provisioning : PR → run_id → logs → preuves indexées.
|
||
|
||
### 5.4 Preuves auditables
|
||
|
||
- C5 produit des preuves standardisées et indexées dans le dépôt `operator-stack/` (evidence pack trimestriel, exports, manifests/hashes si adoptés).
|
||
|
||
---
|
||
|
||
## 6) Justification (pourquoi c’est la solution la plus robuste)
|
||
|
||
- **ERPLibre** est idéal pour être un cockpit : workflow humain, dossiers, demandes, suivi, ergonomie.
|
||
- **C5** doit rester un plan de contrôle minimal : plus un composant est riche à la membrane, plus il est coûteux à sécuriser, patcher, auditer.
|
||
- Cette décision maximise l’adoption (ERPLibre visible) sans diluer la rigueur (FastAPI contrôle et prouve).
|
||
|
||
---
|
||
|
||
## 7) Alternatives considérées
|
||
|
||
1. **ERPLibre en C5 (remplacement complet)** : rejeté (surface d’attaque, complexité, périmètre flou, audit alourdi).
|
||
2. **FastAPI seul sans cockpit** : acceptable techniquement, mais moins fédérateur et moins ergonomique.
|
||
3. **Cockpit alternatif** : possible, tant qu’il reste “tenant” et qu’il commande par contrat via C5.
|
||
|
||
---
|
||
|
||
## 8) Critères d’acceptation
|
||
|
||
La décision est considérée opérationnelle lorsque :
|
||
|
||
1. ERPLibre est déployé dans un tenant dédié “Gouvernance/Back-office” de l’opérateur et exposé via C5.
|
||
2. SSO Keycloak protège ERPLibre (et les portails) via la membrane.
|
||
3. ERPLibre génère/édite un TenantDescriptor et ouvre une PR + ΔLog dans Forgejo.
|
||
4. FastAPI en C5 valide et orchestre l’exécution via runner C5, produisant un `run_id`.
|
||
5. Les preuves sont déposées et indexées (operator-stack/evidence/…), consultables via C5.
|
||
6. Un test de non-bypass démontre l’impossibilité d’accès direct tenant → C2/C3/C4.
|
||
|
||
---
|
||
|
||
## 9) Impacts sur la pile opérateur de référence
|
||
|
||
- Aucun changement à la pile C1–C5 : FastAPI reste en C5.
|
||
- Ajout d’un **tenant opérateur dédié** (workload) : ERPLibre devient une application “premier plan” consommant le plan de contrôle C5.
|
||
|
||
---
|
||
|
||
## 10) ΔLog (à compléter au commit)
|
||
|
||
- Décision : ERPLibre cockpit en tenant opérateur ; FastAPI plan de contrôle C5 ; commande par contrat (PR+ΔLog+API)
|
||
- Auteur(s) : \_________________\_
|
||
- Référence PR : \_________________\_
|
||
- Date d’entrée : \_________________\_ |