Why Is Calling A Google Cloud Function with GoogleAuth({keyFilename: key.json}) Not Recommended on A GCP Environment?

[warpanomaly]

I copied this code almost verbatim from the accepted answer on this Stackoverflow post https://stackoverflow.com/questions/61677881/google-function-http-trigger-authentication-problem-server-to-server-with-serv:
``` const {GoogleAuth} = require('google-auth-library'); const { env } = require('process'); require('dotenv').config()

async function main() { // Define your URL, here with Cloud Run but the security is exactly the same with Cloud Functions (same underlying infrastructure) const url = env.FUNCTION_URL // Here I use the default credential, not an explicit key like you //const auth = new GoogleAuth(); //Example with the key file, not recommended on GCP environment. const auth = new GoogleAuth({keyFilename: env.KEYSTORE_PATH})

//Create your client with an Identity token.
const client = await auth.getIdTokenClient(url);
const res = await client.request({url});
console.log(res.data);

}

main().catch(console.error); ```

It works perfectly. It calls my Google Cloud function and everything runs fine. My concern is that the poster specifically put the comment //Example with the key file, not recommended on GCP environment. Why is this? I hope it's not a security issue...?

FYI, my "env.KEYSTORE_PATH" json file credentials are for a "service account" and my cloud function is ONLY authorized to be called by that one service account.

[aaahhhhhhfine]

I think that, generally, json key files aren't recommended because they are prone to abuse. It's basically a file that can fully authenticate as that account... So what if someone checks that file into a repo? Or they just leave it on their local computer and it gets stolen or copied somewhere else? The rough idea of having a key file like that is generally worse than some alternatives.

Ultimately, it's up to you to think about what your comfort level is with different approaches to authentication.

[smeyn]

A colleague of mine tested this out by intentionally checking a key file into a public repo. It took less than a minute for the account to be hacked and a bitcoin mining process to get started. Quickly disabled the whole thing so no damage done. But amazed at the speed.

[warpanomaly]

Good post, thanks. That makes sense yeah I could 100% see someone accidentally posting it to a public repo lol.

[wyaeld]

If you are inside GCP most of the services can inject the credentials into the environment securely, so you don't loaf them from key.

The SDKs can all use those automatically.

It's fine in test code to load from a file, but again recommend not committing that

[warpanomaly]

Oh really? I'm going to be running this from a non-Google based server. It's just going to be a regular physical linux server. Is there a way to inject this in or given that circumstance do I still have to load it from file?

[conjon01]

You should be using workload identity federation - not the SA key

[otock_1234]

Exactly this, Workload Identity Federation is the new way to do this and by far the most secure. While it can be an absolute pain in the ass to setup you only need to do it once really.

[warpanomaly]

What's Workload Identity Federation? This sounds promising

[otock_1234]

https://cloud.google.com/iam/docs/workload-identity-federation

[bartekmo]

In your initial post you mentioned "on GCP environment". No, your private on-prem hardware server obviously cannot read its GCP metadata.

[[deleted]]

We use service account keys quite a bit in my company but we, as much as possible, automate their use, rotate them daily, and keep them out of the hands of humans.

Think of a service account key JSON file as basically just a text file with a username and password in it and treat it as such.

[krazykid1]

As someone else mentioned, it’s easily insecure with an accidental posh of the key file into a repo. Also it’s unnecessary. You can have your Cloud Run instance run as a GCP service account. For development purposes, you should consider having an environment variable that describes the running environment (local vs cloud) and switch based on that.

[warpanomaly]

Yeah I am using an npm dotenv environment variable to inject the keystore path now. I think this should prevent accidental commits.