Что такое политики API Gateway?

С развитием облачных технологий и микросервисной архитектуры роль API-шлюзов как порталов для трафика становится все более важной. API-шлюзы в основном отвечают за прием запросов и их перенаправление на соответствующие вышестоящие сервисы. Политики API-шлюзов определяют логику и правила управления трафиком, что напрямую влияет на поведение бизнес-трафика.

Что такое политики API-шлюзов

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

1. Проверяет, является ли запрос легальным. Например, не исходит ли он от пользователя из списка запрещенных.
2. Проверяет, аутентифицирован ли запрос и авторизован ли доступ к запрашиваемому контенту.
3. Проверяет, не нарушает ли запрос определенные ограничительные правила, такие как лимиты на количество запросов.
4. Определяет, на какой вышестоящий сервис следует перенаправить запрос.

После этой серии шагов запрос либо отклоняется, либо успешно достигает указанного вышестоящего сервиса. Эти правила обработки мы называем политиками API-шлюза. Эти правила постоянно добавляются администратором шлюза во время его работы. Шлюз принимает эти правила и выполняет соответствующие действия по обработке трафика.

На примере API-шлюза Apache APISIX можно выделить два типа конфигурационной информации: файл конфигурации для запуска шлюза, например, config.yaml, который определяет необходимые настройки для нормального запуска шлюза. Кроме того, администраторы могут динамически создавать различные правила и конфигурации через Admin API во время работы, такие как Route, Consumer, Plugin и т.д. Политики API-шлюза — это различные правила и конфигурации, которые администратор динамически создает через Admin API.

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

Политика аутентификации и авторизации

Аутентификация позволяет подтвердить личность вызывающего API, а авторизация ограничивает доступ вызывающего только к ресурсам в пределах его полномочий.

Например, если пассажир отправляется на вокзал, он использует свой паспорт для "аутентификации", чтобы подтвердить свою личность перед входом на вокзал. После входа на вокзал он показывает свой билет сотруднику для подтверждения и получает "авторизацию" на посадку в конкретный поезд. Основная цель политик аутентификации и авторизации — убедиться, что все запросы, перенаправляемые на вышестоящие сервисы, являются легальными, и что запросы имеют доступ только к ресурсам в пределах своих полномочий. Некоторые стандартные политики включают:

Basic Auth

Политика Basic Access Authentication — это самый простой метод контроля доступа. Обычно HTTP-запрос пользователя содержит заголовок для аутентификации, который выглядит так: Authorization: Basic <credentials>, где credentials включают идентификатор пользователя и пароль, разделенные :. Этот метод не требует сложных настроек, таких как страницы входа и куки. Аутентификация основана на простой информации в заголовке запроса, обычно это имя пользователя и пароль, что делает его простым в настройке и использовании.

Пример запроса cURL с базовой аутентификацией, где username и password:

curl -i -u 'username:password' http://127.0.0.1:8080/hello

Следует отметить, что информация в credentials не шифруется при передаче, а только кодируется в base64, поэтому обычно требуется использовать HTTPS для обеспечения безопасности пароля.

После реализации этой политики в шлюзе запросы без учетных данных не будут перенаправляться, если только в запросе не будет указана правильная информация для аутентификации. Эта политика реализует проверку доступа к API с минимальными затратами.

Key Auth

Политика Key Auth ограничивает вызовы API путем добавления ключей к API и использования ключей для контроля доступа к ресурсам. Только запросы с правильным ключом, который может быть указан в заголовке запроса или в параметрах запроса, могут получить доступ к ресурсам. Обычно этот ключ также используется для различения разных вызывающих API, чтобы можно было применять разные политики или контроль ресурсов для разных вызывающих. Как и в случае с базовой аутентификацией, ключ не шифруется, поэтому важно использовать HTTPS для обеспечения безопасности.

На примере плагина key-auth в APISIX, плагин требует создания Consumer с уникальным значением ключа через Admin API:

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

Этот запрос создает Consumer с именем jack и ключом jack-key.

