2026-07-26 11:44:34 +02:00
1 changed files with 1 additions and 1 deletions
@@ -91,7 +91,7 @@ Le compte de service est **par application** : ajouter un bucket ne crée aucune
 - **Le dépôt `tools` n'est plus modifié** quand une application change ses buckets. C'était l'objet de la décision.
 - **Ordre de déploiement contraint** : le module doit exister sur `main` de `tools` avant qu'une application l'appelle (`?ref=main`), et le provisionneur doit exister avant le premier plan d'application.
 - **Le provisionneur est un secret partagé** entre les rôles CI. Sa compromission permet de créer des buckets et des comptes, pas de lire des objets. Si ce risque devient inacceptable, la suite est une identité de provisionnement **par application**, bornée par préfixe de bucket — MinIO ne le permet pas simplement aujourd'hui.
- **Non vérifié à la rédaction** : les noms d'actions d'administration MinIO de la politique du provisionneur viennent de la documentation, pas d'un essai. Le premier `apply` les confirmera ou les corrigera.
+- **Vérifié par le premier `apply`** (kadans, 2026-07-26) : les actions d'administration passent telles quelles — compte de service, politique et attachement ont été créés. Une seule correction a été nécessaire côté S3, `s3:ListBucket` : le provider interroge l'existence du bucket (HeadBucket) avant de le créer, et MinIO répond `Access Denied` sans cette action. Elle donne au provisionneur la vue des **clés** d'un bucket, jamais leur **contenu** — la garantie « ne peut pas lire les vidéos d'une autre app » tient toujours.

 ## Alternatives Considered