← Cloudflare Workers / workers / configuration

Cloudflare Access

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

Можно защитить:

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

Чтобы использовать Access с Workers, вам потребуется:

• Zero Trust включён в вашем аккаунте. Если Zero Trust не включён, выполните Настройка Zero Trust сначала, а затем вернитесь в панель управления Workers.
• Разрешение на управление Workers и приложениями Access.

Требуйте вход на каждом Worker в вашем аккаунте, включая Workers, которые вы развернёте в будущем. Вход можно требовать только для preview-развёртываний либо одновременно для продакшен- и preview-развёртываний.

Путь в Dashboard: Workers & Pages страница обзора > Защита всех Workers.

1. На панели управления Cloudflare перейдите к разделу Workers & Pages страницу.

   Перейдите в Workers & Pages ↗

2. Найдите Защита всех Workers карточка.

3. Если на карточке указано Не включено, выберите Включите Access.

4. Выберите Только предпросмотры или Весь трафик.

5. В разделе Политика аутентификации, выберите существующую политику или настройте одну из параметры политики.

6. Выберите Включите Access.

7. (Необязательно) Проверьте длительность сессии.

   

8. Выберите Применить Access.

Чтобы защитить только предварительные развёртывания для каждого Worker, создайте локально размещённое приложение Access с all_preview_workers назначения:

"destinations": [
  {
    "type": "all_preview_workers"
  }
]

Чтобы защитить продакшен и предварительные развёртывания каждого Worker, используйте all_workers вместо этого:

"destinations": [
  {
    "type": "all_workers"
  }
]

Отправьте эти destinations в POST /accounts/{account_id}/access/apps запрос. Полную схему запроса, включая параметры политики, настройки сессии и дополнительные параметры Access см. API приложений Access.

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

Путь в Dashboard: Workers & Pages > выберите Worker > Доступ.

1. На панели управления Cloudflare перейдите к разделу Workers & Pages страницу.

   Перейдите в Workers & Pages ↗

2. Выберите свой Worker из списка приложений.

3. Выберите Доступ на вкладке.

4. Выберите Защита этого Worker через Access.

5. Выберите Только предпросмотры или Весь трафик.

6. В разделе Политика аутентификации, выберите существующую политику или настройте одну из параметры политики.

7. (Необязательно) Проверьте длительность сессии.

   

8. Выберите Применить Access.

Чтобы защитить только предварительные развёртывания для одного Worker, создайте локально размещённое приложение Access с preview_worker назначения. Укажите worker_id к идентификатору вашего Worker:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "type": "self_hosted",
    "name": "Access for my-worker",
    "destinations": [
      {
        "type": "preview_worker",
        "worker_id": "c81a2d22c29840ed9d61681a3270dbff"
      }
    ],
    "policies": [
      {
        "decision": "allow",
        "include": [
          {
            "email_domain": {
              "domain": "example.com"
            }
          }
        ]
      }
    ]
  }'

Чтобы защитить продакшен и предварительные развёртывания Worker, используйте worker вместо этого:

"destinations": [
  {
    "type": "worker",
    "worker_id": "c81a2d22c29840ed9d61681a3270dbff"
  }
]

Полную схему запроса, включая параметры политики и настроек сессии см. API приложений Access.

Используйте Access на основе имени хоста, если авторизация должна требоваться только для определённого URL, ведущего к вашему Worker, например для workers.dev хост, Custom Domain, поддомен или путь. Access на основе хоста защищает только этот конкретный URL, тогда как защита Worker защищает весь Worker независимо от способа обращения к нему. Например, при использовании Access на основе имени хоста вы можете защитить my-worker.example.workers.dev, admin.example.com, либо один путь, например example.com/login чтобы сделать закрытой только часть своего Worker.

И в панели управления, и через API защита имени хоста или пути настраивается созданием приложение с самостоятельным хостингом и используя имя хоста или путь в качестве домена приложения.

Если Access на уровне аккаунта защищает все Workers, вы можете сделать конкретный Worker публичным, добавив обход (bypass) на уровне Worker. Обход означает, что Access не требует входа в систему для этого Worker.

