Права доступа Cloudflare Workers: безопасный деплой для клиента

Права доступа Cloudflare Workers теперь распределяются между четырьмя ролями, превращая единые учётные данные для деплоя в отдельную границу для каждого клиента. С 15 сентября 2026 года агентство может разрешить клиентскому CI-заданию развёртывать один уже существующий Worker, не давая ему права удаления или доступа ко всем остальным Workers в аккаунте — при условии, что более широкая политика не расширяет эти права.

Главное изменение — область доступа

У разрешения две составляющие. Роль определяет, что можно делать. Область доступа — где именно это можно делать.

Cloudflare теперь позволяет сочетать роль Worker с областью доступа к одному конкретному Worker для участника команды, User Group, агента или API-токена. Та же роль по-прежнему может охватывать все Workers, но теперь это необязательно.

На первый взгляд, это небольшое улучшение администрирования. Однако для студии или агентства, которое ведёт несколько клиентов в одном аккаунте Cloudflare, оно меняет саму передачу доступа: учётные данные для деплоя проекта клиента A можно ограничить только его Worker.

Обновление от 15 сентября доступно всем клиентам Cloudflare и работает через панель управления, API или Terraform.

Полный набор ролей из справочника ролей Workers:

Такое разделение полезно, потому что отладка, ревью кода, выпуск новой версии и удаление сервиса — четыре разные задачи. Для них не должны использоваться одни и те же учётные данные.

Прежние разрешения Cloudflare для Workers действовали на уровне аккаунта. Новую модель можно применять ко всей Developer Platform, ко всем Workers или к одному существующему Worker. Политика Workers на уровне продукта охватывает каждый текущий и будущий Worker. Политика на уровне отдельных Workers распространяется только на те из них, которые выбраны явно.

Есть одно архитектурное ограничение: нельзя настроить область доступа для Worker, которого ещё не существует. Для создания нового Worker по-прежнему нужна роль Admin на уровне продукта.

Как права доступа Cloudflare Workers меняют передачу проекта клиенту

Представим небольшое агентство, которое размещает по одному Worker для каждого клиента. Процессу деплоя нужно публиковать новые версии client-a-api. Создавать Workers, удалять этот Worker или обращаться к client-b-checkout ему незачем.

До этого обновления типичные CI-разрешения Workers, которые Cloudflare теперь помечает как устаревшие, действовали на уровне аккаунта. Оставалось два понятных варианта: принять чрезмерно широкие права или вынести клиента в отдельный аккаунт. Область доступа к отдельному Worker даёт третий вариант: сохранить структуру аккаунта, но выдать токену деплоя роль Editor только для client-a-api.

Стоимость подписки не меняется, поскольку управление на уровне Worker доступно всем клиентам. Зато меняется операционная модель.

В этой модели не учтён важный компромисс. Двенадцать наборов клиентских учётных данных с ограниченной областью доступа — это больше секретов для выпуска, хранения и ротации, чем один общий токен. Выигрыш не в том, что учётных данных становится меньше, а в том, что при сбое или утечке нужно проверять меньше проектов.

Основатель, который работает один, использует один Worker и никому не передаёт доступ к деплою, почти не заметит разницы. То же верно для команды, которая сознательно разрешает платформенной команде управлять всеми Workers. Изменение важно там, где несколько сотрудников, клиентов или автоматизированных заданий работают в одном аккаунте Cloudflare, но не должны разделять одну и ту же зону потенциального ущерба.

Как выдать процессу клиентского деплоя ровно столько прав, сколько нужно

Лучше всего начинать передачу с уже существующего Worker со стабильным Route или Custom Domain. Тогда заданию деплоя не придётся создавать Worker или менять домен.

1. 1

   Сначала опишите задачу, затем выбирайте роль

   Начните с одного предложения: «Этот процесс развёртывает новые версии существующего Worker client-a-api».

   Из этой формулировки следует роль Editor с областью доступа к отдельному Worker. Если процесс должен создавать новый Worker, ему требуется роль Admin на уровне продукта. Если нужно добавить, изменить или удалить Route либо Custom Domain, для каждой затронутой зоны также потребуется Workers Routes Write.

2. 2

   Создайте API-токен, принадлежащий аккаунту

   В Cloudflare откройте Manage Account > Account API Tokens и создайте токен, принадлежащий аккаунту. В качестве области доступа укажите Specified Workers, выберите client-a-api, а затем роль Editor.

   Для этого процесса используйте токен, принадлежащий аккаунту, а не личный пользовательский токен. Cloudflare позиционирует такие токены как сервисные учётные записи для долговечных интеграций, поэтому деплой не остановится после ухода создавшего токен сотрудника. Для создания или обновления такого токена нужны права Super Administrator.

3. 3

   Запустите Wrangler с этим токеном

   Сохраните токен в хранилище секретов системы деплоя. Cloudflare документирует для Wrangler следующие переменные окружения:

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

   Запускайте команду из настроенного проекта существующего Worker. wrangler login здесь не заменит токен, поскольку его OAuth-процесс пока не поддерживает детальную авторизацию.

