Cloudflare Worker : cloisonner les droits de déploiement par client

Les quatre rôles Worker de Cloudflare transforment un identifiant de déploiement partagé en frontière propre à chaque client. Depuis le 15 septembre 2026, une agence peut laisser la CI d’un client déployer un seul Cloudflare Worker existant sans lui accorder le droit de le supprimer ni l’accès à tous les autres Workers du compte, à condition qu’aucune politique plus large n’élargisse ces droits.

Cloudflare Worker : le vrai changement tient au périmètre

Une autorisation repose sur deux éléments. Le rôle définit les actions permises. Le périmètre détermine où elles le sont.

Cloudflare permet désormais d’associer un rôle Worker au périmètre d’un Worker précis pour un membre de l’équipe, un User Group, un agent ou un token API. Le même rôle peut toujours couvrir tous les Workers, mais ce n’est plus une obligation.

Ce réglage peut sembler mineur. Pour un studio ou une agence qui gère plusieurs clients dans un même compte Cloudflare, il change pourtant la transmission des accès : l’identifiant de déploiement du client A peut désormais s’arrêter au Worker du client A.

La mise à jour du 15 septembre est disponible pour tous les clients et se configure depuis le dashboard, l’API ou Terraform.

Voici l’ensemble des rôles décrit dans la documentation des rôles Workers :

Cette séparation est utile, car diagnostiquer un incident, relire du code, livrer une version et supprimer le service correspondent à quatre missions différentes. Elles ne devraient pas toutes hériter du même identifiant.

Les anciennes permissions Workers de Cloudflare s’appliquaient à l’échelle du compte. Le nouveau modèle peut couvrir toute la Developer Platform, tous les Workers ou un seul Worker existant. Une politique Workers au niveau du produit englobe chaque Worker actuel et futur. Une politique par Worker ne vise que ceux qui ont été sélectionnés.

Une limite structurelle demeure : impossible de définir le périmètre sur un Worker qui n’existe pas encore. La création d’un nouveau Worker exige toujours le rôle Admin au niveau du produit.

Ce que ce cloisonnement change pour la livraison client

Prenons une petite agence qui héberge un Worker par client. Son workflow de déploiement doit publier de nouvelles versions de client-a-api. Il n’a pas besoin de créer des Workers, de supprimer celui-ci ni d’intervenir sur client-b-checkout.

Avant cette mise à jour, les permissions couramment accordées à la CI pour Workers — désormais qualifiées de legacy par Cloudflare — s’appliquaient au compte entier. Deux options nettes existaient alors : accepter un identifiant trop large ou placer le client dans un autre compte. Le périmètre individuel ajoute une troisième voie : conserver l’organisation du compte, mais accorder au token de déploiement le rôle Editor uniquement sur client-a-api.

Le calcul de l’abonnement ne change pas, puisque les contrôles au niveau du Worker sont proposés à tous les clients. En revanche, le calcul opérationnel, lui, évolue.

Ce modèle laisse de côté un arbitrage important. Douze identifiants client cloisonnés représentent davantage de secrets à émettre, stocker et renouveler qu’un token partagé. Le gain ne vient pas d’un nombre inférieur d’identifiants, mais d’un périmètre d’enquête plus réduit lorsqu’un identifiant échoue ou fuit.

Pour un fondateur solo avec un seul Worker et aucun accès de déploiement partagé, le changement sera presque imperceptible. Même constat pour une équipe qui confie volontairement tous les Workers à son groupe plateforme. Cette évolution devient utile lorsque plusieurs personnes, clients ou jobs automatisés partagent un compte Cloudflare sans devoir partager le même rayon d’impact.

Donner au job de déploiement d’un client les droits nécessaires

Pour une première transmission propre, partez d’un Worker existant associé à une Route ou à un Custom Domain stable. Ainsi, le job de déploiement n’a pas à créer le Worker ni à modifier son domaine.

1. 1

   Définir la tâche avant de choisir le rôle

   Commencez par une phrase : « Ce workflow déploie de nouvelles versions du Worker existant client-a-api. »

   Cette formulation mène au rôle Editor avec un périmètre limité au Worker concerné. Si le job doit créer un nouveau Worker, il lui faut Admin au niveau du produit. S’il doit ajouter, modifier ou supprimer une Route ou un Custom Domain, il lui faut aussi Workers Routes Write pour chaque zone concernée.

2. 2

   Créer un token API détenu par le compte

   Dans Cloudflare, ouvrez Manage Account > Account API Tokens et créez un token détenu par le compte. Définissez son périmètre sur Specified Workers, sélectionnez client-a-api, puis choisissez Editor.

   Pour ce workflow, utilisez un token détenu par le compte, et non le token utilisateur d’une personne. Cloudflare présente ces tokens comme des identités de service destinées aux intégrations durables : le déploiement ne s’arrête donc pas au départ de la personne qui l’a créé. Leur création ou leur mise à jour exige la permission Super Administrator.

3. 3

   Exécuter Wrangler avec ce token

   Enregistrez le token dans le coffre de secrets du système de déploiement. Cloudflare documente les variables d’environnement suivantes pour Wrangler :

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   Exécutez ces commandes depuis le projet configuré pour le Worker existant. wrangler login ne convient pas ici, car son flux OAuth ne prend pas encore en charge les autorisations granulaires.

