Cloudflare объявила о предоставлении средств управления доступом для каждого Worker, благодаря чему пользователю, программному агенту или API-токену можно разрешить взаимодействие с конкретным приложением без доступа к остальным ресурсам аккаунта. Нововведение сопровождается четырьмя новыми ролями для платформы разработчиков, предназначенными для разделения мониторинга приложения, чтения его содержимого, его изменения и полного администрирования.
Средства управления доступны всем клиентам с 15 сентября 2026 года; настроить их можно через панель управления Cloudflare, API или Terraform. Их также можно применять к отдельному пользователю или User Group, чтобы все участники группы наследовали одну и ту же политику.
Четыре уровня разрешений
- Metadata Read-Only: позволяет просматривать списки ресурсов, их настройки и данные мониторинга, такие как метрики, журналы и трассировки, без доступа к содержимому продукта или коду. Подходит для расследования сбоев, когда чтение исходного кода не требуется.
- Content Read-Only: позволяет читать содержимое продукта, например код Worker или содержимое базы данных D1, без изменения или публикации изменений.
- Editor: позволяет читать и записывать содержимое, а также обновлять настройки, но не разрешает создавать или удалять ресурсы. Cloudflare предлагает эту роль как подходящий вариант для систем CI/CD, которым требуется публиковать изменения в определённом Worker.
- Admin: предоставляет полный контроль над ресурсом, включая создание, переименование, удаление и предоставление доступа другим пользователям; при этом это разрешение можно ограничить одним Worker вместо всего аккаунта.
Что меняется на практике?
Операционная команда может предоставить инженеру или агенту роль Metadata Read-Only для проверки настроек, метрик, журналов и трассировок без раскрытия кода. Аналогично агент сможет проверять код с помощью Content Read-Only, не имея возможности публиковать его или изменять настройки приложения.
В конвейерах CI/CD можно создать API-токен с ролью Editor и ограничить его одним Worker. Если конвейер будет неправильно настроен или токен окажется раскрыт, его возможности останутся ограничены публикацией изменений для этого приложения, без возможности удалить Worker или изменить другие приложения в аккаунте. Cloudflare поясняет, что эти разрешения применяются на трёх уровнях: ко всей платформе разработчиков, к определённому продукту, например Workers, или к конкретному ресурсу, например одному Worker.
Важные ограничения области действия и подключений
Одного доступа к Worker недостаточно для добавления, изменения или удаления Route или Custom Domain. Для этих операций требуется разрешение Editor для Worker, а также отдельное разрешение Workers Routes для зоны. Такое разделение позволяет управлять направлением трафика к приложению без предоставления более широких прав на настройки домена.
После настройки маршрута система CI/CD может продолжать публиковать новые версии, если публикация не изменяет существующее подключение, и без доступа к связанным доменам, базам данных или хранилищам. Durable Objects также используют разрешения Worker, который их выполняет: роль Metadata Read-Only предоставляет доступ к их метрикам, журналам и трассировкам, но не позволяет читать хранящиеся в них данные. Для доступа к Data Studio, которая может запрашивать и изменять данные, требуется роль Editor.
Сообщения об ошибках и прежние версии
Cloudflare обновила ответы API при отклонении операций: теперь они не ограничиваются общей ошибкой 403 Forbidden, а содержат ссылку на документацию, в которой указано необходимое разрешение. Это должно помочь пользователям и агентам точно настраивать права вместо их случайного расширения.
Компания рекомендует перейти на новые роли вместо прежних разрешений Workers, однако не объявила дату их отключения; существующие назначения будут продолжать работать до отдельного предварительного уведомления. Cloudflare планирует расширить ту же модель на другие продукты, включая D1, R2 и KV, чтобы доступ можно было ограничивать конкретной базой данных или отдельным хранилищем.
Чтение certi.news
Фактическое изменение заключается не просто в добавлении новой административной роли, а в переносе контроля с уровня аккаунта или продукта на уровень ресурса, с чётким разделением данных мониторинга, содержимого и выполнения. Это особенно важно для команд, использующих программных агентов или автоматизированные конвейеры развёртывания, поскольку ошибку или утечку токена можно локализовать в пределах одного Worker. В то же время управление маршрутами и доменами по-прежнему требует отдельного разрешения, а поддержка D1, R2 и KV пока указана как последующий план, а не как уже доступная функция. Сохранение прежних разрешений без объявленной даты их вывода из эксплуатации означает, что организациям потребуется постепенно пересматривать свои политики, а не предполагать немедленный переход.