4. 4

   Переключите деплой и удалите прежние широкие права

   Разверните через новый токен версию с безобидным изменением и убедитесь, что обновился нужный Worker. Проверьте, что у токена нет роли Workers на уровне продукта и области доступа к посторонним ресурсам.

   Затем удалите из этого процесса старый секрет с широкими правами. Сохранить оба набора учётных данных на время проверки разумно. Оставить оба после неё — значит свести новую границу доступа на нет.

На этом обычную передачу деплоя можно считать завершённой. Клиентское задание сможет обновлять, загружать, развёртывать, откатывать и переименовывать этот Worker, а также управлять его секретами: все эти действия входят в роль Editor. Удалить Worker оно не сможет, а политика на уровне одного Worker не откроет доступ к другим Workers.

Четыре задачи — четыре разумные политики

Агент поддержки, которому нужны только факты

Выдайте агенту отладки роль Metadata Read-Only для затронутого Worker. Он сможет изучать настройки, метрики, логи и трассировки, не читая исходный код и не меняя сервис.

Так процесс поддержки сможет собирать факты, не превращаясь незаметно в процесс ревью кода или деплоя. Этой же роли достаточно для wrangler tail на данном Worker.

Внешний разработчик, проверяющий клиентский проект

Выдайте подрядчику Content Read-Only для Worker клиента. Он сможет изучать развёрнутый исходный код и настройки, но не сможет менять или развёртывать его.

Так граница ревью становится понятнее. Нет необходимости выдавать Editor только потому, что проверяющему нужно разобраться в работающем коде.

CI-пайплайн отдельного клиента

Выдайте токену, принадлежащему аккаунту, роль Editor для одного существующего Worker. Он сможет публиковать и откатывать версии, но не удалять Worker и не обращаться к другим Workers.

Для передачи проекта агентством это самый подходящий вариант: учётные данные принадлежат процессу, а не сотруднику. Если для клиентских проектов также используются браузерные агенты, ограничения Cloudflare по разрешённым хостам решают другую часть задачи — определяют, куда разрешено обращаться браузеру. Это обновление определяет, какой Worker может менять учётная запись деплоя.

Владелец платформы, отвечающий за жизненный цикл

Оставьте Admin сотруднику или автоматизированному процессу, которому действительно нужно право удаления. Admin на уровне продукта должен оставаться у владельца, создающего Workers; готовый Worker затем можно передать политикам с более узкими повседневными правами.

Так появляется явное разделение между управлением жизненным циклом и обычной поставкой изменений. Заданию деплоя не нужны те же полномочия, что и специалисту, который создаёт и выводит из эксплуатации клиентские сервисы.

Граница стала уже, но полной изоляции нет

Главное преимущество вполне реально, однако формула «только один Worker» может стать опасным упрощением.

Durable Objects требуют такой же осторожности. У них нет собственных ролей или областей доступа: они наследуют права от Worker, в котором реализованы. Metadata Read-Only открывает метрики, логи и трассировки Durable Object без доступа к хранимым данным, но Editor также соответствует документированному уровню прав для запросов и изменения данных в Durable Object на базе SQLite через Data Studio.

Routes — ещё одна отдельная граница. Роли Editor достаточно для развёртывания новой версии, пока существующие Route или Custom Domain не меняются. Для изменения этой связи дополнительно требуется Workers Routes Write в каждой затронутой зоне. Cloudflare также сообщает, что Custom Domains пока не поддерживают роли на уровне отдельных Workers.

Наконец, разрешения Cloudflare складываются. Узкая прямая политика не отменяет широкую политику, унаследованную через User Group. В представлении Members видны прямые разрешения, а унаследованные групповые политики нужно проверять на вкладке Groups. Если пропустить эту проверку, экран может показывать нужную узкую политику, хотя фактический набор разрешений останется широким.

Кому стоит действовать сейчас

Стоит заняться этим уже на этой неделе, если в одном аккаунте размещено несколько клиентских Workers, а у сотрудника, агента или CI-задания всё ещё есть доступ ко всем Workers ради работы лишь с одним из них. Польза особенно заметна, когда Worker уже существует, а его доменные подключения не меняются при обычном деплое.

Не спешите сужать права токена, если процесс создаёт Workers, меняет Routes или Custom Domains либо напрямую обращается к подключённым хранилищам данных. Сначала сопоставьте этим действиям необходимые разрешения — иначе следующий деплой остановится на полпути.

Изменение вас не затронет, если доступ к Worker никогда не передаётся другим, используется только один Worker или деплоем намеренно управляет платформенная команда с ответственностью на уровне всего аккаунта.

Что сделать в понедельник

Начните с политики разрешений для CI-деплоя одного существующего клиента. Назначьте токену, принадлежащему аккаунту, роль Editor, ограничьте его одним Worker, перечислите все привязки и унаследованные Durable Objects, на которые он может влиять, проверьте прямые и групповые политики, а затем выполните деплой без изменения Route или Custom Domain.

Когда проверочный запуск пройдёт успешно, удалите старый секрет с доступом ко всем Workers. Одно такое переключение создаст реальную границу и даст шаблон, который можно повторить для следующего клиента.

Если вам нужны другие понятные практические разборы изменений платформ, подпишитесь на рассылку.