Cloudflare a scindé l'accès à Workers en rôles et portées plutôt qu'en une seule grande liste de permissions

À mesure que davantage d'équipes et d'agents de codage autonomes ont commencé à déployer directement sur la Developer Platform de Cloudflare, le modèle de permissions existant imposait un choix inconfortable : accorder des rôles étendus à l'échelle du compte qui permettaient à un agent de toucher chaque Worker, base de données et bucket du compte, ou construire à la main suffisamment de permissions individuelles pour couvrir tous les cas — ce qui devient ingérable à mesure que le nombre de ressources et d'actions augmente.

La correction apportée par Cloudflare a consisté à cesser de traiter l'accès comme une liste plate et à définir plutôt deux dimensions indépendantes. Quatre rôles — Metadata Read-Only, Content Read-Only, Editor et Admin — décrivent des niveaux de capacité, depuis la consultation des journaux et des métriques sans voir le code, jusqu'à la lecture du code sans le modifier, puis la modification sans suppression, et enfin le contrôle total. Séparément, chaque rôle peut être appliqué à l'une de trois portées : chaque ressource de la Developer Platform, chaque ressource d'un produit (tous les Workers), ou une seule ressource nommée (un Worker précis).

Les deux axes se composent indépendamment. Un pipeline CI/CD peut recevoir le rôle Editor limité à exactement le Worker qu'il déploie, de sorte qu'un jeton divulgué peut mettre à jour ce Worker mais ne peut ni le supprimer ni toucher une autre application. Un agent de débogage peut recevoir Metadata Read-Only limité à un Worker, afin de consulter les journaux et les traces sans jamais lire le code source. Cloudflare a conçu cette même structure à deux dimensions (rôles et portées) pour l'étendre ultérieurement à d'autres ressources de la Developer Platform comme les bases de données D1 et les buckets R2, plutôt que d'inventer de nouvelles permissions pour chaque produit.

Séparer « ce que vous pouvez faire » (le rôle) de « où vous pouvez le faire » (la portée) en deux axes indépendants

Croiser quatre rôles avec trois portées produit douze niveaux d'accès précis à partir d'un vocabulaire restreint et fixe, au lieu d'une explosion combinatoire de permissions ponctuelles par ressource.

Limiter la portée à une seule ressource (un Worker) signifie qu'un jeton d'agent compromis ou mal configuré a un rayon d'impact contenu — il ne peut ni voir ni toucher aucune autre ressource du compte.

La même structure rôle/portée a été conçue pour s'étendre à d'autres produits (D1, R2, KV) sans redéfinir le modèle à chaque fois.

Les Durable Objects héritent de l'accès du rôle de leur Worker parent plutôt que de nécessiter leur propre système de permissions, ce qui évite une fragmentation supplémentaire du modèle.

Lorsque les besoins d'accès se multiplient avec davantage d'agents, n'ajoutez pas de permissions individuelles supplémentaires — scindez le contrôle d'accès en deux axes orthogonaux, la capacité et la portée, qui se composent au lieu de se multiplier.

Cloudflare a également ajouté des réponses d'erreur 403 contextuelles qui renvoient directement à la documentation décrivant quelle permission manque, afin qu'un agent ou un développeur confronté à un mur de permissions puisse se corriger lui-même au lieu de rester bloqué sur une réponse générique « Forbidden ». L'entreprise a déclaré qu'elle prévoit d'étendre ensuite le même modèle de rôles et de portées aux bases de données D1, aux buckets R2 et aux espaces de noms KV.