При включении плагина в маршруте необходимо настроить местоположение и имя поля ключа в запросе. По умолчанию местоположение — header, а имя поля — apikey, поэтому правильный запрос для этого маршрута будет выглядеть так:

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

Когда APISIX получает этот запрос, он извлекает ключ и сопоставляет его с Consumer jack из всех настроенных ключей. Таким образом, шлюз узнает, что запрос был отправлен пользователем jack. Если ключ не найден, запрос считается нелегальным.

JSON Web Token

JSON Web Token (JWT) — это открытый стандарт, который определяет способ безопасной передачи информации между сторонами в виде JSON-объектов. Политика JWT может объединять аутентификацию и авторизацию. После авторизации пользователя ему передается JWT-токен, который вызывающий будет использовать во всех последующих запросах, чтобы подтвердить авторизацию.

В API-шлюзе аутентификацию JWT можно добавить через политику JWT. Это позволяет отделить логику аутентификации от бизнес-кода, и разработчики могут сосредоточиться на реализации бизнес-логики. На примере плагина jwt-auth в APISIX, плагин должен быть включен и настроен в Consumer с уникальным ключом, публичным и приватным ключами для шифрования, алгоритмом шифрования, временем истечения токена и т.д. Также необходимо включить этот плагин в маршруте и настроить шлюз для чтения местоположения и полей токена, таких как заголовок, параметры запроса, куки и т.д. Этот плагин добавляет API в API-шлюз для выдачи токенов. Перед отправкой запроса необходимо запросить API, который выдает токен. При отправке запроса токен должен быть указан в указанном месте в соответствии с конфигурацией. Когда запрос достигает шлюза, шлюз считывает токен из указанного места и проверяет его валидность. Если проверка успешна, запрос перенаправляется на вышестоящий сервис.

По сравнению с предыдущими двумя стратегиями, политика JWT включает возможность установки времени истечения срока действия. Выданный токен может истечь через определенное время, в то время как срок действия Basic Auth и Key Auth является постоянным, если только сервер не изменит пароль или ключ. Кроме того, политика JWT может быть использована между несколькими сервисами, что полезно для сценариев единого входа (SSO).

OpenID Connect

OpenID Connect — это метод аутентификации и авторизации, основанный на протоколе OAuth2.0, который предоставляет относительно полное решение для приложений. Политика OpenID Connect в API-шлюзе позволяет вышестоящему сервису получать информацию о пользователе от поставщика идентификации (IdP), тем самым защищая безопасность API. Распространенными IdP являются Keycloak, Ory Hydra, Okta, Auth0 и т.д. На примере Apache APISIX, рабочий процесс политики OpenID Connect в шлюзе выглядит следующим образом:

1. Клиент отправляет запрос в шлюз.
2. После получения запроса шлюз отправляет запрос на аутентификацию в IdP.
3. Пользователь будет перенаправлен на страницу, предоставленную IdP, для завершения аутентификации.
4. IdP перенаправляет обратно в шлюз с кодом аутентификации.
5. Шлюз запрашивает Access Token у IdP через код, чтобы получить информацию о пользователе.
6. Шлюз может передавать информацию о пользователе при перенаправлении запроса на вышестоящий сервис.

Этот процесс позволяет отделить аутентификацию и авторизацию от бизнес-логики, делая архитектуру более модульной.

Для получения дополнительной информации о методах аутентификации и авторизации в APISIX, пожалуйста, обратитесь к API Gateway Authentication.

Политика безопасности

Политика безопасности API-шлюза действует как страж, обеспечивая безопасный доступ к API, позволяя легальным запросам проходить через шлюз и блокируя нелегальные запросы. Согласно OWASP API Security Project, существует множество возможных угроз и атак на вызывающих API. Использование политики безопасности API-шлюза позволяет выполнять проверку безопасности для всех запросов API, что играет важную роль в защите API от этих угроз.

Ниже приведены несколько важных политик безопасности API-шлюза:

