Ошибка "Не удалось найти учетные данные по умолчанию" при использовании Google Cloud Storage

У нас есть приложение Golang, работающее в Google App Engine, которое считывает ключ подписи с помощью cloud.google.com/go/storage. При попытке развернуть недавно обновленную версию он начал получать ошибки, говоря, что он не может найти учетные данные по умолчанию и, следовательно, не получить доступ к хранилищу.

bucketName, err := file.DefaultBucketName(ctx)
if err != nil {
     log.Errorf(ctx, "failed to get default GCS bucket name: %v", err)
     return nil, nil, err
}
client, err = storage.NewClient(ctx)
if err != nil {
     log.Errorf(ctx, "failed to create client: %v", err)
     return nil, nil, err
}

(ctxэто контекст. мы создаем, используяappengine.NewContext()с входящим http.Request объектом качестве параметра;file является google.golang.org/appengine/file)

Это привело к этому журналу ошибок:

"2020-06-15 09:16:51.809 CEST не удалось создать клиент: набор: google: не удалось найти учетные данные по умолчанию. Дополнительную информацию см. На https://developers.google.com/accounts/docs/application-default-credentials. "

Прослеживая ошибку через библиотеки golang, мы обнаружили, что, похоже, приложение не может разрешить имя хоста метаданных, которое должно быть установлено при его запуске на платформе Google Cloud.

Мы решили эту проблему, добавив это в файл app.yaml, но делать это неправильно:

env_variables:
  GCE_METADATA_HOST: "169.254.169.254"

Это заставляет testOnGCE()в metadata.go ( https://github.com/googleapis/google-cloud-go/blob/master/compute/metadata/metadata.go), чтобы вернуть значение true и позволить нам прочитать ключ подписи из хранилища.

Это ошибка платформы Google Cloud, которую нам нужно исправить, или что-то не так с приведенным выше кодом? Он работал нормально с тех пор, как мы добавили его в 2018 году, и только начали давать сбой при развертывании кода в июне 2020 года, а сломавшееся развертывание содержало только изменения в клиентском коде JavaScript, бэкэнд golang не был затронут. Мы пытались повторно развернуть его несколько раз, но сообщение об ошибке было на 100 % воспроизводимым, пока мы не добавили обходной путь.

0 ответов

Другие вопросы по тегам