91

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 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

Evgeny Minkevich
  • 2,319
  • 3
  • 28
  • 42

4 Answers4

179

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.

starball
  • 20,030
  • 7
  • 43
  • 238
Paul Morie
  • 15,528
  • 9
  • 52
  • 57
  • 8
    A hopefully clarifying question. For it seems like secrets are still stored as plain text (base64), so the naming might be a little bit misleading at the moment if you ask me since. Or could you elaborate around that? I do agree, that intention based API is the way to go. – Tomas Jansson Jun 03 '17 at 19:54
  • 28
    Is it possible to use a secret inside of a config map? It is quite common that an application config file contains both secret, and non-secret data. For example, the tomcat server.xml contains both port numbers (non-secret) and shutdown password (secret)... It would be nice to represent that as a single resource... – Lucas Sep 28 '17 at 16:03
  • 1
    Should each connection string be its own Secret, or should I have something like a "ConnectionStrings" secret that contains all of them? – s g Dec 28 '17 at 23:10
  • @sg it depends on what works best for you. My recommendation would be to group information into secrets that reflects how you manage that information. IE, two different systems managed separately probably ought to be in separate secrets. A single bag of all the creds an app uses that you manage as a single unit is probably fine to go into a single secret. Hope that answer helps. – Paul Morie Feb 02 '18 at 13:03
  • @Lucas no, that's not possible with the bare primitives. A mechanism like the one you asked for is certainly valid, but it should be at a higher level than configmaps and secrets. You may be interested in this issue: https://github.com/kubernetes/helm/issues/2196 – Paul Morie Feb 02 '18 at 13:06
  • 2
    @TomasJansson secrets now support encryption at rest: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ – Paul Morie Feb 02 '18 at 13:07
  • 3
    @PaulMorie, I ended up writing a [utility that merge's yamls](https://gitlab.com/pastdev/s2i/tree/master/clconf) to accomodate my needs. So we supply our containers with a ConfigMap yaml with all the non secret values, and a Secret yaml with the secret values, then use this to merge them and present as a single config. Works great by itself or with other tools (like [confd](https://github.com/kelseyhightower/confd))... – Lucas Feb 02 '18 at 16:21
  • 1
    That's really cool @Lucas, I think a lot of folks would be interested in that. You should show that at sig-apps sometime! – Paul Morie Feb 21 '18 at 05:00
  • @PaulMorie what is sig-apps? – Lucas Feb 21 '18 at 21:16
  • 1
    @Lucas see https://kubernetes.io/blog/2016/08/sig-apps-running-apps-in-kubernetes – Vicky Chijwani May 03 '18 at 12:35
  • Can you please explain the current (1.10) implementation difference between a Secret and a ConfigMap (regardless of intent)? Other than Base64 encoding and encryption at rest. – Sebastiaan van den Broek May 23 '18 at 11:11
  • Link to @Lucas Utility mentioned above - https://github.com/pastdev/clconf. – slm Sep 23 '19 at 22:36
  • 1
    Thanks @slm, looks like it was too late for me to edit the original comment... Had to move it to github to attempt to get it merged into `confd`, but they went a different direction. I still actively use a `clconf` in all my container projects with a custom fork of confd: github.com/pastdev/confd. – Lucas Sep 24 '19 at 21:16
  • @Lucas - thanks, just stumbled onto your `clconf` tool yday, was planning to try to work it into some of our deployment scenarios as well. – slm Sep 25 '19 at 02:15
  • @PaulMorie are secret update and configmap update atomic operations? I asked a question here. What is the flow when a client updates secret or configmap? https://stackoverflow.com/questions/58529204/are-kubernetes-api-calls-secret-update-and-configmap-update-atomic-calls – JimmyCYJ Oct 23 '19 at 23:30
  • If a config file includes both sensitive and not-sensitive data, you should store the file in a Secret – fgul Feb 23 '20 at 17:16
  • 5
    @PaulMorie It's been a couple years since this answer. Has there been any development? Are they still basically them same in terms om implementation? – MEMark Jul 07 '20 at 10:08
  • I am not sure that it's possible: typical scenario is "I use some 3rd party tool, it has a config file, config file may (or not) content password/token". It means that no any difference between plain config file and "secret" config file. Do you plan to substitute secrets in the plain config files?! Surprise, but there are even binary config files lol. If you don't plan to do it, then what is the difference for me, the end user? – RandomB Jun 23 '21 at 03:55
  • 8
    Another question is: if I use always secrets instead of config maps - what can be drawbacks/problems of such approach? – RandomB Jun 23 '21 at 03:58
  • Another drawback of secret is that base64 encoded data grows... see this answer to know more about it https://stackoverflow.com/a/4715480/1564365. Basically you can pack more configuration data in configmap (up to 1mb because of the etcd limit), you won't be able to pack the same amount in secret (same limit 1mb)... and I've been burned by the limit before (hi Rancher). – Kyslik Oct 15 '21 at 12:18
  • @Kyslik compress the secret before base64. – Robino Oct 19 '21 at 11:25
  • How we can get expected security by using base64? base64 can be decoded easily. – srimaln91 Apr 16 '22 at 08:19
  • @srimaln91You don't really get security with Secrets – Anshuman Kumar Nov 23 '22 at 11:19
  • I think it would be better to use WorkloadIdentity if your cloud provider supports it, https://cloud.google.com/kubernetes-engine/docs/tutorials/workload-identity-secrets#create-secret. – Anshuman Kumar Nov 23 '22 at 11:25
10

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
Michael Cole
  • 15,473
  • 7
  • 79
  • 96
0

Kubernetes secrets are used to store information in encrypted form . So that even if is any unauthorised access is made the attacker is not able to do anything as he needs decryption key . They are used to store sensitive information.

Kubernetes Config Maps are used store non confidential info in key value store . Pods may use them cli, env variables.

Abhishek Kushwaha
  • 25
  • 5
-8

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

Mohsin
  • 89
  • 1
  • 4