我刚刚从第一代Firebase函数迁移到第二代。在本文档中写道：GCP不能保证以env变量形式存储的数据的纯粹安全。文章还建议使用Secret Manager，它比Firestore的read-op贵得多。这也意味着谷歌不保证Firebase函数运行时env变量的安全。我在第二代Firebase函数中使用Node.js 16运行时。
第二代Firebase函数的Node.js 16运行时环境是否足够安全，可以在运行时内使用敏感数据？我计划在第二代Firebase函数的Node.js 16运行时中读取Firestore中最敏感的数据，并在不将其记录在代码中的情况下使用它。但是，如果像env变量这样的安全数据可以记录在某种运行时中(上面的文档中没有指定)，那么我会很沮丧地发现并处理这样的安全异常所以我想确保在第二代Firebase Functions的Node.js 16运行时从Firestore检索到的数据是完全安全的不幸的是，我找不到任何合适的文档来说明Node.js 16运行时的安全保障。
+正如@Doug在评论中提到的，completely safe在上下文中过于模糊。以下是问题中的安全细节：
环境变量可用于函数配置，但不建议将其作为存储数据库凭据或API密钥等机密的方法。这些更敏感的值应该存储在源代码和外部环境变量之外。某些执行环境或某些框架的使用可能会导致环境变量的内容被发送到日志中，不建议将敏感凭据存储在YAML文件、部署脚本或源代码管理下。对于存储机密，我们建议您查看机密管理的最佳实践。请注意，没有特定于云功能的与云KMS的集成。
上下文中的安全性如下：考虑到官方文档中的上述评论，我想确保我从Firestore或其他地方检索到的数据、index.js中的字符串常量和运行时环境变量不会被记录或记录。最重要的是，不要暴露在触发函数的客户端；。
如果运行时是安全的，并且不会将检索到的Firestore数据暴露给客户端，那么Secret Manager的必要性和更高的价格就会消失。
您在文档中引用的话基本上是说env-var缺乏安全性，因为您随附部署的任何代码(包括第三方库和模块)都可以自由轻松地读取它们。出于这个原因；危险的"；envvars中的值(如凭据和API密钥)很容易被过滤掉(有意或无意)。这就是这里的警告，仅此而已。
除此之外，env-var有时存储在源代码中，这通常是一种更糟糕的情况。因此，对于必须保密的数据，您现在有两个理由不使用env-vars。
Secret Manager是推荐的解决方案，因为它遵循最小特权原则，使您能够准确地确定谁或什么可以看到这些值，仅此而已。这是最好的安全选择-你应该只允许那些拥有它的人访问秘密。
如果你使用像Firestore这样的数据库来保存你的秘密，你将在实现最小特权时遇到问题。这主要是因为任何对您的项目具有读取访问权限的人都可以简单地打开控制台并在那里开始查看数据库。您无法控制对这些单独文档的权限。Firestore不是为这个而设计的。Secret Manager正是为这个案子而设计的。
如果你是唯一有权访问项目控制台的人，那么你在安全性方面还没有问题。这完全取决于你是想以最好的方式实现安全，还是只想用一个更简单的解决方案。这取决于你。或者，如果您隐式地信任使用函数部署的所有代码，则可以使用env-vars。而且，如果你是唯一一个可以访问源代码管理的人，你甚至可以把值放在那里。
您可以看到每个人都有不同的安全状况，需要不同的解决方案。选择一个能满足你特殊需求的。但没有一个解决方案是真正的"；完全安全"；因为某人或某事必须能够访问你的秘密，并且某人或某事可能会以某种方式受到损害。