Путь в Dashboard: Workers & Pages > выберите Worker > Доступ.

1. На панели управления Cloudflare перейдите к разделу Workers & Pages страницу.

   Перейдите в Workers & Pages ↗

2. Выберите свой Worker из списка приложений.

3. Выберите Доступ на вкладке.

4. Выберите опцию, чтобы сделать Worker публичным или обойти Access на уровне аккаунта.

5. Подтвердите изменение.

Создайте Access-приложение на уровне Worker с политикой обхода. Используйте worker назначения укажите worker_id к идентификатору вашего Worker и задайте политику decision к bypass с include правило, которое соответствует всем:

"policies": [
  {
    "decision": "bypass",
    "include": [
      {
        "everyone": {}
      }
    ]
  }
]

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

Можно добавить одну или несколько политик. Войти смогут посетители, соответствующие любой из выбранных политик.

Для расширенной настройки политик, например нескольких провайдеров идентификации, правил device posture, service tokens, сложного порядка политик или пользовательских страниц входа и блокировки, отредактируйте приложение Access в Zero Trust после его создания. Полный список параметров см. в Политики доступа.

Когда Cloudflare Access аутентифицирует запрос, который напрямую обращается к вашему Worker, Worker может прочитать данные вошедшего в систему пользователя, включая email, группы, состояние устройства и дополнительные поля идентификации : через ctx.access. Дополнительная настройка или разбор JWT не требуются.

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

ctx.access это undefined если Access не аутентифицировал запрос.

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Access required", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Access required", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

При локальной разработке с wrangler dev или Cloudflare Vite Plugin, вы можете имитировать аутентифицированные удостоверения Cloudflare Access, не выполняя развёртывание и не проходя процесс входа Access.

Добавьте dev блок внутри access конфигурацию в вашем wrangler.jsonc:

{
	"access": {
		"dev": {
			"aud": "my-app",
			"identity": { "email": "[email protected]" }
		}
	}
}

[access.dev]
aud = "my-app"

  [access.dev.identity]
  email = "[email protected]"

• aud (обязательно): тег Audience вашего Access-приложения, доступный как ctx.access.aud. Wrangler не запустится без этого.
• identity (необязательно): имитирует утверждения о личности аутентифицированного пользователя (email, имя, группы и так далее), возвращаемые ctx.access.getIdentity(). Включайте его, если ваш Worker считывает данные о личности пользователя. Не указывайте его, если Worker только проверяет, включён ли Access.

Чтобы протестировать от имени другого пользователя, измените поля идентификации и перезапустите. Чтобы протестировать неаутентифицированные запросы, удалите dev блок: ctx.access будет undefined, так же как для запроса, который не проходил через Access в продакшене.

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Not authenticated", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Not authenticated", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

При такой конфигурации переход по localhost:8787 вернёт Hello, [email protected].

Объект identity принимает любые поля, соответствующие форме production Access identity. Полный список приведён в Application token: удостоверение пользователя.

Worker может быть защищен несколькими правилами Access. Если к одному запросу может применяться несколько правил, в первую очередь действует наиболее специфичное правило:

1. Access на основе имени хоста или пути: Применяется первым, если запрос соответствует этому имени хоста или пути, например admin.example.com или example.com/login.
2. Access на уровне Worker: Применяется далее для выбранного Worker по всем его маршрутам, Custom Domains, workers.dev хост и превью.
3. Доступ к Worker на уровне аккаунта: Применяется последним как запасной вариант для всех Worker или всех предпросмотров Worker в аккаунте.

Например, если у Worker есть и Access на уровне аккаунта, и правило на уровне Worker, то именно правило на уровне Worker управляет этим Worker. Если также существует соответствующее приложение Access, основанное на hostname или path, то именно это правило для hostname или path управляет соответствующим URL.

Если вы удалите более специфичное правило, Worker может остаться защищённым более общим правилом. Например, удаление Access на уровне Worker может открыть Access на уровне аккаунта, действующий под ним.

• API приложений Access
• Политики доступа
• Локально размещённые приложения Access
• Маршруты и домены
• Preview URLs