Kubernetes Secrets与ConfigMaps

一直在使用Kubernetes机密。现在，我们还有ConfigMaps。

首选的转发方式是什么-机密或配置映射？

PS经过几次迭代，我们稳定在以下规则：

configMap是按解决方案域划分的（可以在该域中的微服务之间共享，但最终是单一用途的配置条目）
机密在解决方案域之间共享，通常代表第三方系统或数据库

kubernetes

— 叶夫根尼（Evgeny Minkevich）
source

Answers:

140

我是这两个功能的作者。想法是您应该：

使用Secrets处理实际上是秘密的事物，例如API密钥，凭据等
将ConfigMap用于非秘密配置数据

将来，机密可能会与众不同，例如轮换或对带有HSM的机密API的支持等。总的来说，我们喜欢基于意图的API，对于机密数据和普通旧式，其意图肯定不同。配置。

希望能有所帮助。

— 保罗·莫里
source

一个希望澄清的问题。因为似乎机密仍以纯文本（base64）形式存储，所以如果您问我此后，命名可能会有些误导。还是可以详细说明一下？我确实同意，基于意图的API是必经之路。

— Tomas Jansson

是否可以在配置映射中使用密钥？应用程序配置文件同时包含秘密和非秘密数据是很常见的。例如，tomcat server.xml包含端口号（非机密）和关闭密码（机密）...很高兴将其表示为单个资源...

— Lucas

每个连接字符串应该是其自己的密钥，还是应该包含所有它们的“ ConnectionStrings”密钥之类的东西？

— sg

@PaulMorie，我最终编写了一个实用程序，该实用程序合并了Yamls以适应我的需求。因此，我们为我们的容器提供了一个带有所有非秘密值的ConfigMap yaml，以及一个带有秘密值的Secret yaml，然后使用它来合并它们并将其呈现为单个配置。单独或与其他工具（例如confd）配合使用时效果很好...

— 卢卡斯

@Lucas真的很棒，我想很多人对此会感兴趣。您应该在sig-apps上展示一下！

— 保罗·莫里

ConfigMap和Secrets都将数据存储为键值对。主要区别在于，Secrets以base64格式存储数据，而ConfigMaps以纯文本格式存储数据。

如果您有一些关键数据，例如密钥，密码，服务帐户凭据，数据库连接字符串等，那么您应该始终选择Secrets而不是Configs。

而且，如果您想使用环境变量进行一些应用程序配置，而这些环境变量不想让您保密/隐藏，例如应用程序主题，基本平台URL等，则可以使用ConfigMaps

— 莫欣
source

base64如何保护机密？它只是万无一失，而不是保护。

— Igor A. Melekhine

base64根本没有保护。

— MEMark

实现上的一个显着差异是kubectl apply -f：

如果数据未更改，则ConfigMap是“不变的”。
机密始终是“已配置”的-即使文件没有更改

— 迈克尔·科尔
source