Firebase 功能第二代 - 运行时隐私和安全

Question

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.

Answer 1

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.