Ограничения доступа по IP

Политика ограничения доступа по IP ограничивает доступ определенных клиентов к API, устанавливая определенные IP-адреса или CIDR в белом или черном списке, чтобы запретить злонамеренный доступ к чувствительным данным. Правильная настройка этой политики значительно повышает безопасность API и позволяет улучшить управление безопасностью API.

Блокировка URI

Политика блокировки URI перехватывает потенциально опасные запросы API, устанавливая определенные правила для URI. Например, некоторые атаки на безопасность обнаруживают потенциальные уязвимости, сканируя путь URI, а затем атакуют. Apache APISIX предоставляет плагин uri-blocker для блокировки опасных запросов API. Можно также настроить регулярные выражения через плагин uri-blocker. API-шлюз заблокирует запрос, если он соответствует правилу. Например, если мы настроим root.exe, admin, этот плагин может блокировать запросы */root.exe и */admin, чтобы дополнительно защитить безопасность API.

CORS

CORS (Cross-origin resource sharing) — это политика безопасности браузера для кросс-доменных запросов. Обычно перед отправкой xhr-запроса в браузере, браузер проверяет, находится ли адрес запроса и текущий адрес в одном источнике. Запросы в пределах одного источника отправляются напрямую. В противном случае браузер сначала отправляет OPTION-запрос для предварительной проверки кросс-доменного запроса. В заголовке ответа будут указаны настройки, связанные с CORS, такие как разрешенные методы и учетные данные для кросс-доменных запросов. Браузер решает, отправлять ли официальный запрос, на основе этой информации. Подробнее см. CORS.

Обычно ответ с настройками CORS устанавливается серверной службой. Но если сервисов много, будет безопаснее и удобнее обрабатывать их на уровне шлюза. Политика CORS может устанавливать разные политики разрешения кросс-доменных запросов для разных API, и вышестоящие сервисы больше не должны обрабатывать эту логику.

CSRF

CSRF — это атака на подделку межсайтовых запросов, которая заставляет конечных пользователей выполнять непроизвольные действия на сайте, где они уже аутентифицированы. Эта атака обычно сопровождается социальной инженерией (отправка злонамеренной ссылки жертве по электронной почте). Когда пользователь нажимает на ссылку, злоумышленник использует аутентифицированную личность жертвы для выполнения атакующих действий на сайте. С точки зрения сайта, любое поведение ожидаемо, так как пользователь уже вошел в систему.

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

Политика обработки трафика

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

Ограничение скорости

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

Мы можем настроить временное окно и максимальное допустимое количество запросов в политике ограничения скорости. API-шлюз будет отклонять запросы, превышающие максимальное допустимое количество, и возвращать сообщение об ошибке ограничения скорости. Запрос не будет разрешен, пока количество запросов не станет меньше лимита или не откроется следующее временное окно.

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

Разрыв цепи

Политика разрыва цепи API может предоставить возможность разрыва цепи для вышестоящих сервисов. При использовании этой политики необходимо установить коды состояния здоровых и нездоровых вышестоящих сервисов, чтобы шлюз мог судить о состоянии вышестоящих сервисов. Кроме того, необходимо установить порог запросов для срабатывания разрыва или восстановления здоровья. Когда вышестоящий сервис постоянно возвращает нездоровые коды состояния шлюзу, шлюз разрывает цепь вышестоящего сервиса на некоторое время. В течение этого периода шлюз больше не будет перенаправлять запросы на вышестоящий сервис, а сразу возвращать ошибку. Это может предотвратить "лавину" запросов на вышестоящий сервис из-за ошибок и защитить бизнес-сервисы. После этого периода шлюз попытается снова перенаправить запрос на вышестоящий сервис. Если он все еще возвращает нездоровый код состояния, шлюз продолжит разрыв цепи на более длительное время (удвоенное). Пока вышестоящий сервис не вернет определенное количество здоровых кодов состояния, шлюз считает, что вышестоящий сервис восстановился, и продолжит перенаправлять трафик на вышестоящий узел.

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

