Kubernetes Secrets与ConfigMaps [英] Kubernetes Secrets vs ConfigMaps

问题描述

到目前为止一直在使用Kubernetes机密. 现在我们也有了ConfigMap.

Have been using Kubernetes secrets up to date. Now we have ConfigMaps as well.

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

What is the preferred way forward - secrets or config maps?

P.S.经过几次迭代，我们稳定在以下规则:

P.S. After a few iterations we have stabilised at the following rule:

• configMap是每个解决方案域的(可以在该域中的微服务之间共享，但最终是单一用途的配置条目)

• configMaps are per solution domain (can be shared across microservices within the domain, but ultimately are single purpose config entries)

秘密在解决方案域之间共享，通常代表第三方系统或数据库

secrets are shared across solution domains, usually represent third party systems or databases

推荐答案

我是这两个功能的作者.这个想法是，您应该:

I'm the author of both of these features. The idea is that you should:

1. 将秘密用于诸如API密钥，凭据等实际上是秘密的事物
2. 将配置映射用于非秘密配置数据

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

In the future there will likely be some differentiators for secrets like rotation or support for backing the secret API w/ HSMs, etc. In general we like intent-based APIs, and the intent is definitely different for secret data vs. plain old configs.

希望有帮助.

这篇关于Kubernetes Secrets与ConfigMaps的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！