Le provider teste l'existence du bucket avant de le créer (HeadBucket), et MinIO exige s3:ListBucket pour répondre à cette question. La politique du provisionneur avait s3:CreateBucket mais pas de quoi regarder — donc elle ne pouvait rien créer.
C'était le seul point que l'ADR annonçait comme non éprouvé (« les noms d'actions viennent de la documentation, pas d'un essai »). Le reste — tout le bloc admin:* — est confirmé par ce même run.
Ce que ça concède, et ce que ça ne concède pas
s3:ListBucket donne la vue des clés d'un bucket. Pas leur contenu : s3:GetObject et s3:PutObject restent absents. La garantie qui justifie de partager ce compte entre les rôles CI — « il peut créer des buckets, il ne peut pas lire les vidéos d'une autre application » — tient donc toujours.
Une PR jumelle met l'ADR à jour (factory) : le paragraphe « non vérifié à la rédaction » devient un constat.
Le premier `apply` réel côté kadans (run 470) est allé **jusqu'au bout de la partie difficile** puis a buté sur la plus simple :
```
module.stockage.minio_iam_policy.app: Creation complete [id=kadans-app]
module.stockage.minio_iam_user.app: Creation complete [id=kadans-app]
module.stockage.minio_iam_user_policy_attachment.app: ok
module.stockage.vault_kv_secret_v2.app: Creation complete [id=kvv2/data/minio/kadans]
Error: [FATAL] unable to check bucket (kadans-videos): Access Denied.
```
## Cause
Le provider teste l'existence du bucket **avant** de le créer (`HeadBucket`), et MinIO exige `s3:ListBucket` pour répondre à cette question. La politique du provisionneur avait `s3:CreateBucket` mais pas de quoi *regarder* — donc elle ne pouvait rien créer.
C'était le seul point que l'ADR annonçait comme non éprouvé (« les noms d'actions viennent de la documentation, pas d'un essai »). Le reste — tout le bloc `admin:*` — est confirmé par ce même run.
## Ce que ça concède, et ce que ça ne concède pas
`s3:ListBucket` donne la vue des **clés** d'un bucket. Pas leur contenu : `s3:GetObject` et `s3:PutObject` restent absents. La garantie qui justifie de partager ce compte entre les rôles CI — *« il peut créer des buckets, il ne peut pas lire les vidéos d'une autre application »* — tient donc toujours.
Une PR jumelle met l'ADR à jour (`factory`) : le paragraphe « non vérifié à la rédaction » devient un constat.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Le premier apply réel (kadans) a créé la politique, le compte de service,
l'attachement et le secret Vault — puis a échoué sur le bucket lui-même :
Error: [FATAL] unable to check bucket (kadans-videos): Access Denied.
Le provider teste l'existence du bucket AVANT de le créer (HeadBucket), et
MinIO exige `s3:ListBucket` pour ça. C'est le seul point que l'ADR annonçait
comme non éprouvé ; il l'est maintenant.
`s3:ListBucket` donne la vue des CLÉS d'un bucket, pas leur contenu :
GetObject / PutObject restent absents, donc le provisionneur — partagé entre
les rôles CI — ne peut toujours pas lire les vidéos d'une autre application.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Le premier
applyréel côté kadans (run 470) est allé jusqu'au bout de la partie difficile puis a buté sur la plus simple :Cause
Le provider teste l'existence du bucket avant de le créer (
HeadBucket), et MinIO exiges3:ListBucketpour répondre à cette question. La politique du provisionneur avaits3:CreateBucketmais pas de quoi regarder — donc elle ne pouvait rien créer.C'était le seul point que l'ADR annonçait comme non éprouvé (« les noms d'actions viennent de la documentation, pas d'un essai »). Le reste — tout le bloc
admin:*— est confirmé par ce même run.Ce que ça concède, et ce que ça ne concède pas
s3:ListBucketdonne la vue des clés d'un bucket. Pas leur contenu :s3:GetObjectets3:PutObjectrestent absents. La garantie qui justifie de partager ce compte entre les rôles CI — « il peut créer des buckets, il ne peut pas lire les vidéos d'une autre application » — tient donc toujours.Une PR jumelle met l'ADR à jour (
factory) : le paragraphe « non vérifié à la rédaction » devient un constat.🤖 Generated with Claude Code
https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Le premier apply réel (kadans) a créé la politique, le compte de service, l'attachement et le secret Vault — puis a échoué sur le bucket lui-même : Error: [FATAL] unable to check bucket (kadans-videos): Access Denied. Le provider teste l'existence du bucket AVANT de le créer (HeadBucket), et MinIO exige `s3:ListBucket` pour ça. C'est le seul point que l'ADR annonçait comme non éprouvé ; il l'est maintenant. `s3:ListBucket` donne la vue des CLÉS d'un bucket, pas leur contenu : GetObject / PutObject restent absents, donc le provisionneur — partagé entre les rôles CI — ne peut toujours pas lire les vidéos d'une autre application. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA