问题的上下文是“秘密管理”。

如何管理生产中的微服务的秘密存储和检索?

评论

您尝试了什么?

@ 030,我尝试了Hashicorp的Vault,最近尝试了AWS Parameter存储。

#1 楼

简短答案

理想情况下,您应将机密存储为环境变量,并从Hashicorp的Vault或AWS参数存储之类的机密管理系统中检索它们。

长答案

我不由自主地看到了您的问题,并在另一个问题中也提到了这一点: ,由构建实例注入的环境变量,使用存储在对象存储中的加密文件自行开发的解决方案等。...


这实际上取决于您如何运行和部署应用程序。我在一家使用Amazon Beanstalk进行生产的公司工作,他们将所有秘密和配置作为由Jenkins构建服务器创建的“ secrets.conf”文件进行了分发,并在应用程序部署时随其一起提供。那里的问题是,在詹金斯的多个工作中管理相同的秘密是不守规矩的。因此,我进来,将他们转移到使用Chef来创建文件,然后Chef从Hashicorp Vault提取了文件。

在我目前的公司中,他们是内置GitLab的重度用户CI / CD构建系统。由于这些应用都是在Kubernetes中运行的所有Docker实例,因此所有秘密实际上都设置为部署期间设置的环境变量。构建服务器从GitLab用户界面中设置的“秘密变量”中获取这些变量。

这些适合当时的业务需求,这才是最终的关键。但是,如果您想变得适当,则应将机密存储为环境变量,因为您特别提到了微服务。强烈建议您遵循12因子应用程序方法进行配置:https://12factor.net/config


十二要素应用程序将配置存储在环境变量中(通常缩写为env vars或env)。 Env var易于在部署之间进行更改,而无需更改任何代码。与配置文件不同,它们很少有可能被意外检入代码存储库;与自定义配置文件或其他配置机制(例如Java系统属性)不同,它们是与语言和操作系统无关的标准。


因此,您一定要利用环境变量。设置这些环境变量的方式可以是配置管理系统(例如:Chef),也可以是构建服务器在部署时的构建服务器,或者可以对应用进行编码以直接从秘密存储中提取并在内部设置这些变量。 >
对于秘密所在的实际位置(从中检索秘密的位置),您有几种选择。但是您在评论中提到的2个将非常有用:Hashicorp的Vault和AWS Parameter存储。其他可能是Chef Vault,使用存储在对象存储中的加密文件,1password等等的本地解决方案。理想情况下,您希望可以通过构建管道或应用程序以编程方式对其进行访问。

评论


您还具有令人羡慕的分配系统的经验,这些系统会在发生故障时将变量还原为最后一组正确的变量?

–莫里茨
18年4月5日在6:15

而且AWS刚刚添加了它自己的Secret Manager

–利维
18-4-5在11:18



@Moritz我没有变量管理器的经验。这似乎是“一切都是环境变量”的逻辑演变。听起来不错。

–BoomShadow
18年4月5日在15:03

#2 楼

我们在我的公司使用Chef Vault。这是一个快速教程
如何创建Chef-Vault

#3 楼

看看https://pkhub.io,它是一个易于设置和使用的云秘密管理器,有关Python示例,请参阅https://pkhub.io/usecases/environments。