GAE：存储密钥的最佳实践？

Question

是否存在为Google App Engine存储密钥的非常糟糕的方法？或者，至少比将它们检入源代码控制要差一些？

Answer 1

与此同时，Google添加了密钥管理服务：https://cloud.google.com/kms/

您可以使用它来加密您的秘密，然后将它们存储在数据库中，或者将它们存储在加密的源代码管理中。只有同时解密的人才会解密。访问KMS和您的秘密将能够使用它们。

事实上，能够部署代码的人总能找到你的秘密（假设你的GAE应用程序需要能够使用秘密），但就我而言，没有办法解决这个问题。可以想到。

Answer 2

这里没有简单的解决方案。检查密钥到存储库是不好的，因为它检查不相关的配置详细信息，因为它可能会暴露敏感数据。我通常只为一个实体创建一个配置模型，并在第一次部署后（或者每次更改时）在其上设置相关的配置选项和密钥。

或者，您可以签入示例配置文件，然后将其从版本控制中排除，并在本地保留实际的密钥。但是，这需要某种方式来分发密钥，并且使得开发人员无法部署，除非他们拥有生产密钥（并且所有这些都很容易意外地将示例配置文件部署到实时密钥上）。

Answer 3

不完全是答案：

• 如果您将密钥保留在模型中，则任何可以部署的人都可以从模型中读取密钥，然后再次部署以覆盖其跟踪。虽然Google允许您下载代码（除非您禁用此功能），但我认为它只会保留每个编号版本的最新副本。
• 如果您将密钥保存在未签入的配置文件中并禁用代码下载，那么只有拥有密钥的人才能成功部署，但没有人可以在不将后门隐藏到部署中的情况下读取密钥（可能不那么困难）

在一天结束时，任何可以部署的人都可以获得密钥，因此问题是您是否认为通过将密钥存储在数据存储区（例如，您可以备份）或部署者的机器。

可行的替代方案可能是将两者结合起来：将加密的API密钥存储在数据存储区中，并将主密钥放入配置文件中。这有一些很好的功能：

• 攻击者需要同时访问数据存储区的副本和配置文件的副本（可能开发人员不会在笔记本电脑上备份数据存储区并将其丢失在火车上）。
• 通过在配置文件中指定两个键，您可以进行密钥翻转（因此攻击者需要一个年龄相近的数据存储/配置）。
• 使用非对称加密，您可以让开发人员将API密钥添加到数据存储区而无需读取其他密钥。

当然，您正在将加密上传到Google的服务器，这些服务器可能会或可能不会像通常的法律问题一样“导出”加密（例如，如果Google设置亚太数据中心会怎么样？）。

Answer 4

我能想到的三种方式：

1. 将其存储在DataStore中（可能是base64编码还有一个级别 （间接）
2. 在部署期间通过命令行参数将其作为环境变量传递。
3. 保留配置文件，git-ignore它并从服务器读取它。如果你使用python部署，这个文件本身可以是一个.py文件，所以没有阅读＆amp;存储.json文件。

注意：如果您正在使用conf-file路由，请不要将此JSON存储在静态公用文件夹中！

Answer 5

如果您正在使用Laravel并将密钥存储在数据存储区中，则此包可以简化使用缓存管理性能的过程。 https://github.com/tommerrett/laravel-GAE-secret-manager

Answer 6

Google应用引擎默认情况下会为应用引擎创建凭据，并将其注入环境中。

Google Cloud客户端库使用一种称为“应用程序默认凭据”（ADC）的策略来查找您的应用程序的凭据。当您的代码使用客户端库时，该策略将按以下顺序检查您的凭据：

1. 首先，ADC检查是否设置了环境变量GOOGLE_APPLICATION_CREDENTIALS。如果设置了变量，则ADC使用变量指向的服务帐户文件。

2. 如果未设置环境变量，则ADC将使用Compute Engine，Google Kubernetes Engine，Cloud Run，App Engine和Cloud Functions提供的默认服务帐户为在这些服务上运行的应用程序。

p>

3. 如果ADC无法使用以上任一凭据，则会发生错误。

因此，第2点意味着，如果您使用IAM Admin向服务帐户授予权限，则不必担心传递json键会使其芳香地工作。

例如 假设您的应用程序在App Engine Standard中运行，并且希望访问Google Cloud Storage。为此，您不必创建新的服务帐户，只需授予对ADC的访问权限即可。

REF https://cloud.google.com/docs/authentication/production#finding_credentials_automatically