Блог

Сценарий

Я размещаю API в Cloud Run (grpc, но вопрос также будет касаться http), который я хочу защитить. Цель состоит в том, чтобы предоставить доступ к нескольким приложениям в нашей организации. Обратите внимание, что у каждого приложения есть несколько экземпляров, запущенных в другом месте (по одному для каждого внешнего клиента). API предназначен только для внутреннего использования и не будет напрямую доступен веб-браузерам.

Опции

Я определил следующие параметры:

1. Не используя конечные точки облака: Я могу просто сделать свой API закрытым и защищенным учетной записью службы. Токены на предъявителя (идентификационные токены) могут быть автоматически сгенерированы в приложении.
2. Конечные точки облака ключи API: для каждого приложения я генерирую ключ API, который используется всеми экземплярами этого приложения. это очень легко настроить, поскольку для этого просто требуется отправка дополнительного заголовка.
3. Конечные точки облака самозаверяющий jwt: я использую учетную запись службы для создания самозаверяющего токена (см. Документацию GCP по взаимодействию между службами) и настраиваю конечную точку с помощью этой учетной записи службы. Несколько приложений получают либо свою собственную учетную запись службы, либо я генерирую новые ключи из одного и того же. Обратите внимание, что самоподписывание токена доступно не во всех библиотеках и требует некоторой ручной работы. Следовательно, обновление токена также выполняется вручную.
4. Конечные точки облака Google ID: это обеспечивает только аутентификацию, без авторизации. Это также означает, что каждый, у кого есть учетная запись Google, может получить доступ к моему API (!). Преимущество заключается в том, что есть простой инструмент для генерации токенов ID.
5. Конечные точки облака ключ API идентификатор Google
6. Облачные конечные точки ключ API самоподписанный jwt

Вопросы

1. Какой вариант наиболее рекомендуется для моего сценария? (другие варианты / предложения приветствуются)
2. Вариант 1 обычно считается безопасным? Если да, то зачем вообще беспокоиться о конечных точках Cloud?
3. В документации Google упоминаются различные формы аутентификации (см. Документацию GCP о методах аутентификации). Однако, похоже, что некоторые из них являются авторизацией (например, ключи API и учетные записи служб), а некоторые — аутентификацией (например, идентификаторы Google). Правильная ли это оценка?
4. Я предполагаю, что GCP понимает, что 3 имеет дело с учетными записями служб, и он может проверить их по-своему; невозможно, чтобы кто-то без ключа для учетной записи службы мог получить доступ.
5. В варианте 3: я бы подумал, что лучше использовать несколько учетных записей служб, по одной для каждого приложения и, предпочтительно, ключ для каждого экземпляра. Будет ли это считаться лучшим способом для варианта 3?
6. Стоит ли выполнять дополнительную проверку в реальном API? Если да, то зачем мне вообще облачные конечные точки?
7. В документации GCP не упоминается большая проблема с вариантом 4. Я думаю, что это должно быть сделано намного более понятным.
8. В чем было бы преимущество использования варианта 5? Тот факт, что я могу определить, кто совершает вызов? Почему бы тогда не создать больше ключей API?
9. Полезен ли вообще вариант 6? Хотя это считается аутентификацией в конечных точках Cloud, на самом деле это авторизация, правильно?
10. Что изменится, если веб-браузер будет использовать API?

Вот мое мнение (но ваш вопрос основан на мнении и может быть закрыт)

1. Это зависит!! В основном из возможностей вашего клиентского приложения! Если вы можете создать JWT, подписанный Google, на основе учетной записи службы, это идеально (не облачная конечная точка, встроенная безопасность продукта). Помните, что добавление дополнительного уровня подразумевает новую возможную точку отказа, новый материал для обслуживания и обновления. Если вы можете избежать этого, это лучше!

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

3. Google выполняет аутентификацию во всех случаях. Только для продукта GCP он выполняет авторизацию на основе ролей IAM и разрешений.

4. Для # 3 должен быть известен открытый ключ подписи. С учетной записью службы Google знает открытый ключ. Вы можете настроить пользовательскую аутентификацию и предоставить свой собственный открытый ключ (например, вашего PKI, если вы используете автономный сервер OIDC)

5. 1 учетная запись службы для каждого приложения, если отлично: у каждого приложения могут быть разные разрешения. Если одно приложение скомпрометировано (и учетная запись службы украдена), учетная запись службы не перегруппирована, и вам не нужно менять ключ учетной записи службы в других приложениях. Тем не менее, вы ограничены 100 учетными записями служб на проект. Я не уловил «ключ для каждого экземпляра». Вы можете сгенерировать несколько ключей, если вам нужно повернуть их или сохранить один в сейфе (на вашей стороне). Если у вас есть на примете что-то другое, пожалуйста, прокомментируйте!

6. Это зависит!! У ваших клиентских приложений другая авторизация? В этом случае вам необходимо идентифицировать личность вызывающего абонента, а затем сопоставить его авторизацию внутри вашего сервиса (обычно мы делаем это с Firestore). Если простой аутентификации достаточно, не выполняйте дополнительные проверки. Почему конечная точка Cloud? Если у вас облачный запуск в частном режиме (принимайте только JWT, подписанный Google), и ваше клиентское приложение может использовать только ключ API, вам нужен посредник для аутентификации клиентского приложения и генерации JWT при пересылке запроса

7. Как было сказано ранее, только аутентификация выполняется Google. Для вашего собственного приложения вы должны управлять авторизацией самостоятельно. И да, если вы принимаете стороннего поставщика OIDC (Google, Facebook, LinkedIn, как вы можете сделать с Firebase Auth (или Cloud Identity Platform), вы открываете свой API для всех допустимых проверок подлинности)

8. В этом случае идентификатор Google используется для аутентификации (вызывающего абонента), а КЛЮЧ API — для аутентификации (проекта). Во-первых, ключ API идентифицирует проект GCP, а не учетную запись (пользователя или службу) или приложение. Только проект! (это означает, что если вы хотите строго идентифицировать другое приложение (поскольку у вас разные авторизации для каждого приложения), вам нужен проект GCP для каждого приложения и ключ API для каждого проекта, и вы не можете автоматически сгенерировать ключ API, поэтому вам нужно сделать это вручную,… Скучный момент …). Во-вторых, в этом случае вы можете использовать ключи API для квот и функции ограничения скорости (действительно, для этого вам нужен ключ API, а не Google ID, он работает только с ключом API)

9. То же, что и раньше

10. Если вы имеете в виду браузер с аутентифицированными пользователями, используйте Firebase Auth (или Cloud Identity Platform) для аутентификации ваших пользователей, и это все.

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

У меня есть только французское видео, в котором рассказывается об этой теме. Но я представлю его на английском языке на конференции Serverless Day в Цюрихе позже в сентябре, я постараюсь более четко объяснить концепцию ключей API и когда их использовать!