Cloudflare a annoncé la disponibilité de contrôles d’accès au niveau de chaque Worker, permettant d’accorder à un utilisateur, à un agent logiciel ou à un jeton API l’autorisation d’interagir avec une application donnée sans accéder aux autres ressources du compte. Cette évolution s’accompagne de quatre nouveaux rôles pour la plateforme destinée aux développeurs, conçus pour séparer la surveillance de l’application, la lecture de son contenu, sa modification et son administration complète.
Les contrôles sont disponibles pour tous les clients à compter du 15 septembre 2026 et peuvent être configurés depuis le tableau de bord Cloudflare, via l’API ou avec Terraform. Ils peuvent également être appliqués à un utilisateur individuel ou à un User Group, auquel cas tous les membres du groupe héritent de la même politique.
Quatre niveaux d’autorisation
- Metadata Read-Only : permet de consulter les listes de ressources, leurs paramètres et les données de surveillance, telles que les métriques, les journaux et les traces, sans accéder au contenu du produit ni au code. Ce rôle convient à l’analyse des pannes lorsque la lecture du code source n’est pas nécessaire.
- Content Read-Only : permet de lire le contenu du produit, comme le code d’un Worker ou le contenu d’une base D1, sans modifier ni déployer de changements.
- Editor : permet de lire et d’écrire le contenu et de mettre à jour les paramètres, mais n’autorise pas la création ou la suppression de ressources. Cloudflare le présente comme une option adaptée aux systèmes CI/CD qui doivent déployer des changements sur un Worker donné.
- Admin : accorde un contrôle complet sur la ressource, notamment la création, le changement de nom, la suppression et l’octroi d’un accès à d’autres utilisateurs, avec la possibilité de limiter cette autorisation à un seul Worker plutôt qu’à l’ensemble du compte.
Qu’est-ce qui change concrètement ?
L’équipe d’exploitation peut accorder à un ingénieur ou à un agent l’autorisation Metadata Read-Only afin qu’il examine les paramètres, les métriques, les journaux et les traces sans exposer le code. De même, un agent peut effectuer une revue du code avec Content Read-Only sans avoir la capacité de le déployer ou de modifier les paramètres de l’application.
Dans les pipelines CI/CD, il est possible de créer un jeton API doté du rôle Editor et limité à un seul Worker. Si le pipeline est mal configuré ou si le jeton est exposé, sa capacité reste limitée au déploiement de changements pour cette application, sans possibilité de supprimer le Worker ou de modifier d’autres applications du compte. Cloudflare précise que ces autorisations s’appliquent selon trois portées : l’ensemble de la plateforme destinée aux développeurs, un produit donné tel que Workers, ou une ressource précise telle qu’un seul Worker.
Restrictions importantes concernant la portée et les connexions
L’accès à un Worker ne suffit pas à lui seul pour ajouter, modifier ou supprimer une Route ou un Custom Domain. Ces opérations exigent l’autorisation Editor sur le Worker, ainsi que l’autorisation Workers Routes propre à la zone. Cette séparation permet de gérer la manière dont le trafic est dirigé vers l’application sans accorder de privilèges plus larges sur les paramètres du domaine.
Une fois la route configurée, le système CI/CD peut continuer à déployer de nouvelles versions tant que le déploiement ne modifie pas la connexion existante, sans lui accorder d’accès aux domaines, aux bases de données ou au stockage associés. Les Durable Objects dépendent également des autorisations du Worker qui les exécute : le rôle Metadata Read-Only permet d’accéder à leurs métriques, journaux et traces, mais pas de lire les données qui y sont stockées. L’accès à Data Studio, qui peut interroger et modifier les données, exige le rôle Editor.
Messages d’erreur et anciennes versions
Cloudflare a mis à jour les réponses de l’API lorsque des opérations sont refusées. Elles ne se limitent plus à l’erreur générique 403 Forbidden, mais incluent un lien vers la documentation indiquant l’autorisation requise. Cela devrait aider les utilisateurs et les agents à configurer précisément les autorisations au lieu de les élargir au hasard.
L’entreprise recommande de passer aux nouveaux rôles plutôt que d’utiliser les anciennes autorisations propres à Workers, mais elle n’a annoncé aucune date de retrait de ces dernières. Les affectations actuelles continueront de fonctionner jusqu’à la communication d’un préavis. Cloudflare prévoit d’étendre le même modèle à d’autres produits, notamment D1, R2 et KV, afin de pouvoir limiter l’accès à une base de données ou à un espace de stockage précis.
Lecture de certi.news
Le changement concret ne consiste pas seulement à ajouter un nouveau rôle d’administration, mais à déplacer le contrôle du niveau du compte ou du produit vers celui de la ressource, avec une séparation claire entre les données de surveillance, le contenu et l’exécution. Cela est particulièrement important pour les équipes qui utilisent des agents logiciels ou des pipelines de déploiement automatisés, car une erreur ou une fuite de jeton peut être contenue dans un seul Worker. En revanche, la gestion des routes et des domaines reste un point nécessitant une autorisation distincte, tandis que la prise en charge de D1, R2 et KV est encore mentionnée comme un projet ultérieur et non comme une disponibilité actuelle. Quant au maintien des anciennes autorisations sans date de retrait annoncée, il signifie que les organisations devront revoir progressivement leurs politiques au lieu de supposer une transition immédiate.