С помощью этой инструкции вы добавите политики для правила.
Число политик, привязанных к правилу, не ограничено. К каждому правилу могут быть привязаны все доступные политики, но только по одной каждого типа.
Чтобы добавить политику:
Перейдите в окно создания шлюза, редактирования или создания правила.
Перейдите на шаг Политики.
Нажмите Добавить политику.
В окне Добавление политики выберите нужную политику.
Список доступных политик зависит от выбранного шаблона шлюза, если вы создаете политику в мастере создания шлюза, и наличия бэкенда.
Доступность политики в зависимости от шаблона шлюза и наличия бэкенда Политика
Обратный прокси с бэкендом
Обратный прокси без бэкенда
Container Apps с бэкендом
Container Apps без бэкенда
Mock-сервер
Для шлюза на основе шаблона «OpenAPI» политики указываются внутри спецификации.
Нажмите Создать.
Ограничение запросов
- Сценарий использования
- Поля для заполнения
Количество запросов — максимальное количество запросов, которое может быть обработано за указанный интервал.
Интервал времени, сек — время в секундах, в течение которого действует счетчик количества запросов. При достижении указанного значения, счетчик максимального количества запросов обнуляется.
Код ответа на отклоненный запрос — код ответа HTTP, который следует возвращать, когда запрос отклоняется из-за превышения лимита. Может быть установлен любой код ответа от 200 до 599. При отсутствии значения возвращается 503.
X-RateLimit-Limit — установленный в плагине лимит запросов.
X-RateLimit-Remaining — оставшееся количество запросов, которые могут быть приняты до обнуления счетчика.
Ограничить количество запросов, отправляемых по определенному URI в единицу времени, чтобы избежать DDoS-атаки.
Заголовки успешно выполненных запросов содержат следующую информацию:
Перезапись ответа
- Сценарий использования
- Поля для заполнения
Новый код ответа — код ответа HTTP, которым заменяется получаемый код. Может быть установлен любой код ответа от 200 до 599. При отсутствии значения код ответа не модифицируется.
Новое тело ответа — тело ответа, возвращаемое при перезаписи. При отсутствии значения тело ответа не модифицируется. Доступные значения: тело ответа в формате JSON и в виде текста в кодировке base64.
Заголовок — заголовок, который нужно модифицировать при возврате ответа. Добавить новую пару заголовка и значения можно кнопкой Добавить заголовок.
Значение — значение, которое будет передано в соответствующем заголовке при возврате ответа. Добавить новую пару заголовка и значения можно кнопкой Добавить заголовок.
Изменить информацию, получаемую в ответе от целевого хоста: набор заголовков, код ответа или тело ответа.
Кеширование запросов
- Сценарий использования
- Поля для заполнения
Перечень кодов ответа — коды ответов HTTP, при которых следует кешировать ответы. Оставьте поле пустым, если требуется кешировать все ответы.
Время жизни кеша, сек — время (в секундах), в течение которого кешированный ответ следует удалить при отсутствии повторных запросов.
Кешировать ответы от целевого хоста в течение определенного интервала времени и возвращать ответы из кеша. Это позволяет снизить нагрузку на целевой хост.
Авторизация по API-ключам
- Сценарий использования
- Порядок действий
Запрашивать аутентификацию по API-ключу при отправке запросов к шлюзу. Доступ предоставляется пользователям, которые в качестве способа авторизации используют API-ключ.
Для авторизации можно использовать статические API-ключи.
Для авторизации на бэкенде по API-ключу необходимо указать API-ключ в заголовке авторизации, например:
X-API-KEY: <Key Secret>
где <Key Secret> — секрет API-ключа.
В параметрах API-ключа должен быть указан сервис Cloud.ru, который используется в качестве бэкенда.
Если не подключен ни один способ авторизации, будет обработан запрос любого неавторизованного пользователя к шлюзу API.
Авторизация через IAM-токен
- Сценарий использования
Запрашивать аутентификацию при отправке запросов к шлюзу. Доступ предоставляется пользователям, которые в качестве способа авторизации используют IAM-токен.
Для авторизации можно использовать как персональный IAM-токен, так и токен сервисного аккаунта.
Если не подключен ни один способ авторизации, будет обработан запрос любого неавторизованного пользователя к шлюзу API.
Совместное использование ресурсов (CORS)
Политика для реализации механизма доступа к ресурсам другого домена (Cross-Origin Resource Sharing).
Поля для заполнения
Источники — список источников через запятую, для которых разрешен CORS. Формат указания одного источника: scheme://host:port. Например: https://mydomain.com:8080.
Если опция Разрешить credentials выключена, можно включить CORS для всех источников, указав в поле значение *.
HTTP-методы — список HTTP-методов через запятую, для которых разрешен CORS. Примеры значений: POST, GET.
Если опция Разрешить credentials выключена, можно включить CORS для всех методов, указав в поле значение *.
Заголовки запроса — список заголовков запроса через запятую, разрешенных при доступе к CORS-ресурсу.
Если опция Разрешить credentials выключена, можно включить CORS для всех всех заголовков запросов, указав в поле значение *.
Заголовки ответа — список заголовков ответа через запятую, разрешенных при доступе к CORS-ресурсу.
Если опция Разрешить credentials выключена, можно включить CORS для всех заголовков, указав в поле значение *.
Разрешить credentials — разрешить включать в запросы credentials (например, cookies). Если опция Разрешить credentials включена, то нельзя использовать маску * в остальных полях создания политики.
Защита от сбоев (Circuit Breaker)
- Сценарий использования
- Поля для заполнения
Код ответа на отклоненный запрос — код ответа шлюза при попытке подключения к целевому бэкенду в период автоматического отклонения запросов. Допустимое значение от 200 до 599.
Макс. время работы режима отклонения запросов, сек — время в секундах, в течение которого работает Circuit Breaker.
Коды ошибок сервера — коды ошибок от целевого бэкенда. Допустимое значение от 500 до 599. Если поле не заполнено, то автоматическое отклонение запросов включается при получении от целевого бэкенда ответов с кодом 500 в количестве, указанном в поле Количество неуспешных запросов.
Коды успешной обработки запроса — коды успешного ответа от целевого бэкенда. Допустимое значение от 200 до 499. Если поле не заполнено, при получении от целевого бэкенда ответов с кодом 200 в количестве, указанном в поле Количество успешных запросов, бэкенд считается работоспособным и мониторинг запросов прекращается.
Количество неуспешных запросов — количество последовательных неуспешных попыток подключения к целевому бэкенду, при достижении которого бэкенд считается неработоспособным и включается автоматическое отклонение запросов.
Количество успешных запросов — количество последовательных успешных попыток подключения к целевому бэкенду, при достижении которого бэкенд считается работоспособным и мониторинг запросов прекращается.
Автоматически отклонять API-запросы в случае недоступности целевого бэкенда при достижении заданного числа ошибок, возвращаемых бэкендом. Это позволит избежать постоянных повторных запросов от клиента к бэкенду в случае сбоя.
Шаблон Circuit Breaker работает по принципу разрыва соединения в случае ошибки, чтобы избежать каскадного сбоя приложений.
Пример конфигурации плагина:
В приведенном выше примере конфигурации автоматическое отклонение запросов работает следующим образом.
При получении от бэкенда ответа с кодом 503 включается мониторинг запросов — сервис начинает считать успешные и неуспешные коды ответов от бэкенда.
Если приходит три подряд ответа с кодом 503, то бэкенд считается неработоспособным и включается режим автоматического отклонения запросов. Режим включается на 2 секунды, после чего запросы к бэкенду повторяются.
Если от бэкенда снова поступает ответ с кодом 503, то время автоматического отклонения запросов увеличивается вдвое (4 секунды). Так происходит при каждом последующем получении ответа с кодом 503. При этом время работы режима отклонения запросов не может превышать указанное в поле Макс. время работы режима отклонения запросов, сек.
Запросы к бэкенду повторяются каждый раз после окончания времени работы режима отклонения запросов. Сервис продолжает считать запросы, пока не получит от бэкенда два раза подряд код ответа 200. Тогда бэкенд снова считается работоспособным и мониторинг запросов прекращается до следующего получения кода ответа 503.
Сервис считает только успешные и неуспешные коды ответа от бэкенда — 2хх и 5хх. Например, три подряд неуспешных ответа могут быть представлены следующими последовательностями:
«503 — 503 — 503»
«503 — 403 — 503 — 503»
«503 — 404 — 403 — 503 — 503»
Пример двух подряд успешных ответов:
«200 — 200»
«200 — 403 — 200»
«200 — 403 — 401 — 200»
При этом, если после ответа с кодом 200 пришел ответ 503, то количество успешных ответов обнуляется и счет начинается заново при получении следующего успешного ответа.
Маршрутизация запросов
- Сценарий использования
- Поля для заполнения
Исходный адрес — URI, при запросе на который будет использоваться политика маршрутизации запросов. Например, /route1/. Подробнее о URI — в разделе Концепции.
Целевой адрес — URI целевого хоста, на который будет машрутизирован запрос. Например, /confident_route1/. Подробнее о URI — в разделе Концепции.
Заголовок — заголовок, который будет добавлен к запросу при маршрутизации запроса к целевому хосту. Если запрос уже содержит этот заголовок, он будет перезаписан из поля Значение. Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок. Заголовок указывать необязательно.
Значение — значение, которое будет передано в соответствующем заголовке при маршрутизации запроса к целевому хосту. Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок.
Скрыть путь для обращения к сервису на целевом хосте по соображениям безопасности. Пользователь должен отправлять запросы на URI /route1/, а использоваться должен URI /confident_route1/.
Вы можете добавить несколько пар «заголовок-значение».
Mock API
- Сценарий использования
- Поля для заполнения
Тип ответа — выбор формата ответа при обращении к Mock API:
Текст — Mock-сервер будет отправлять текст в теле ответа. Введите текст для отправки.
JSON — Mock-сервер будет отправлять JSON-объект в теле ответа. Добавьте в JSON-редактор фрагмент кода в формате JSON.
Тело ответа — текст или JSON-объект, возвращаемый в ответ на запрос.
Создать по одному из путей заглушку API для тестирования проекта. Заглушка отдает указанный ответ на запрос по данному URI вместо ответа от целевого хоста.