#authentication #google-cloud-platform #cloud #client
#аутентификация #google-облачная платформа #облако #клиент
Вопрос:
У меня есть закрытый ключ учетной записи службы Google (формат json) из консоли Google. Как мне создать нового клиента в golang (какой API Google я использую) и аутентифицировать полученные учетные данные без установки переменной среды? Я хотел бы предоставить учетные данные учетной записи службы Google вручную в Golang. Я начал с передачи файла json в виде массива байтов : creds, err := google.CredentialsFromJSON(ctx, blob) . Blob — это массив байтов файла json. Я могу успешно создать клиента с cloud.google.com/go/secretmanager/apiv1 даже после того, как я изменил закрытый ключ (ой). Итак, мне интересно, в какой момент и как мне аутентифицировать учетные данные? Спасибо.
Комментарии:
1. Вы пытались использовать свои учетные данные?
Ответ №1:
Вопрос неясен. Я позволю себе перефразировать это так: «Как создать действительные учетные данные из файла ключей учетной записи службы?«
Что ж, Google действительно реализует стратегию предоставления аутентифицированного идентификатора вызывающему процессу. В грубом виде он действительно ищет определение переменной среды с именем GOOGLE_APPLICATION_CREDENTIAL, значение которого содержит путь к допустимому файлу ключей SA. В противном случае он использует учетную запись службы по умолчанию из части вычислений, с которой он запускается (GCE, GKE pod, Appengine, cloud function, …).
Наконец, в противном случае вы получили сообщение об ошибке.
При локальной работе рекомендуется установить эти учетные данные по умолчанию с помощью облачного SDK с помощью command gcloud auth application-default login . Таким образом, приложение будет действовать от имени зарегистрированного пользователя (например, вас и использовать с вашими разрешениями и квотами).
В противном случае вы могли бы настроить переменную env вручную, чтобы указать на загруженный вами файл ключей учетной записи службы.
Теперь, если вы работаете снаружи из облачной среды Google, вы можете вручную создавать учетные данные, удаляя ключевой файл, как вы это делаете. Следующий пример является явным. Вы должны понимать, что учетные данные, которые вы подделываете, являются аргументом для любого конструктора клиента API Google.
После того, как клиент API создан с вашими учетными данными, вы просто используете его, вызывая методы, которые он предоставляет. Аутентификация происходит под капотом. Каждый вызов Google API аутентифицируется с помощью токена OAuth2, поток получения которого описан здесь . Вы можете покопаться в клиенте исходного кода клиентского API, если вам нужно убедиться, но самое приятное, что вам это не нужно.
Комментарии:
1. Спасибо @chaiyachaiya за ваш подробный ответ. Дело в следующем: мой пользователь загружает закрытый ключ учетной записи службы в формате json из консоли Google. Затем пользователь открывает файл json, копирует содержимое в пользовательский интерфейс и отправляет (публикует его как часть тела запроса post). Серверная часть удаляет ее и получает содержимое. Теперь, прежде чем обращаться к gcp с этой информацией, я хочу проверить содержимое json, на случай, если пользователь ввел неверную информацию в пользовательский интерфейс. Далее:
2. Я изменил закрытый ключ в пользовательском интерфейсе и попробовал следующее:
creds, err := google.CredentialsFromJSON(ctx, blob, secretmanager.DefaultAuthScopes()...)и_, err = secretmanager.NewClient(ctx, option.WithCredentials(creds)). Не получено никакой ошибки аутентификации. Вы сказали, что аутентификация выполняется под капотом, так что я делаю не так?3. Кроме того, прочитайте aobut JWT. Разве я не должен использовать это: cloud.google.com/endpoints/docs/openapi /… ? Еще раз спасибо за ваше время!!
4. Каким будет вариант использования? пользователь, которому вы предоставляете файл ключей, является вашим партнером, которому необходим доступ к некоторым вашим службам Google (например, GCS или API cloud endpoint)? Или вам нужен этот файл, чтобы позволить пользователю использовать общедоступный API Google (например, Gmail). Ни один из этих случаев не должен подразумевать копирование / вставку содержимого ключевого файла в форме. Я подробно изложу ваш ответ на эти вопросы. Ссылка, на которую вы указываете, действительно является процессом two legs Oauth2, но вам не нужно об этом заботиться. Клиенты Google делают. (например: при вызове клиента. CreateSecret(ctx, createSecretReq))
5. проверьте это: cloud.google.com/secret-manager/docs/reference/libraries