15 сентября 2026 года Cloudflare добавила более точное управление доступом к Workers. Теперь права можно выдавать не только на весь продукт или аккаунт, но и на конкретный Worker, а для людей, AI-агентов и CI/CD доступны четыре отдельных роли.
Изменение особенно полезно там, где деплой и диагностика уже частично автоматизированы. Вместо одного широкого API-токена для всех сценариев можно разделить чтение логов, просмотр кода, публикацию новой версии и административные операции.
Что именно изменилось в Cloudflare Workers
Cloudflare ввела четыре роли для Workers: Metadata Read-Only, Content Read-Only, Editor и Admin. Их можно назначать участникам команды, User Groups и API-токенам, а область действия ограничивать отдельными Workers.
| Роль | Что разрешено | Типичный сценарий |
|---|---|---|
| Metadata Read-Only | Настройки, метрики, логи и traces без доступа к исходному коду | Диагностика и observability-агент |
| Content Read-Only | Чтение кода и метаданных без изменения и deploy | Code review, аудит и анализ ошибок |
| Editor | Чтение, изменение и deploy существующего Worker без удаления | CI/CD и автоматический выпуск версий |
| Admin | Полное управление в пределах выданного scope, включая удаление | Администратор приложения |
Официальная документация отдельно уточняет, что scope и роль работают вместе. Например, Editor можно выдать только одному конкретному Worker, а не всем приложениям аккаунта.
Почему это важно для AI-агентов
AI-агенту редко нужен полный административный доступ. Агент диагностики может анализировать логи и метрики, но ему не обязательно видеть исходный код. Агент code review может читать код, но не должен иметь возможность заменить production-версию. Агент, выполняющий deploy после одобренного изменения, может получить Editor только на нужный Worker.
Такой подход соответствует принципу least privilege: каждому автоматическому участнику дают только те права, которые необходимы для конкретной операции. Если токен попадёт не туда или сценарий выполнит неверное действие, область возможного ущерба остаётся ограниченной.
Практическая схема доступа
- НаблюдениеАгент получает Metadata Read-Only для логов, metrics и traces
- ПроверкаCode review получает Content Read-Only и не может менять Worker
- DeployCI/CD получает Editor только для нужного приложения
- АдминистрированиеAdmin остаётся у ограниченного числа ответственных
- АудитПрава и токены периодически пересматриваются
Главный принцип: не выдавать автоматизации доступ ко всему аккаунту, если её задача относится к одному Worker.
Scoped API token для CI/CD
Для CI/CD Cloudflare рекомендует account-owned API token. Теперь его можно ограничить Specified Workers и ролью Editor. Такой токен сможет обновлять и разворачивать выбранный Worker, но не получит доступ к другим приложениям в аккаунте и не сможет удалить Worker.
Это полезно для GitHub Actions, GitLab CI, собственного deploy-сервиса и агентных пайплайнов. Один общий токен с широкими правами лучше заменить несколькими узкими токенами по назначению.
Если Worker использует Routes или Custom Domains, одного Editor может быть недостаточно. Документация Cloudflare указывает, что для изменения routes или custom domains дополнительно требуется Workers Routes Write для соответствующей зоны. Это важно учитывать при проектировании автоматического deploy.
Что происходит с bindings, D1, KV и R2
Право развернуть Worker и право напрямую читать связанные ресурсы — не одно и то же. Cloudflare указывает, что Editor позволяет deploy Worker с bindings, но прямой доступ к данным KV, D1 или R2 требует соответствующих разрешений на сами ресурсы.
Это полезное разделение. CI/CD может опубликовать новую версию приложения, не получая одновременно право просматривать содержимое базы или объектного хранилища.
Durable Objects наследуют доступ Worker
Durable Objects не имеют собственного независимого набора ролей. Их доступ определяется правами на Worker, который реализует объект. Для просмотра observability достаточно Metadata Read-Only, а операции с данными через Data Studio требуют более высокого уровня.
Если архитектура использует несколько Workers с разными Durable Objects, это ещё один аргумент не выдавать один общий административный токен на весь продукт.
Где granular permissions особенно полезны
- AI-агент анализирует production-логи и предлагает исправление;
- отдельный агент проверяет код перед merge;
- CI/CD публикует один Worker после успешных тестов;
- подрядчик работает только с одним приложением клиента;
- несколько команд используют один Cloudflare account;
- production и внутренние сервисы должны иметь разные контуры доступа.
Что granular permissions не решают автоматически
Новые роли снижают риск избыточных прав, но не заменяют полноценную модель безопасности. API-токен всё равно нужно хранить как секрет, ограничивать время жизни и область использования там, где это возможно, не выводить в логи и не передавать модели в prompt.
Также нужно отдельно контролировать права GitHub/GitLab, секреты CI, доступ к внешним API и процессы одобрения production-deploy. Узкий Cloudflare token не поможет, если злоумышленник получил полный доступ к репозиторию или другому секрету, который даёт более широкие возможности.
Чек-лист для безопасного Worker deploy
- Для каждого процесса определена минимальная необходимая роль
- CI/CD token ограничен конкретным Worker, если ему не нужны остальные
- Агенты чтения не имеют Editor/Admin без необходимости
- Admin не используется для обычного deploy
- Routes и Custom Domains имеют отдельные права только там, где они реально нужны
- Секреты не попадают в prompt, код и workflow logs
- У каждого токена понятное назначение и владелец
- Права пересматриваются после изменения архитектуры или команды
Как это связано с бизнес-автоматизацией
Когда Worker выступает API-шлюзом, webhook-приёмником или промежуточным сервисом между CRM, сайтом и AI, права доступа становятся частью архитектуры автоматизации. Ошибка в одном deploy-процессе не должна давать ему возможность менять соседние приложения.
Для таких проектов полезно отдельно проектировать автоматизацию бизнес-процессов, AI-автоматизацию и защищённые API-интеграции, а не добавлять секреты и права по мере появления новых сценариев.
Частые вопросы
Можно ли дать AI-агенту доступ только к одному Worker?
Да. Cloudflare позволяет выбрать scope Individual Workers и назначить подходящую роль конкретному участнику, группе или API-токену.
Какая роль нужна CI/CD для deploy?
Для обновления и deploy существующего Worker подходит Editor. Удалять Worker эта роль не позволяет.
Нужен ли Admin для Wrangler deploy?
Для обычного deploy существующего Worker Admin не требуется. При работе с granular permissions Cloudflare рекомендует аутентификацию через account-owned API token; OAuth-поток wrangler login пока не поддерживает granular authorization.
Может ли Content Read-Only изменить код?
Нет. Эта роль предназначена для чтения содержимого Worker и метаданных без изменения или deploy.
Получает ли Editor доступ к данным R2 или D1 через binding?
Deploy Worker с binding возможен, но прямой доступ к содержимому привязанного ресурса требует отдельных прав на этот ресурс.
Официальные источники
- Cloudflare Blog — Give every teammate and agent the right level of access to your Workers
- Cloudflare Changelog — Granular Worker permissions
- Cloudflare Docs — Workers roles and permissions
- Cloudflare Docs — Roles and permissions
Если Workers уже используются для webhooks, API или AI-автоматизации, можно прислать текущую схему доступа и отдельно разобрать, какие токены стоит разделить и где достаточно read-only роли.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.