4. 4

   Basculer sur le nouveau token, puis supprimer l’accès large

   Déployez une version sans risque avec le nouveau token et vérifiez que le Worker prévu est bien mis à jour. Assurez-vous que le token ne possède aucun rôle Workers au niveau du produit et aucun périmètre de ressource sans rapport.

   Retirez ensuite l’ancien secret de déploiement étendu de ce workflow. Conserver les deux identifiants pendant le test est raisonnable. Les garder tous les deux après le test annule le cloisonnement.

Voilà toute la transmission nécessaire à un déploiement courant. Le job du client peut mettre à jour, téléverser, déployer, restaurer, renommer et gérer les secrets de ce Worker, car toutes ces actions relèvent d’Editor. Il ne peut pas supprimer le Worker, et la politique par Worker ne lui ouvre aucun accès aux autres Workers.

Quatre missions, quatre politiques cohérentes

Un agent de support qui doit seulement recueillir des éléments

Accordez à un agent chargé du diagnostic le rôle Metadata Read-Only sur le Worker concerné. Il pourra consulter les paramètres, métriques, logs et traces sans lire le code source ni modifier le service.

Le workflow de support peut ainsi réunir les éléments utiles sans devenir discrètement un workflow de revue de code ou de déploiement. Le même rôle suffit pour utiliser wrangler tail sur ce Worker.

Un développeur externe chargé de relire le projet d’un client

Accordez à un prestataire Content Read-Only sur le Worker du client. Il pourra examiner le code déployé et les paramètres, sans pouvoir modifier ni déployer le service.

La frontière de la revue devient plus nette. Il n’est plus nécessaire d’accorder Editor au seul motif que la personne chargée de la revue doit comprendre ce qui tourne en production.

Un pipeline CI propre à un client

Accordez à un token détenu par le compte le rôle Editor sur un seul Worker existant. Il pourra publier des versions et revenir en arrière sans supprimer le Worker ni atteindre les autres Workers.

C’est le scénario le plus pertinent pour une transmission d’agence, car l’identifiant appartient au workflow plutôt qu’à un membre de l’équipe. Si des agents de navigation travaillent aussi pour vos clients, les contrôles d’hôtes autorisés de Cloudflare traitent l’autre moitié du périmètre : les destinations accessibles au navigateur. Cette mise à jour, elle, définit le Worker que l’identité de déploiement peut modifier.

Un responsable plateforme qui gère le cycle de vie

Réservez Admin au membre de l’équipe ou à l’automatisation qui a réellement besoin du droit de suppression. Conservez le rôle Admin au niveau du produit pour le responsable qui crée les Workers, puis confiez le Worker finalisé à des politiques quotidiennes plus étroites.

Cette organisation sépare clairement les opérations de cycle de vie des livraisons courantes. Un job de déploiement n’a pas besoin des mêmes pouvoirs que la personne qui crée et retire les services clients.

Un périmètre plus étroit ne garantit pas une isolation complète

Le bénéfice annoncé est réel, mais résumer la mesure à « un seul Worker » peut donner un faux sentiment de sécurité.

Les Durable Objects demandent la même vigilance. Ils n’ont ni rôles ni périmètres indépendants : ils héritent de l’accès accordé au Worker qui les implémente. Metadata Read-Only inclut les métriques, logs et traces des Durable Objects sans donner accès aux données stockées. Editor atteint toutefois aussi le niveau d’autorisation documenté pour interroger ou modifier, dans Data Studio, les données d’un Durable Object adossé à SQLite.

Les Routes constituent une autre frontière distincte. Editor suffit pour déployer une nouvelle version tant qu’une Route ou un Custom Domain existant reste inchangé. Pour modifier cette association, Workers Routes Write est également requis sur chaque zone concernée. Cloudflare précise aussi que les Custom Domains ne prennent actuellement pas en charge les rôles par Worker.

Enfin, les permissions Cloudflare se cumulent. Une politique directe étroite n’annule pas une politique large héritée d’un User Group. La vue Members affiche les permissions directes, tandis que les politiques héritées des groupes doivent être contrôlées dans l’onglet Groups. Sans cette vérification, l’écran peut montrer la politique restreinte recherchée alors que les permissions effectives restent larges.

Qui doit agir maintenant ?

Agissez cette semaine si un compte contient plusieurs Workers clients et qu’une personne, un agent ou un job CI conserve une permission couvrant tous les Workers pour une mission qui n’en concerne qu’un. Le bénéfice est maximal lorsque le Worker existe déjà et que ses connexions de domaine ne changent pas pendant les déploiements courants.

Attendez avant de restreindre le token si le workflow crée des Workers, modifie des Routes ou des Custom Domains, ou dépend d’un accès direct aux produits de données liés. Cartographiez d’abord ces actions, au risque sinon de voir le prochain déploiement échouer en cours de route.

Vous n’êtes pas concerné si vous ne partagez jamais l’accès aux Workers, si vous n’exploitez qu’un seul Worker ou si vous confiez volontairement le déploiement à une équipe plateforme responsable de tout le compte.

L’action à mener dès lundi

Commencez par modifier la politique d’autorisation derrière le déploiement CI d’un client existant. Attribuez Editor à un token détenu par le compte, limitez-le à ce seul Worker, recensez chaque binding et chaque Durable Object hérité qu’il peut affecter, vérifiez les politiques directes et celles des groupes, puis déployez sans modifier la Route ni le Custom Domain.

Une fois ce test validé, supprimez l’ancien secret couvrant tous les Workers. Cette première bascule établit une vraie frontière et fournit un modèle à reproduire pour le client suivant.

Pour recevoir d’autres analyses opérationnelles et accessibles sur les évolutions des plateformes, inscrivez-vous à la newsletter.