Создайте безопасный API-шлюз, который может обрабатывать параметры запроса и данные формы (загрузки файлов) и пересылать их в соответствующие облачные функции.
Все мы любим API. Все, что вам нужно или вы хотите из Интернета, есть вероятность, что для этого есть API или вы сможете его создать. Вот что мы сделали. В нашей организации мы создали API почти для всех задач, которые можно было передать на серверы. Но тогда у нас было слишком много API. Итак, нам понадобился какой-то сервис для выполнения двух важных задач для наших API:
- Создайте общий шлюз для всех связанных API, чтобы триггеры API были структурированными, универсальными и легко управляемыми.
- Сделайте публично открытые API более безопасными.
Поскольку все наши API-интерфейсы размещены на GCP, было естественно, что мы выбрали Google API Gateway. Теперь давайте посмотрим, как Google Cloud API Gateway решил наши проблемы.
Предпосылки
Я предполагаю, что у вас будут готовы следующие ресурсы. Если нет, то прилагаются ссылки, которые помогут вам начать работу:
- Аккаунт GCP с активированным биллингом. Если у вас его еще нет, вы можете создать новый, используя уровень бесплатного пользования за 300 долларов.
- Проект GCP
- Google Cloud Functions (я использую облачные функции Google, но вы также можете использовать App Engine и Cloud Run).
Шлюз API можно настроить с помощью спецификации OpenAPI 2.0. Прежде чем мы сможем приступить к написанию фактического файла конфигурации API, нам нужно будет включить следующие службы, чтобы мы могли развернуть шлюз.
Мы также можем включить эти службы с помощью консоли GCloud, используя следующие команды:
Шлюз API состоит из 2 компонентов:
- Конфигурация API: конфигурация API, созданная при загрузке определения API. Мы создадим определение API как спецификацию OpenAPI. Каждый раз, когда мы загружаем определение API, API Gateway создает новую конфигурацию API. То есть мы можем создать конфигурацию API, но не можем позже изменить ее. Если мы позже отредактируем определение API в спецификации OpenAPI, а затем загрузим отредактированное определение API, мы создадим новую конфигурацию API.
- Шлюз: высокопроизводительный масштабируемый прокси-сервер на основе Envoy, на котором размещается развернутая конфигурация API. Когда мы развертываем конфигурацию API на шлюзе, он создает внешний URL-адрес, который наши клиенты API используют для доступа к API.
Шлюзы развертываются в конкретном регионе GCP (регион - это конкретный географический регион на GCP, где мы можем развертывание ресурсов).
На шлюзе также должна быть размещена конфигурация API. Мы не можем создать пустой шлюз, т.е. для всех шлюзов требуется конфигурация API, однако она может поддерживать только одну конфигурацию API для каждого шлюза. Однако после создания шлюза мы можем обновить его, чтобы заменить одну конфигурацию API на другую.
Создание шлюза и конфигурации API:
Теперь, когда мы закончили с теорией, перейдем к самой захватывающей части, а именно к написанию фактического файла спецификации OpenAPI для API Gateway. Это просто для создания API Config. Если вы хотите знать, как настроить шлюз, который будет хранить этот файл конфигурации, просто следуйте инструкциям, приведенным здесь.
Итак, давайте сначала создадим базовый файл спецификации, который просто пересылает запрос в зависимости от пути:
Теперь, когда мы с этим закончили. Вот часть, с которой я боролся. Теперь у меня была облачная функция, в которой мне нужно было передать 2 параметра запроса и 1 данные формы (изображение). Итак, давайте сначала займемся передачей параметров запроса. В следующем смысле я создаю новый путь, который передает наши параметры:
Теперь последняя часть загрузки файла изображения через form-data. Что ж, это на удивление самая простая часть, поскольку шлюз API делает это автоматически. Любые прикрепленные данные автоматически пересылаются.
Обеспечение безопасности API:
Это еще один аспект, который для нас очень важен. Большинство наших API были общедоступными. Мы, конечно, могли бы сделать их частными и использовать токены Google JWT для аутентификации, но токены JWT недолговечны, и мы не хотели проходить процесс создания нового каждые несколько часов для множества устройств и приложения, в которых мы использовали наши API.
Введите ключи API, которые генерируются вручную, и один ключ можно использовать на шлюзе для проверки на соответствие всем API, связанным в шлюзе. Есть и другие способы верификации (JWT, Firebase, Auth0, Okta, Google Id tokens), но это то, чем мы занимаемся.
Теперь, если вы хотите узнать, как сгенерировать ключи API, просто следуйте приведенной здесь документации.
После того, как мы сгенерировали ключи API, мы можем использовать их либо как параметры запроса, либо как параметры заголовка для аутентификации.
Используйте API-ключ в нашем приложении, минуя его с параметром key = API_KEY для параметра запроса или x-api-key = API_KEY для параметров заголовка.
Это потребует от нас изменения файла конфигурации API.
Это последняя конфигурация API. Кроме того, не забудьте заблокировать вызовы без аутентификации в наших облачных функциях, иначе не будет смысла защищать API.
Теперь, если мы нажмем наш API и получим ошибку типа «PERMISSION_DENIED: API не включен для проекта», нам нужно будет сделать следующее:
- Перейдите в API и службы.
- Нажмите ВКЛЮЧИТЬ APIS И УСЛУГИ в верхней части экрана.
- Найдите имя нашего шлюза.
- Включите API
И мы закончили настройку нашего шлюза.
Когда я начал работать над API-шлюзом, я обнаружил, что это интересный и потенциально очень мощный сервис, но не хватало подробной документации, поэтому и эта статья. Я надеюсь, что вам понравится этот сервис.
Спасибо за внимание! Поделитесь этой статьей, если вы нашли ее полезной.
Пожалуйста, хлопайте 👏, чтобы проявить немного любви :)
Давай подружимся в LinkedIn, GitHub.
