Предоставьте каждому участнику команды и агенту нужный уровень доступа к вашим Worker15.09.2026 13:00

Поскольку все больше команд —, а теперь и агентов — создают приложения на платформе разработки Cloudflare (Developer Platform), наличие правильных средств контроля доступа имеет решающее значение для безопасного развертывания. В конце концов, меньше всего вам хочется, чтобы агент внес изменения в продакшн просто потому, что ему предоставили больше прав, чем требуется.

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

Новые роли доступны уже сегодня для всех клиентов. Вы можете назначить их конкретному пользователю, чтобы при входе в панель управления он видел только тот Worker, к которому ему предоставлен доступ. Или вы можете создать токен API с ограниченной областью действия (scoped access) и передать его своему агенту, чтобы гарантировать, что у него есть доступ только к этому единственному приложению. 

Вот пример того, как создать токен API с разрешениями для конкретного Worker:  

Роли, созданные с учетом методов работы команд

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

Мы планируем использовать те же роли по мере внедрения средств контроля доступа на уровне ресурсов для других продуктов Developer Platform, включая D1, R2 и KV. Каждая роль может применяться на одном из трех уровней области видимости (scopes). Например, если вы установите параметр управления «metadata read-only» (только чтение метаданных), на разных уровнях это будет выглядеть следующим образом:  

• Уровень Developer Platform: доступ к метаданным для всех ресурсов платформы разработки.
• Уровень продукта: доступ к метаданным для каждого ресурса определенного продукта, например, каждого Worker.
• Уровень ресурса: доступ к метаданным для одного конкретного ресурса, например одного Worker.

Роль и область видимости определяют, что именно пользователь может делать и к каким ресурсам. Давайте посмотрим, как это выглядит в некоторых типичных рабочих процессах (воркфлоу) с Worker.

Отладка без раскрытия исходного кода

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

Роль Metadata Read-Only предоставляет им доступ к этой информации без раскрытия исходного кода Worker. Они могут выполнять запросы к аналитике через GraphQL API, получать доступ к логам, а также исследовать трассировки и другие данные наблюдаемости. Эти запросы возвращают данные только для тех Worker, к которым у них есть доступ. Если область действия агента ограничена одним Worker, он может использовать API Cloudflare для расследования проблемы, не видя данных ни одного другого Worker в учетной записи.

По мере внедрения этих ролей в другие продукты Developer Platform мы планируем сохранить такое разделение. Пользователь сможет проверять настройки и данные наблюдаемости для базы данных D1 или бакета R2, не имея возможности читать значения в базе данных или файлы в бакете.

Просмотр кода без возможности его изменения 

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

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

После добавления поддержки в другие продукты Developer Platform роль Content Read-Only будет работать аналогичным образом: пользователь сможет читать данные, хранящиеся в базе данных D1, пространстве имен KV или бакете R2, без возможности их изменения.

Развертывание силами CI без предоставления полного контроля

Рабочему процессу CI/CD нужен доступ только к тому приложению, которое он развертывает. У него не должно быть возможности изменять другой Worker или удалять собственный, переводя приложение в автономный режим.

Благодаря средствам контроля доступа на уровне Worker каждый рабочий процесс может иметь собственный токен API с ролью Editor, ограниченный одним Worker. Если рабочий процесс настроен неправильно или его токен скомпрометирован, масштаб последствий остается ограниченным: система может развернуть изменения для этого Worker, но не может удалить его или затронуть любое другое приложение в вашей учетной записи.

Удаление Worker с правами администратора (Admin)

Admin — это наивысший уровень доступа, который вы можете предоставить. Он позволяет удалять приложение. Вы по-прежнему можете ограничить эту роль отдельным Worker, чтобы доступ не распространялся на все остальные Worker в учетной записи.

Маршруты и пользовательские домены (Routes & Custom Domains) 

Вы можете добавлять маршруты (routes) или пользовательские домены (Custom Domains) к Worker, чтобы указать, какие хост-имена направляются в это приложение. Например, эта конфигурация в вашем файле Wrangler перенаправляет трафик для example.com на Worker:

{
  "route": {
    "pattern": "example.com/*",
    "zone_name": "example.com"
  }
}

Поскольку изменение такого маршрута может перенаправить продакшн-трафик или перевести приложение в автономный режим, доступа к самому Worker недостаточно. Чтобы добавить, изменить или удалить маршрут или пользовательский домен, вам необходимы как права Editor для Worker, так и разрешение Workers Routes для зоны.

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

Тем не менее, как только маршрут настроен, вы можете продолжать развертывание новых версий Worker без доступа к подключенной зоне или ресурсу, если развертывание не изменяет это подключение. Это позволяет вашей CI/CD-системе развертывать приложение, не предоставляя ей доступ к вашим доменам, базам данных или хранилищу.

Разрешения Workers распространяются на Durable Objects

Durable Objects не имеют собственных ролей или разрешений. Вместо этого доступ к Durable Object определяется вашим доступом к Worker, который его реализует. Чтобы предоставить кому-либо доступ к Durable Object, назначьте ему соответствующую роль для этого Worker.

Роль Metadata Read-Only дает им доступ к метрикам, логам и трассировкам Durable Object, но не к данным, хранящимся в объекте. Поскольку Durable Objects Data Studio может напрямую запрашивать и изменять эти сохраненные данные, для доступа к ним требуется роль Editor.

Более понятные ошибки, подсказывающие вам и вашим агентам необходимые разрешения

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

Вместо того чтобы возвращать только общий ответ 403 Forbidden, наши API теперь включают ссылку на соответствующую документацию API, где вы можете точно увидеть, какие разрешения необходимы для выполнения запроса. Таким образом, вы и ваш агент сможете определить правильный уровень доступа, не предоставляя избыточных привилегий.

Доступно уже сейчас

Средства контроля доступа на уровне Worker доступны для всех клиентов уже сегодня. Вы можете настроить их в панели управления Cloudflare, через API или с помощью Terraform.

Чтобы предоставить члену команды доступ к конкретному Worker, перейдите в раздел Manage Account > Members, выберите участника и создайте политику с нужной ролью и областью видимости Worker.

Управление доступом команд с помощью групп пользователей (User Groups)

Если нескольким людям из одной команды или проекта требуется одинаковый доступ, вы можете создать группу пользователей (User Group) вместо назначения разрешений каждому человеку по отдельности. Назначьте политику группе, а затем добавьте соответствующих участников. Все участники этой группы автоматически унаследуют эту политику.

Замена устаревших разрешений для Worker 

Ранее мы использовали следующие роли и разрешения для управления доступом к Worker. Теперь, когда мы внедряем единый набор ролей на всей платформе разработки (Developer Platform), мы рекомендуем использовать новые роли в дальнейшем.

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

Что дальше?  

Доступ на уровне Worker — это первый шаг к созданию более согласованной модели авторизации на всей платформе разработки Cloudflare.

В дальнейшем мы планируем перенести те же средства контроля доступа на уровне ресурсов на другие продукты Developer Platform, включая пространства имен KV и базы данных D1. Вместо предоставления доступа ко всем бакетам или базам данных в учетной записи вы сможете ограничить доступ конкретным ресурсом и связать эту область видимости с правильной ролью.

Те же роли, которые были представлены для Worker, будут применяться и к этим ресурсам.

Ознакомьтесь с нашей документацией для разработчиков, чтобы начать работу.

© Cloudflare Blog