简体   繁体   中英

Kubernetes Secrets vs ConfigMaps

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

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

PS After a few iterations we have stabilised at the following rule:

  • 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. Use Secrets for things which are actually secret like API keys, credentials, etc
  2. Use ConfigMaps for not-secret configuration data

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.

Hope that helps.

One notable difference in the implementation is that kubectl apply -f :

  • ConfigMaps are "unchanged" if the data hasn't changed.
  • Secrets are always "configured" - even if the file hasn't changed

Both, ConfigMaps and Secrets store data as a key value pair. The major difference is, Secrets store data in base64 format meanwhile ConfigMaps store data in a plain text .

If you have some critical data like, keys, passwords, service accounts credentials, db connection string, etc then you should always go for Secrets rather than Configs.

And if you want to do some application configuration using environment variables which you don't want to keep secret/hidden like, app theme, base platform url, etc then you can go for ConfigMaps

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM