С помощью этой инструкции вы добавите политики для правила.
Число политик, привязанных к правилу, не ограничено. К каждому правилу могут быть привязаны все доступные политики, но только по одной каждого типа.
Чтобы добавить политику:
Перейдите в окно создания шлюза, редактирования или создания правила.
Перейдите на шаг Политики.
Нажмите Добавить политику.
В окне Добавление политики выберите нужную политику.
Список доступных политик зависит от выбранного шаблона шлюза, если вы создаете политику в мастере создания шлюза, и наличия бэкенда.
Доступность политики в зависимости от шаблона шлюза и наличия бэкенда Политика
Обратный прокси с бэкендом
Обратный прокси без бэкенда
Container Apps с бэкендом
Container Apps без бэкенда
Mock-сервер
Для шлюза на основе шаблона «OpenAPI» политики указываются внутри спецификации.
Нажмите Создать.
Ограничение запросов
Чтобы избежать DDoS-атаки, вводят ограничение количества запросов, отправляемых по определенному URI в единицу времени.
Для настройки ограничения количества запросов заполните поля:
Количество запросов — максимальное количество запросов, которое может быть обработано за указанный интервал.
Интервал времени, сек — время в секундах, в течение которого действует счетчик количества запросов. При достижении указанного значения, счетчик максимального количества запросов обнуляется.
Код ответа на отклоненный запрос — код ответа HTTP, который следует возвращать, когда запрос отклоняется из-за превышения лимита. Может быть установлен любой код ответа от 200 до 599. При отсутствии значения возвращается 503.
Заголовки успешно выполненных запросов содержат следующую информацию:
X-RateLimit-Limit — установленный в плагине лимит запросов.
X-RateLimit-Remaining — оставшееся количество запросов, которые могут быть приняты до обнуления счетчика.
Перезапись ответа
Политика используется для изменения информации, получаемой в ответе от целевого хоста: набор заголовков, код ответа или тело ответа.
Чтобы настроить перезапись ответов, заполните поля:
Новый код ответа — код ответа HTTP, которым заменяется получаемый код. Может быть установлен любой код ответа от 200 до 599. При отсутствии значения код ответа не модифицируется.
Новое тело ответа — тело ответа, возвращаемое при перезаписи. При отсутствии значения тело ответа не модифицируется. Доступные значения: тело ответа в формате JSON и в виде текста в кодировке base64.
Заголовок — заголовок, который нужно модифицировать при возврате ответа. Добавить новую пару заголовка и значения можно кнопкой Добавить заголовок.
Значение — значение, которое будет передано в соответствующем заголовке при возврате ответа. Добавить новую пару заголовка и значения можно кнопкой Добавить заголовок.
Кеширование запросов
Политика используется для кеширования ответов от целевого хоста в течение определенного интервала времени и возвращения ответов из кеша. Это позволяет снизить нагрузку на целевой хост.
Чтобы настроить кеширование запросов, заполните поля:
Перечень кодов ответа — коды ответов HTTP, при которых следует кешировать ответы. Оставьте поле пустым, если требуется кешировать все ответы.
Время жизни кеша, сек — время (в секундах), в течение которого кешированный ответ следует удалить при отсутствии повторных запросов.
Авторизация
Настройка доступа пользователей к шлюзам. Если политика не настроена, все пользователи, у которых есть адрес шлюза, имеют к нему доступ.
Авторизация по API-ключам
Для доступа к шлюзу пользователь должен авторизоваться. Перед авторизацией запрашивается аутентификация по API-ключу. Доступ предоставляется пользователям, которые в качестве способа авторизации используют API-ключ.
Для авторизации можно использовать статические API-ключи.
Чтобы авторизоваться на бэкенде по API-ключу, необходимо указать API-ключ в заголовке авторизации, например:
X-API-KEY: <Key Secret>
где <Key Secret> — секрет API-ключа.
В параметрах API-ключа должен быть указан сервис Cloud.ru, который используется в качестве бэкенда.
Авторизация через IAM-токен
Для доступа к шлюзу пользователь должен:
авторизоваться;
иметь права на доступ к этому шлюзу.
Доступ предоставляется пользователям, которые в качестве способа авторизации используют IAM-токен.
Для авторизации можно использовать как персональный IAM-токен, так и токен сервисного аккаунта.
Авторизация через OpenID Connect
Для доступа к шлюзу пользователь должен авторизоваться. Доступ предоставляется пользователям, которые в качестве способа авторизации используют учетные записи сторонних приложений и сервисов.
Перед настройкой политики настройте возможность авторизации на стороннем сервисе или приложении через IdP (Identity Provider) по стандартному протоколу OpenID Connect и получите там значения:
ClientID;
Секрет;
URL конфигурации провайдера.
Значения ClientID и Секрет нужно внести в сервис Secret Management.
Для настройки авторизации заполните поля:
Client ID — идентификатор стороннего приложения или сервиса. Значение идентификатора выбирается из доступных в сервисе Secret Management.
Секрет — секрет, сформированный сторонним приложением или сервисом при настройке авторизации. Значение серета выбирается из доступных в сервисе Secret Management.
URL discovery — URL конфигурации провайдера.
Редирект — URI, куда будет перенаправлен пользователь после успешной авторизации. Например: /callback.
Bearer only — требование передачи токена в заголовке запроса. Если опция Bearer only включена, то токен всегда будет передаваться в заголовке, даже после прохождения авторизации в рамках одной сессии.
Базовая авторизация
Для доступа к шлюзу пользователь должен авторизоваться. Доступ предоставляется пользователям, которые в качестве способа авторизации используют пару логин-пароль, которая создана в сервисе API Gateway в разделе Пользователи.
Совместное использование ресурсов (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)
Политика настраивается, чтобы автоматически отклонять API-запросы в случае недоступности целевого бэкенда при достижении заданного числа ошибок, возвращаемых бэкендом. Это позволит избежать постоянных повторных запросов от клиента к бэкенду в случае сбоя.
Шаблон Circuit Breaker работает по принципу разрыва соединения в случае ошибки, чтобы избежать каскадного сбоя приложений.
Чтобы настроить защиту от сбоев, заполните поля:
Код ответа на отклоненный запрос — код ответа шлюза при попытке подключения к целевому бэкенду в период автоматического отклонения запросов. Допустимое значение от 200 до 599.
Макс. время работы режима отклонения запросов, сек — время в секундах, в течение которого работает Circuit Breaker.
Коды ошибок сервера — коды ошибок от целевого бэкенда. Допустимое значение от 500 до 599. Если поле не заполнено, то автоматическое отклонение запросов включается при получении от целевого бэкенда ответов с кодом 500 в количестве, указанном в поле Количество неуспешных запросов.
Коды успешной обработки запроса — коды успешного ответа от целевого бэкенда. Допустимое значение от 200 до 499. Если поле не заполнено, при получении от целевого бэкенда ответов с кодом 200 в количестве, указанном в поле Количество успешных запросов, бэкенд считается работоспособным и мониторинг запросов прекращается.
Количество неуспешных запросов — количество последовательных неуспешных попыток подключения к целевому бэкенду, при достижении которого бэкенд считается неработоспособным и включается автоматическое отклонение запросов.
Количество успешных запросов — количество последовательных успешных попыток подключения к целевому бэкенду, при достижении которого бэкенд считается работоспособным и мониторинг запросов прекращается.
Пример конфигурации плагина:
В приведенном выше примере конфигурации автоматическое отклонение запросов работает следующим образом.
При получении от бэкенда ответа с кодом 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 /confident_route1/.
Для маршрутизации запросов заполните поля:
Исходный адрес — URI, при запросе на который будет использоваться политика маршрутизации запросов. Например, /route1/. Подробнее о URI — в разделе Концепции.
Целевой адрес — URI целевого хоста, на который будет машрутизирован запрос. Например, /confident_route1/. Подробнее о URI — в разделе Концепции.
Заголовок — заголовок, который будет добавлен к запросу при маршрутизации запроса к целевому хосту. Если запрос уже содержит этот заголовок, он будет перезаписан из поля Значение. Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок. Заголовок указывать необязательно.
- Значение — значение, которое будет передано в соответствующем заголовке при маршрутизации запроса к целевому хосту.
Добавить новую пару заголовка и значения можно при помощи кнопки Добавить заголовок.
Вы можете добавить несколько пар «заголовок-значение».
Mock API
При настройке политики по одному из путей создается заглушка API для тестирования проекта. Заглушка отдает указанный ответ на запрос по URI вместо ответа от целевого хоста.
Чтобы настроить политику, заполните поля:
Тип ответа — выбор формата ответа при обращении к Mock API:
Текст — Mock-сервер будет отправлять текст в теле ответа. Введите текст для отправки.
JSON — Mock-сервер будет отправлять JSON-объект в теле ответа. Добавьте в JSON-редактор фрагмент кода в формате JSON.
Тело ответа — текст или JSON-объект, возвращаемый в ответ на запрос.