2

I've just made a migration from 1st gen Firebase functions to 2nd gen. In this documentation, there written: GCP does not guarantee the pure safety of the data stored in a form of env variable. The article also recommends use of Secret Manager which is much more expensive than the read op of Firestore. It also means that Google does not guarantee the safety of the env variables in the Firebase functions' runtime. I use Node.js 16 runtime within 2nd gen of Firebase functions.

Is 2nd gen Firebase functions' Node.js 16 runtime environment safe enough to use sensitive data within runtime? I'm planning to read the most sensitive data from Firestore within the 2nd gen Firebase functions' Node.js 16 runtime and use it without logging it in my code. But, if such secure data like env variables can be logged in some kind of runtimes(which are not specified in the above documentation), it would be frustrating for me to find out and handle such security exceptions. So i want to make sure that the data retrieved from Firestore in the 2nd generation Firebase Functions' Node.js 16 runtime is completely safe. Unfortunately, i couldn't have found any proper documentation specifying such safety guarantee of Node.js 16 runtime.

+as @Doug mentioned in the comment, completely safe is too ambiguous in the context. So here's the details for the safety in the question:

Environment variables can be used for function configuration, but are not recommended as a way to store secrets such as database credentials or API keys. These more sensitive values should be stored outside both your source code and outside environment variables. Some execution environments or the use of some frameworks can result in the contents of environment variables being sent to logs, and storing sensitive credentials in YAML files, deployment scripts or under source control is not recommended. For storing secrets, we recommend that you review the best practices for secret management. Note that there is no Cloud Functions-specific integration with Cloud KMS.

Safety in the context is as following: Considering the comments above from the official docs, i want to make sure that my retrieved data from Firestore or elsewhere, string constants in my index.js and runtime environment variables, not to be logged or recorded at all. Most of all, not to be exposed to client side who triggers the function;.

If the runtime is safe and free from any kind of exposure of Firestore data retrieved to client side, necessity of Secret Manager and higher price will just disappear.

tsitixe
  • 1,851
  • 3
  • 14
  • 24
  • 2
    I suggest editing the question to define very specifically what you mean by "completely safe". To be perfectly fair, nothing digital is "completely safe" due to the fact an attacker just needs enough private information (passwords, secrets, 2FA access) to get a hold of anything protected by those measures. The question is just how much of a hurdle are you willing to put up against and attacker to make it hard to get that access. – Doug Stevenson Sep 11 '22 at 15:32
  • 1
    Which line are you referring to in the documentation? I'd say the environment variables are safe (that was the way before secrets manager was added to docs) and unless you are explicitly returning them to client like `return process.env` then you should be good to go. – Dharmaraj Sep 11 '22 at 16:43
  • @Dharmaraj i've thought the same as yours but the line `These more sensitive values should be stored outside both your source code and outside environment variables. Some execution environments or the use of some frameworks can result in the contents of environment variables being sent to logs, and storing sensitive credentials in YAML files` made me so confused. Of course there's no chance for our dev team to explicitly return such value. However, if everything goes the same as we both comment, there seems no reason for GCP team to leave such comment in the official document ]: – tsitixe Sep 11 '22 at 17:42
  • 1
    @tsitixe I would assume they are referring to third party frameworks e.g let's say one of your node packages source code is changed and it starts maliciously read env vars. But majorly just avoid adding the .env to version control and any deployment scripts. – Dharmaraj Sep 11 '22 at 17:48
  • @DougStevenson Thanks for the comment. I added my details on the completeness [: – tsitixe Sep 11 '22 at 18:47
  • @Dharmaraj I see! Still the quote is quite ambiguous though, since such guidelines are already vivid to the devs unlike the quote above. I guess it would be better to wait for another comment or answer. Thanks for your details btw [: – tsitixe Sep 11 '22 at 18:51

1 Answers1

2

Your quote from the documentation is basically saying that env vars lack security because they are freely and easily readable by any code that you deploy along with them, including third party libraries and modules. For that reason, putting highly "dangerous" values, such as credentials and API keys in env vars leaves them easily exfiltrated (intentionally or unintentionally). That's the warning here, and nothing more.

On top of that, env vars are sometimes stored in source code, which is often a worse situation. So you now have two reasons not to use env vars for data that must remain secret.

Secret Manager is the recommended solution because it operations on the principle of least privilege, giving you the ability to determine exactly who or what can see the values, and nothing more. This is the best option for security - you should only give access to secrets to those who have it.

If you use a database like Firestore to hold your secrets, you are going to have a problem implementing least privilege. This is primarily because anyone who has read access to your project will be able to simply open up the console and start viewing the database right there. You can't control the permissions on those individual documents. Firestore wasn't designed for that. Secret Manager was designed precisely for this case.

If you are the only person who has access to your project console, then you don't have a problem with security like this (yet). It's entirely up to you if you want to do security in the best possible way, or just get away with an easier solution. It's up to you. Or, if you implicitly trust all of the code you deploy with your function, you could get away with env vars. And, if you are the only one with access to your source control, you could even put the values in there.

You can see how everyone has a different security situation that requires different solutions. Pick the one meets your particular needs. But no solution is truly "completely safe" because someone or something must have access to your secrets, and that someone or something could be compromised in some way.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441