Нет GOOGLE_APPLICATION_CREDENTIALS в развертывании Cloud Functions

Question

У меня есть облачная функция, которая взаимодействует с облачным хранилищем и BigQuery, и все они принадлежат одному проекту. Обычный способ, которым я следовал при развертывании облачной функции из командной строки:

$ gcloud functions deploy my_function ... --set-env-vars GOOGLE_APPLICATION_CREDENTIALS=my_project_credentials.json

, где my_project_credentials.json - файл ключа json, содержащий учетную запись службы и ключ для доступа к облачному хранилищу. и BigQuery.

Поскольку с тех пор я так и поступал, мне нужен другой способ полностью избежать этого json файла учетных данных (поскольку эти взаимодействующие службы в любом случае принадлежат одному проекту Google Cloud). Есть ли такой способ? Я немного новичок в Google Cloud, поэтому я не знаком с IAM.

(Еще одна причина, по которой мне это нужно, заключается в том, что у меня есть клиент, который не устраивает меня как разработчика. имея доступ к этому ключу json, а также он / она не хочет, чтобы этот ключ json использовался вместе с кодом функции. Пожалуйста, предоставьте некоторые подробности о том, как это сделать в IAM, особенно в BigQuery и Cloud Storage, поскольку у меня нет контроль и над IAM).

Answer 1

Когда вы можете, и по крайней мере, когда вы запускаете приложение на GCP, вы не должны использовать файл ключей учетной записи службы. 2 причины

• Это простой файл для аутентификации: вы можете легко скопировать его, отправить по электронной почте и даже зафиксировать в своем репозитории кода, возможно, publi c !!
• Это секрет, вы должны надежно хранить его и часто менять (Google рекомендует не реже, чем каждые 90 дней). Сложно управлять, вы хотите повторно развертывать свою функцию каждые 90 дней с файлом безопасности новостей!

Итак, мой коллега Гейб и Колбан имеют право. Использовать идентификатор функции:

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

В вашем коде используйте getDefaultCredential (в зависимости от языка имя немного меняется, но значение остается тем же). Если вы посмотрите исходный код, вы увидите, что функция выполняет это

• Посмотрите, существует ли переменная окружения GOOGLE_APPLICATION_CREDENTIALS. Если это так, используйте его
• Посмотрите, существует ли «общеизвестный файл». В соответствии с ОС и при выполнении команды gcloud auth application-default login учетные данные хранятся в другом месте локально. Библиотека ищет их.
• Посмотрите, существует ли сервер метаданных . Этот вычислительный механизм ссылки на ссылку, но другая среда следовала тому же принципу.

Здесь нет «магов c». Сервер метаданных знает идентификатор функции и может генерировать токен доступа и идентификации по запросу. Библиотеки реализуют вызовы к нему, если ваш код работает на GCP -> Вот почему вам никогда не понадобится файл ключа учетной записи службы, сервер метаданных здесь для предоставления вам этой информации!

Answer 2

Что сказал Колбан. При развертывании облачной функции вы можете определить учетную запись службы для использования, а затем любые вызовы API, использующие учетные данные приложения по умолчанию, будут автоматически использовать эту учетную запись службы без необходимости использования токена-носителя учетной записи службы (файл json). Ознакомьтесь с документацией здесь:

https://cloud.google.com/docs/authentication/production#auth -cloud-implicit- nodejs