Аутентификация в HTTP-функциях Google Cloud

avatar
searain
30 января 2018 в 22:32
17246
2
12

https://cloud.google.com/solutions/authentication-in-http-cloud-functions

В документе предлагается настроить корзину Google Cloud Storage. Затем настройте разрешение сервисных учетных записей «storage.buckets.get» на корзину.

Затем используйте это разрешение для аутентификации доступа к http облачным функциям Google.

Мы говорим об аутентификации облачных функций HTTP, но мы заимствуем разрешение из Google Cloud Storage. Мне кажется это хакерское решение.

Если мы сможем просто настроить разрешения прямо для каждой облачной функции через Google Cloud Console, это будет здорово.

Ребята, вы используете решение для аутентификации, предложенное Google в приведенном выше документе? Или у вас есть подходы получше?

Чтобы настроить ""storage.buckets.get", означает ли это, что я предоставляю сервисному аккаунту разрешение "Storage Object Viewer"?

enter image description here

Источник
Rosário Pereira Fernandes
31 января 2018 в 11:50
0

«Если мы сможем просто настроить разрешения прямо для каждой облачной функции через Google Cloud Console, это будет здорово», — это звучит как запрос функции. Вы можете отправлять запросы функций напрямую команде Firebase здесь

Ответы (2)

avatar
arudzinska
26 апреля 2018 в 15:12
6

Решение, предложенное в приведенной вами ссылке, действительно является одним из способов. На самом деле, вы можете использовать любой другой продукт Google Cloud Platform (не только сегменты хранилища), чтобы проверить разрешения для выбранного аккаунта.

Альтернатива, которая может работать:

  1. Подготовьте облачную функцию, в которой будут перечислены адреса электронной почты авторизованных пользователей.
  2. Cloud Function извлекает заголовок 'Authorization' входящего HTTP-запроса, который содержит токен, сгенерированный для учетной записи, отправившей запрос.
  3. Функция вызывает конечную точку tokeninfo, используя указанный заголовок для получения электронной почты учетной записи (из тела ответа JSON). URL-адрес, возвращающий электронное письмо, будет выглядеть следующим образом: 
url = "https://www.googleapis.com/oauth2/v1/tokeninfo?fields=email&access_token
    =" + token_from_the_request_header;
  1. Проверка того, что возвращаемый адрес электронной почты находится в списке авторизованных.
  2. ... если да, выполнение логики функции.
Jeb50
10 декабря 2018 в 00:46
0

Скажем, у меня есть функция gcloud (API) https://us-central1-gcf.cloudfunctions.net/myapi и я хочу использовать ее в нескольких собственных приложениях. Я не думаю, что вы имели в виду, что каждый физический пользователь должен войти в Google, чтобы использовать его, верно? В корпоративной необлачной среде типичной практикой является наличие общей учетной записи LDAP для всех приложений, которые хотят вызывать эту функцию. Для gcloud мы можем заменить его общей учетной записью gmail, после прочтения «конечной точки tokeninfo» выше у меня возникает вопрос, как указать, что эта общая учетная запись gmail, скажем, CallFromApps@gmail.com может использовать мой GCF?

avatar
Katayoon
1 февраля 2018 в 00:09
4

Для использования облачных функций вам необходимо поместить свои модули в корзины. Предоставляя учетной записи «storage.buckets.get» разрешение на доступ к корзине, вы предоставляете авторизацию служебной учетной записи для запуска вашей облачной функции HTTP; и аналогичным образом вы отменяете авторизацию, удаляя разрешение «storage.buckets.get» из другой учетной записи службы.

Чтобы настроить разрешение 'storage.buckets.get', вам необходимо либо выбрать «Администратор хранилища» через стандартные роли, либо «storage.legacyBucketReader»/'storage.legacyBucketWriter» из устаревших ролей или даже определить пользовательскую роль с разрешением 'storage.buckets.get'.

Jeb50
9 декабря 2018 в 23:34
1

этого не должно быть, я могу установить триггер для корзины, темы, публикации/подписки, если они являются правильным значением для ключа --trigger для команды gcloud functions deploy.