如何在Microservice / Container / Cloud环境中管理秘密？ [英] How to manage secrets in a Microservice / Container / Cloud environment?

问题描述

微服务和云是一件事。每个人都在谈论和写作。就个人而言，我正在考虑这个主题：如何利用这些话题？什么是可能的挑战？这如何加速日常发展？如何管理所有的东西？
几天以来困扰我的一个问题是如何在微服务/云环境中管理秘密？

想象一下，一家拥有150名软件工程师的公司和各种团队的各种产品。每个团队都在创建一个软件，每个服务都需要各种各样的秘密（API密钥，密码，SSH密钥等）。
旧时尚的方式是以ini / yaml / txt格式创建一些配置文件，并从中读取。 12Factor应用程序说：每个env vars都可以执行。

可以为每台机器设置Env vars，并且配置文件也可以放置在那里。
如果您手中充满了机器，并且部署由几个系统管理员完成，则此功能将起作用。
一般规则之一说：不要在Git repo中存储秘密。

现在新的世界进来了
有团队负责自己生产的应用程序。
他们应该由团队部署和运行。
所以我们公司正在转向容器和自助服务（例如Mesos和Marathon或Kubernetes）。

当然，Dockerfiles可以将env vars设置为好。是的，您可以在构建期间将配置文件添加到Docker容器中。
但是每个人都可以访问这些秘密（例如来自其他团队）。没有人知道谁使用这个秘密，做一些危险的事情。

你也想对Dockerfiles进行版本化。您应该在Marathon上运行的应用程序也应该进行版本化（Git或其他任何操作）（并由REST API应用）。那么在哪里存储和管理这个容器/应用程序的所有秘密？
由于具有Swarm和Machine（Docker），Mesos和Marathon（可用于Docker）或Kubernetes等调度程序框架，您不知道应用程序将在哪里运行。这将安排在几台机器上。
大多数这些工具都没有验证（默认情况下，这可以由Nginx代理或其他东西添加）。

管理秘密的一个想法正在使用保险柜等工具。但我从来没有在应用程序中看到本机支持。这同样适用于 Blackbox 。而且我不知道配置管理如何解决这个问题。我知道厨师支持加密的数据库，但是不可能使用Chef来设置/构建Docker容器。

如何在多团队环境中管理秘密几个工程师在Microservice / Container / Cloud环境中？

解决方案

有几种解决方案。

首先，不要将你的秘密放在图像中。这是一个坏主意，正如你所意识到的。如果您在构建时不添加秘密，则必须在运行时执行此操作。这让我们有几个选择：

• 根据 12 Factor App 。然后，您将需要编写一个脚本，当容器启动时，将使用这些变量的值填充配置文件。这样做可以，但是我并不喜欢它，因为环境变量很容易被泄露（它们可以在链接的容器中看到，并且通常被包含在错误报告中 c> docker inspect 。另请参阅召唤。




• 使用卷。只需在运行时挂载配置文件与秘密。这是有效的，但是这意味着你有一个文件，秘密在主机上。当您不知道容器运行的主机时，例如使用Swarm和Mesos等框架时，会变得更复杂。




• 使用安全的k / v存储，例如保险柜 / Keywhiz 。正如你所指出的，你需要做一些脚本来获取应用程序中的值（和env vars一样）。您还需要以某种方式向k / v存储进行身份验证（您可能需要查看）的卷驱动程序Keywhiz 和保险柜，或使用通过env传递的一次性令牌var）。

Kubernetes已经有相当先进的秘密支持，我期望看到其他框架采用自己的解决方案。

Microservices and Cloud is a thing. Everyone is talking and writing about. Personally i am thinking a lot about this topics: How this can be used to benefit from? What are possible challenges? How can this speedup the daily development? And how to manage all things? One question that bothers me since a few days is "How to manage secrets in a Microservice / Cloud environment?".

Imagine a company with 150 software engineers and various teams with various products. Every team is creating a software and every service needs various amounts of secrets (API-Keys, Passwords, SSH-Keys, whatever). The "old fashion" way was to create a few configuration files in a ini / yaml / txt format and read it from. 12Factor apps say: Do it per env vars.

Env vars can be set per machine and the config files can be placed there as well. This works if you got a hand full of machines and the deployment is done by a few system admins. One of the general rules say: "Don`t store secrets in a Git repo.".

Now the new world comes in. Ever team is responsible for the application they produce itself. They should be deployed and run by the team. So our company is moving to a container and self-service way (e.g. Mesos and Marathon or Kubernetes).

Of course, Dockerfiles can set env vars as well. And yes, you can ADD your config file into the Docker container during build. But with this everyone can access the secrets (e.g. from other teams). And no one knows who uses this secrets and do something dangerous.

You want to versionize your Dockerfiles as well. And applications you want to run on Marathon should be versionized (Git or whatever) as well (and applied by REST API). So where to store and manage all the secrets for this containers / apps? Because with scheduler frameworks like Swarm and Machine (for Docker), Mesos and Marathon (usable for Docker as well) or Kubernetes you don`t know where your app will be running. This will be scheduled over several machines. And most of this tools have no authentification (by default, of course this can be added by a Nginx proxy or something).

One idea to manage secrets is using a tool like Vault. But i never saw "native" support in an app. The same applies for Blackbox. And i don`t know how configuration management can solve this. I know that Chef supports encrypted databags, but afaik it is not possible to use Chef to setup/build Docker containers.

How do you manage secrets in a multi team env with several engineers in a Microservice / Container / Cloud environment?

解决方案

There are several solutions.

First, DO NOT put your secrets into the image. That's just a bad idea, as you've realized. If you don't add your secrets at build time, you have to do it at run-time. This leaves us with a few options:

• Use environment variables as suggested by the 12 Factor App. You will then need to write a script that will populate the config files with values of these variables when the container starts up. This works, but I don't really like it, as environment variables are easily leaked (they can be seen in linked containers and docker inspect and are often included in bug reports). Also see Summon.

• Use volumes. Just mount the config file with the secrets at run-time. This works, but does mean you have a file with the secrets lying about on the host. This gets more complicated when you don't know on which host your container will run, such as when using frameworks like Swarm and Mesos.

• Use a secure k/v store such as Vault/Keywhiz. As you point out, you will need to do some scripting to get the values into the application (as with env vars). You also need to authenticate to the k/v store somehow (you may want to look at the volume drivers for Keywhiz and Vault, or use a one-use token passed via an env var).

Kubernetes already has fairly advanced support for secrets, and I would expect to see other frameworks adopt their own solutions.

这篇关于如何在Microservice / Container / Cloud环境中管理秘密？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！