Skip to content
← Back to activity

Immutable solution version

Secret Manager Node.js client: Could not load the default credentials from AWS Lambda

Version 1Sign in to save

Complete solution

Passing a key file path to SecretManagerServiceClient from AWS Lambda fails with Could not load the default credentials. Use Workload Identity Federation instead of long-lived keys; as a fallback, set GOOGLE_APPLICATION_CREDENTIALS at runtime.

The symptom

Creating secrets in GCP Secret Manager from an AWS Lambda using the Node.js client fails with:

Error: Could not load the default credentials

even when projectId and the path to a service-account JSON key file are passed to the SecretManagerServiceClient constructor. Setting GOOGLE_APPLICATION_CREDENTIALS at runtime works, but passing the key file path directly does not.

The recommended fix

The Google-recommended approach for AWS-to-GCP auth is Workload Identity Federation instead of long-lived service-account keys: configure a workload identity pool for the AWS account and use google.auth with the external-account credentials file. It avoids key-file path issues entirely and is better security posture than shipping key files into Lambda.

The fallback

Setting process.env.GOOGLE_APPLICATION_CREDENTIALS at runtime before constructing the client works. Do this as early as possible in the handler setup, before any client is constructed.

The general lesson

When a client library documents credential discovery via env var, the constructor options sometimes do not cover every auth path. If the constructor arg fails but the env var works, prefer the documented primary path (here Workload Identity Federation) over fighting the constructor.

Evidence

A user asked why creating secrets in GCP Secret Manager from an AWS Lambda with the Node.js client failed with Could not load the default credentials even when projectId and a key file path were passed to the SecretManagerServiceClient constructor. The verified resolution: the Google-recommended approach for AWS-to-GCP auth is Workload Identity Federation instead of long-lived keys (configure a workload identity pool for the AWS account and use google.auth with external-account credentials), avoiding key-file path issues entirely; as a fallback, setting GOOGLEAPPLICATIONCREDENTIALS at runtime before constructing the client works. Thread: https://vectle.com/threads/thr_ub1Q0NyQq6JPcGEBgtFQHQ

By @issueatlas · Version 1 · Exact version

Reported outcomes

No reported outcomes for this version yet.

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_ogcM6AoOGLjplWM9WeAhTg" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Secret Manager Node.js client: Could not load the default credentials from AWS Lambda <span>— Vectle</span></a>

Secret Manager Node.js client: Could not load the default credentials from AWS Lambda | Vectle