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

【问题标题】：GAE: best practices for storing secret keys?GAE：存储密钥的最佳实践？
【发布时间】：2011-09-23 23:31:41
【问题描述】：

是否有任何可靠的方式来存储 Google App Engine 的密钥？或者，至少，不如将它们检查到源代码管理中那么糟糕？

【问题讨论】：

【解决方案1】：

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

您可以使用它来加密您的秘密，然后再将它们存储到数据库中，或者将它们存储在加密的源代码控制中。只有对 KMS 和您的秘密具有“解密”访问权限的人才能使用它们。

事实上，可以部署代码的人总是能够获取您的秘密（假设您的 GAE 应用程序需要能够使用这些秘密），但据我所知，没有办法解决这个问题。

【讨论】：

【解决方案2】：

不完全是答案：

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

归根结底，任何可以部署的人都可以获得密钥，所以问题是您是否认为通过将密钥存储在数据存储区（例如，您可能会对其进行备份）或存储在部署者的机器。

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

当然，然后您将加密上传到 Google 的服务器，这可能会或可能不会被视为“出口”加密，存在常见的法律问题（例如，如果 Google 建立亚太数据中心怎么办？）。

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

我能想到的三种方法：

将其存储在 DataStore 中（可能是 base64 编码以多一层间接的）
在部署期间通过命令行参数将其作为环境变量传递。
保留一个配置文件，git-ignore 它并从服务器读取它。如果您使用的是 python 部署，则此文件本身可以是 .py 文件，因此无需读取和存储 .json 文件。

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

【讨论】：

【解决方案5】：

如果您使用 Laravel 并希望将密钥存储在 Datastore 中 - 这个包可以让您轻松实现这一点，同时使用缓存管理性能。 https://github.com/tommerrett/laravel-GAE-secret-manager

【讨论】：

【解决方案6】：

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

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

首先，ADC 检查是否设置了环境变量 GOOGLE_APPLICATION_CREDENTIALS。如果设置了变量，ADC 将使用变量指向的服务帐户文件。
如果未设置环境变量，ADC 将使用 Compute Engine、Google Kubernetes Engine、Cloud Run、App Engine 和 Cloud Functions 为在这些服务上运行的应用程序提供的默认服务帐号。
如果 ADC 无法使用上述任一凭据，则会发生错误。

所以第 2 点意味着如果您使用 IAM Admin 向您的服务帐户授予权限，您不必担心传递的 json 密钥它会非常有效。

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

【讨论】：