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. After a few iterations we have stabilised at the following rule:

• configMaps 针对每个解决方案域(可以在域内跨微服务共享，但最终是单一用途的配置条目)

• 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. 将 Secrets 用于 API 密钥、凭据等实际上是秘密的事物
2. 将ConfigMaps用于非机密配置数据

1. Use Secrets for things which are actually secret like API keys, credentials, etc
2. Use ConfigMaps for not-secret configuration data

在未来，秘密可能会有一些区别，例如轮换或支持使用 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屋！