I want to use Google Cloud Storage API in NodeJS to generate signed URL
It works inside the Cloud Run environments, but I can't find any way to make it up locally ! I always end up with the following error:
Error: Cannot sign data without `client_email`.
I know I have to use a Service Account (SA) for this, and it works nicely by impersonating one with the command gcloud config set auth/impersonate_service_account SA_EMAIL
or directly gsutil -i SA_EMAIL signurl -d 10m -u gs://bucket/file
But it's not working by the code as my ADC credentials doesn't seems to use the impersonation which works in the CLI
I know I can pass in a key file of the service account like that
const storage = new Storage({
credentials: {
client_email: 'SA_EMAIL',
private_key: 'path/to/key.json'
}
});
but my organization doesn't allow them so I have to find another way for the code to know I'm using the right SA
CodePudding user response:
Your organisation is right, you don't need to use a service account key file, it's a bad thing/idea.
You can do it differently but not sure it works in nodeJS.
Try that gcloud auth application-default login --impersonate-service-account=xxxx
. This command will create a credential on your local machine based on your own identity and that impersonate the service account.
However, a few libraries accept that new mode (not so new, implemented 6 months ago I guess, but only JAVA supported it. I performed a Golang contribution to allow Golang to support it.) I don't know if NodeJS Google OAuth2 libraries support that authentication mode.
I have 2 other options (in Python) but it seems not supported in Node (I dug into the source code and the feature is not implemented)
if it still does not work, and to continue not to use a service account key file (that is bad) I recommend you to implement the same feature as I did in Python in the client libraries. I don't have the NodeJS skills to do that, and if you can and have time to contribute it would be wonderful!
CodePudding user response:
If your org does not allow downloading service account keys, you won't be able to get a service account key onto your local machine.
You've got a few options for local testing (I assume you're doing this for testing?). The simplest, if it's permitted for you, is to create a separate project that is not part of the organization, and get service account keys from there. If it's entirely disconnected from your org's permissions and data, it will hopefully be acceptable to be a bit looser with the credentials.
One alternative, if it works with whatever tools and libraries you're using to sign your URLs, might be to use HMAC authentication. If your organization policy has not blocked HMAC signed requests (although there's a pretty good chance they would have), you could perhaps use HMAC credentials to sign requests instead of service account keys.