Cloudflare Workers : un jeton CI/CD limité à un seul Worker

Depuis le 15 septembre 2026, Cloudflare permet à ses clients de limiter l’accès d’un membre, d’un agent ou d’une chaîne CI/CD à un Worker précis. D’après le changelog de Cloudflare, ces contrôles sont disponibles pour tous les clients et configurables depuis le tableau de bord, l’API ou Terraform.

Pour déployer une application existante avec le minimum de privilèges, il faut attribuer le rôle Editor à un jeton API limité au Worker concerné. Le jeton peut alors mettre à jour et déployer cette application, sans pouvoir la supprimer ni intervenir sur les autres Workers du compte — sauf si une autre politique lui accorde déjà des droits plus larges.

Quatre tâches, quatre niveaux d’accès minimal

Le modèle sépare le rôle, qui définit les opérations autorisées, de la portée, qui détermine les ressources concernées. Pour Workers, une politique peut viser tous les Workers du compte ou seulement les ressources sélectionnées. Les quatre rôles organisent ensuite l’accès à l’observabilité, au code et au cycle de vie de l’application.

Consulter les métriques, journaux et traces : Metadata Read-Only. Ce rôle donne accès aux réglages et aux données d’observabilité du Worker sélectionné, mais pas à son code source ni aux valeurs de ses secrets.
Lire le code : Content Read-Only. Il ajoute l’accès au contenu du script sans permettre de le modifier ou de le déployer.
Déployer une nouvelle version : Editor. Il autorise la lecture, la modification, le renommage et le déploiement d’un Worker existant, ainsi que la gestion de ses versions, planifications et réglages. Il ne permet ni de créer ni de supprimer un Worker.
Supprimer le Worker sélectionné : Admin. Attribué à cette ressource, il permet sa suppression sans ouvrir automatiquement les autres Workers du compte.

Cette séparation réduit le rayon d’action d’un identifiant non humain : une erreur de pipeline ou l’exposition de son jeton reste limitée aux opérations et aux Workers inscrits dans la politique. Elle ne protège toutefois pas le Worker autorisé contre un déploiement erroné, puisque Editor conserve précisément le droit d’en modifier le code et la configuration.

Le jeton Editor ne couvre qu’un Worker déjà créé

La configuration prévue pour une chaîne CI/CD consiste à créer un jeton appartenant au compte, à sélectionner la portée « Specified Workers », puis à choisir le Worker et le rôle Editor. Une analyse indépendante en français confirme que cette combinaison permet de déployer un Worker existant sans droit de suppression ni accès aux autres applications, tant qu’aucune politique plus large ne vient étendre les permissions.

Cette portée ne peut pas servir à créer la ressource qu’elle doit désigner. La création d’un Worker exige donc Admin au niveau du produit Workers, tandis qu’Admin appliqué à un Worker existant suffit pour supprimer cette ressource précise. Une organisation peut ainsi séparer le provisionnement, qui porte sur l’ensemble du produit, des déploiements ordinaires de chaque application.

Les permissions s’additionnent lorsqu’un membre ou un jeton reçoit plusieurs politiques. Restreindre une nouvelle politique à un Worker ne neutralise donc pas un ancien droit Editor ou Admin portant sur tous les Workers. Le bénéfice annoncé suppose de retirer ou de réduire ces attributions plus larges.

Routes, domaines et services liés restent séparés

Editor suffit pour publier une nouvelle version tant que le déploiement ne modifie pas la manière dont le trafic atteint le Worker. Ajouter, modifier ou retirer une Route ou un Custom Domain demande aussi la permission Workers Routes Write pour chacune des zones concernées.

Un Worker déjà associé à KV, R2 ou D1 peut être déployé avec le seul rôle Editor. Des permissions propres à ces produits redeviennent nécessaires si l’automatisation doit agir directement sur leurs ressources, par exemple lire des clés KV, interroger une base D1 ou lister des objets R2. Les droits accordés au Worker ne se transforment donc pas en accès général à son stockage lié.

Les Durable Objects suivent une autre règle : ils n’ont pas de rôle ni de portée autonomes et héritent des permissions du Worker qui les implémente. La granularité annoncée concerne ainsi d’abord Workers ; Cloudflare prévoit d’étendre les contrôles par ressource à d’autres produits de sa Developer Platform.

Wrangler exige un jeton appartenant au compte

La principale contrainte opérationnelle concerne l’authentification. La documentation d’autorisation de Workers indique que le flux OAuth de wrangler login ne prend pas encore en charge ces permissions granulaires. Wrangler doit être authentifié avec un jeton API appartenant au compte, accompagné des variables CLOUDFLARE_API_TOKEN et CLOUDFLARE_ACCOUNT_ID.

Les commandes héritent alors du rôle et de la portée du jeton. wrangler tail demande au minimum Metadata Read-Only pour le Worker visé ; le déploiement d’un Worker existant requiert Editor ; une commande de déploiement visant un nom encore inexistant devient une opération de création et nécessite Admin au niveau du produit.

Cette distinction empêche de confondre l’autorisation accordée dans Cloudflare avec la méthode utilisée par l’outil local. Une session OAuth peut fonctionner pour d’autres usages de Wrangler, mais elle ne matérialise pas actuellement la restriction à un Worker : pour une chaîne CI/CD réellement bornée à cette application, le jeton appartenant au compte reste indispensable.

Une disponibilité générale, mais pas une migration forcée

Les contrôles par Worker sont déjà disponibles, et non annoncés comme une préversion. Les anciennes permissions Workers continuent néanmoins de fonctionner et aucune date de retrait n’est fixée. Les comptes peuvent donc faire coexister les deux modèles, au risque de conserver involontairement une autorisation historique plus large que le nouveau jeton.

Le changement répond désormais au cas précis d’un pipeline chargé d’une seule application : Editor lui permet de déployer sans supprimer, tandis que la portée individuelle l’empêche d’atteindre les Workers voisins. Ses frontières restent explicites : la création exige Admin au niveau du produit, les modifications de routage réclament des droits de zone supplémentaires et Wrangler doit utiliser un jeton appartenant au compte pour préserver la granularité.

Cloudflare Workers limite enfin un jeton CI/CD à une seule application