I use Google Source Repository to store my Google Cloud Functions. (Git repo hosted by Google, basically)
One of my function needs to access a private Google Sheet file, I therefore created a Service Account. (With way too many rights since it's so hard to understand what exact rights we should give to a service account, and so hard to update later on, but I digress)
Now, it's clearly not recommended to store the Service Account JSON file in the git repository itself for obvious reasons. Here is what it looks like (stripped from values)
{
"type": "service_account",
"project_id": "",
"private_key_id": "",
"private_key": "",
"client_email": "",
"client_id": "",
"auth_uri": "",
"token_uri": "",
"auth_provider_x509_cert_url": "",
"client_x509_cert_url": ""
}
I have been looking at environment variables to configure for a Functions or something alike but didn't find anything. Tracking the key (and therefore potentially duplicating that file on several repositories) really doesn't sound such a good idea. But I haven't found any "proper" way to do it yet. And due to the way Google Functions work, I can't think of anything else but env variables.
Use an HSM or TPM to store keys. Use a software-based key store. Don't store keys in Secret Manager or other cloud-based secret stores. Don't use the Editor role in projects that allow service account key creation or upload.
Contrasts between a service account and a user account: Service accounts vary from user accounts in a couple of key ways: Service accounts don't have passwords, and can't sign in by means of programs or treats. Service accounts are related with private/open RSA key-matches that are utilized for confirmation to Google.
Google Cloud Functions provide a mechanism to secure each of your endpoint to permitted users only, namely remove allUsers and allAuthenticatedUsers in the IAM. For service to service communication you can use service account to generate token when you want to create a request to the Google Cloud Functions endpoint.
My solution when using cloud function with a service account is:
Fetch service account credential json file from Cloud Storage and decrypt it using a Cloud KMS service account which has encrypt/decrypt permission.
Parse service account credential json file at runtime and get private_key
, client_email
and projectId
.
Pass these three secret variables to the client library
We store config variables as environment variables for cloud function, they are plain text, but it's ok. Because they are not secret things.
We must not store secret things like plain text, e.g cloud function environment variables.
You can upload the service account file along with your functions and use it from within your code. It will remain secure there. Most developers will use a .gitignore or equivalent mechanism to keep that file from being added to source control. There is an example of loading service account credentials from Firebase samples. (If you're not using the Firebase SDK, you'll have to be mindful to convert the function definition to the Cloud style.
You could also use an env var, but you'll have to take special care in quoting and escaping the values to make sure they get to your function correctly. It's kind of a hassle, but doable.
As of January 2020, Google has released a Secret Manager, which is described as:
Secret Manager is a new Google Cloud service that provides a secure and convenient method for storing API keys, passwords, certificates, and other sensitive data. Secret Manager provides a central place and single source of truth to manage, access, and audit secrets across Google Cloud.
For Cloud Functions, there is a tutorial here on how to create a secret and then retrieve it from a cloud function.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With