Cloudflare объявила о запуске Cloudflare Access for Workers — набора инструментов, позволяющего напрямую привязать политику Access к Worker-приложению или ко всем приложениям Workers в аккаунте. Благодаря такой привязке приложения по умолчанию оказываются за входом в систему компании, без необходимости полагаться на то, что каждый разработчик отдельно не забудет настроить средства контроля доступа.
Этот шаг предпринимается на фоне того, что сотрудники с помощью инструментов искусственного интеллекта могут быстрее создавать и развёртывать приложения. Cloudflare считает, что такая скорость также может привести к случайной публикации внутренних приложений или частных данных в общем интернете, поэтому компания разработала новые инструменты так, чтобы защита приложений, размещённых на Workers, стала частью самого процесса развёртывания.
Защита приложения независимо от способа доступа
При включении Access для Worker Cloudflare требует аутентификацию до того, как любой запрос достигнет кода приложения. Это действует независимо от того, получает ли пользователь доступ к приложению через пользовательский домен, путь, поддомен workers.dev или адрес предварительного просмотра.
Ранее Access настраивался на уровне имени хоста, поэтому для каждого домена, через который пользователь мог получить доступ к Worker, требовалось создавать отдельные политики. Добавление нового пользовательского домена требовало предварительно обновить политику; в противном случае этот домен становился доступным без аутентификации. Теперь политика привязывается к самому Worker, благодаря чему связанные с ним домены и URL-адреса автоматически защищаются.
Область защиты можно выбрать в зависимости от потребностей:
- Защита только адресов предварительного просмотра, включая адреса workers.dev или пользовательские домены, используемые для предварительных просмотров.
- Защита всех имён хостов, связанных с приложением, включая пользовательские домены, пути, домены workers.dev и адреса предварительного просмотра.
Политика по умолчанию на уровне аккаунта
Команды, управляющие большим количеством приложений Workers, могут один раз настроить политику Access на уровне аккаунта. В таком случае все существующие и будущие приложения становятся частными с момента создания, при этом можно указать, будет ли политика охватывать трафик адресов предварительного просмотра, производственный трафик или оба вида трафика.
Вариант только для предварительных просмотров может подходить приложениям, которые должны оставаться общедоступными в производственной среде, но при этом не раскрывать разрабатываемые версии. Cloudflare также позволяет переопределить политику аккаунта для конкретного Worker-приложения, если оно должно быть общедоступным.
Тем, кому не нужна всеобъемлющая политика, можно напрямую применить Access к одному Worker. Новая вкладка Access в интерфейсе Worker показывает политики, действующие для приложения. При наличии нескольких политик приоритет имеет наиболее конкретная политика в следующем порядке: политики имени хоста, затем политики Worker, затем политики аккаунта.
Идентификация пользователя внутри кода приложения
Access также позволяет узнать личность пользователя, отправляющего каждый запрос к приложению, включая его электронную почту, имя и группы. Cloudflare заявляет, что эти данные можно использовать для персонализации содержимого, применения разрешений или регистрации активности каждого пользователя.
Информация об идентификации появляется в объекте контекста ctx Worker, а именно через ctx.access. Приложение может вызвать ctx.access.getIdentity(), чтобы получить данные аутентифицированного пользователя, без необходимости вручную выполнять проверку JSON Web Token, например анализировать токен, проверять его подпись и извлекать утверждения.
Access поддерживает подключение существующего поставщика удостоверений организации, а также позволяет ограничивать доступ по определённым адресам электронной почты, почтовым доменам или группам. Для агентов доступ можно предоставлять с помощью сервисных токенов.
Локальное тестирование и внутренние платформы
Проверять поведение идентификации локально можно с помощью wrangler dev, добавив настройку Access в файл wrangler.jsonc для имитации аутентифицированного пользователя. Благодаря этому разработчик может менять адрес электронной почты в настройках и проверять отображение подходящего содержимого для каждого пользователя до развёртывания.
Cloudflare также представила пример внутренней платформы с открытым исходным кодом, которая позволяет публиковать статические сайты методом перетаскивания, при этом каждый опубликованный Worker по умолчанию является частным. Эта архитектура использует Workers for Platforms, где трафик приложений внутри пространства имён проходит через один распределённый Worker. При размещении политики Access на этом Worker приложения, опубликованные через него, по умолчанию становятся частными.
Доступность и техническая архитектура
Функция стала доступна всем пользователям через панель управления; для начала работы также предоставлена документация Cloudflare Access for Workers. Новая возможность основана на FL2 — модульном промежуточном прокси, созданном с использованием Rust и работающем на периферийной инфраструктуре Cloudflare.
Чтобы включить Access на уровне Worker, а не имени хоста, Cloudflare отделила маршрутизацию Workers от их выполнения и перенесла логику маршрутизации на этап, предшествующий Access. Компания объясняет, что модульная система FL2 с определёнными модулями и упорядоченными этапами помогла управлять этим изменением: каждая часть стабильно объявляет свои входные и выходные данные, что позволило использовать компилятор для обнаружения некорректных взаимодействий между этапами во время реструктуризации.