Конечные точки облака, предоставляют роли ключам API, чтобы ограничить некоторые методы / пути (например, роли чтения / записи)

Question

Фон

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

Пример

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

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

Исследование

Я видел похожий пост . В принятом ответе предлагалось два решения:

• Использование Auth0 и программная проверка авторизации пользователя Мне нужно отслеживать использование моих конечных точек API для каждого ключа API. Более того, безопасности ключей API для моего случая достаточно.

• Ключи API Мне удалось ограничить свои ключи API для доступа к API Cloud Endpoints, однако я не вижу возможности разрешить только доступ к моему ключу некоторые пути API Cloud Endpoints.

Я также считаю, что такая услуга, как Apigee , может делать то, что мне нужно, но у меня небольшой бюджет (PO C), поэтому я не думаю, что это услуга для меня, и я бы предпочел использовать только продукты GCP.

Вопрос

Предлагает ли Cloud Endpoints готовое решение для моего использования кейс ? Если да, что мне делать?

Если нет, можно ли:

• создать другой прокси-сервер с помощью облачных функций, который будет проверять по базе данных Firestore, ключу API разрешен доступ к запрошенному методу? Лог c будет выглядеть следующим образом: Пользовательский запрос с предоставленным Google ключом API -> Утверждение конечных точек облака -> Утверждение настраиваемой функции прокси -> выполнение микросервиса

• Настройте ESP в соответствии с моими вариант использования

• Самостоятельно управлять всей аутентификацией API (кажется, много работы)

Answer 1

TL; DR: это невозможно с Cloud Endpoint

Есть несколько вещей и ограничений, которые нужно знать с Cloud Endpoint:

• Cloud Endpoint выполняет аутентификацию, а не авторизацию. Короче говоря, проверьте, действительны ли ваши учетные данные пользователя (auth0, OAuth2, Firebase auth, API Key).
  • Только для ключа API: вы можете ограничить ключ одним или несколькими URL-адресами службы. Затем здесь вы можете ограничить API-ключ только одной Cloud Endpoint, если хотите.
• API-ключи «аутентифицируют» проект GCP, а не пользователя или учетную запись .
  • Если вы создаете 2 ключа в одном проекте, вы не сможете различать инициатора запроса -> Вам необходимо создать 1 проект для каждого клиента и сгенерировать ключ API для каждого проекта
• (относится к предыдущему пункту) Ключи API не могут быть созданы автоматически скриптом. Вы должны выполнить это действие на консоли вручную (и если у вас есть много клиентов, которых нужно зарегистрировать, или если вы хотите зарегистрироваться автоматически c, это будет сложно)
  • Почему ?? Google не рекомендует использовать API-ключ для аутентификации и не рекомендует использовать этот король шкафчиков

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

Вы также можете реализовать свой собственный процесс авторизации (и даже свой собственный API Генерация ключа, это просто строка в конце!), Более сложный ...