Разделение трафика

Политика разделения трафика может динамически контролировать перенаправление трафика на разные вышестоящие сервисы в пропорции. Это полезно в канареечных выпусках и сине-зеленых развертываниях.

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

Сине-зеленый выпуск — это другой режим выпуска, который позволяет выпускать новую версию в пиковый период без прерывания сервиса. Обе версии сервиса сосуществуют. Обычно производственная среда (синяя) копируется в идентичный, но отдельный контейнер (зеленый). Новые обновления выпускаются в зеленую среду, а затем обе среды выпускаются в производство. Зеленая среда может быть протестирована и исправлена, пока пользователь все еще имеет доступ к синей системе. Затем запросы могут быть перенаправлены в зеленую среду с использованием некоторой политики балансировки нагрузки. Синяя среда может быть оставлена в качестве резервной для восстановления после сбоев или для следующего обновления.

APISIX поддерживает оба выпуска через плагин traffic-split, что делает бизнес-развертывание более удобным и надежным.

Перезапись ответа

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

APISIX предоставляет плагин Response Rewrite для изменения тела или заголовков ответа, возвращаемых вышестоящими сервисами, и поддерживает добавление или удаление заголовков ответа, установку правил для изменения тела ответа и т.д. Это полезно в сценариях, таких как установка заголовков CORS для кросс-доменных запросов или установка местоположения для перенаправления.

С другой стороны, APISIX предоставляет proxy-rewrite для перезаписи запросов. Этот плагин также может обрабатывать содержимое запроса, проксируемого на вышестоящий сервис. Вы можете переписать URI запроса, метод, заголовок запроса и т.д., что предоставляет удобство для бизнес-обработки во многих сценариях.

Инъекция ошибок

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

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

Преобразование протоколов

Политика преобразования протоколов может преобразовывать между некоторыми стандартными протоколами, такими как HTTP-запросы и gRPC. Apache APISIX предоставляет плагин grpc-transcode, который может транскодировать и перенаправлять HTTP-запрос на сервисы типа gRPC. Ответ возвращается клиенту в формате HTTP. Таким образом, клиент может сосредоточиться только на HTTP, не обращая внимания на тип вышестоящего gRPC.

Политика наблюдаемости

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

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

• Команда инженеров может отслеживать и устранять проблемы API.
• Команда продукта может понять использование API, чтобы обнаружить бизнес-ценность за ним.
• Команды продаж и роста могут отслеживать использование API, следить за бизнес-возможностями и обеспечивать, чтобы API предоставляли правильные данные.

Политики наблюдаемости обычно делятся на три категории в зависимости от типа выходных данных: Tracing, Metrics и Logging.

Tracing

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

Политика Tracing может интегрировать другие системы отслеживания распределенных вызовов в API-шлюз для сбора и записи информации. Например, интеграция сервисов, таких как Zipkin и SkyWalking, в API-шлюз для сбора данных и межсервисной коммуникации. Таким образом, эта политика позволяет инженерам знать, какой журнал просматривать для конкретной сессии или связанных вызовов API, и проверять область устранения неполадок.

Metrics

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

Политика Metrics может интегрировать сервисы, такие как Prometheus или Datadog, в API-шлюз для предоставления мониторинга и возможностей оповещения для системы. Эта политика собирает данные во время работы шлюза через различные интерфейсы API-шлюза и отправляет данные в Prometheus или Datadog. Визуализируя эти данные, разработчики могут видеть состояние работы шлюза, статистическую информацию о запросах API и другие статистические графики.

Logging

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

Политика Logging может хранить логи в API-шлюзе на диске сервера или отправлять их на другие серверы логов, такие как HTTP-сервер логов, TCP-сервер логов, UDP-сервер логов и т.д., или другие системы логов, такие как Kafka, RocketMQ, Clickhouse.

Итог

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

Для получения дополнительной информации о API-шлюзах, пожалуйста, посетите блоги и API7.ai для получения коммерческой поддержки.