ConfigMap vs Secret
Config-versus-sensitive-data separation.
ConfigMaps hold non-sensitive plain config; Secrets hold sensitive data, base64-encoded and treated specially (RBAC, optional encryption at rest).
What's really being asked
Understanding the intended separation between ordinary configuration and sensitive material, and the real (limited) security guarantees of Secrets.
The full answer
Both ConfigMaps and Secrets externalize configuration from container images so the same image runs across environments. A ConfigMap is for non-sensitive data: log levels, feature flags, service URLs, and other tunables. A Secret is for sensitive data: database passwords, API tokens, TLS certificates and keys. The practical differences are that Secret values are base64-encoded in the object (which is encoding for binary-safety, not encryption), and that Kubernetes treats Secrets more carefully: you can enable encryption at rest in etcd, restrict access with RBAC, and the kubelet can mount them via tmpfs rather than writing to node disk. The decision rule is simple: if leaking the value would be a security incident, use a Secret; otherwise use a ConfigMap.
The mistakes people make
Claiming base64 makes Secrets encrypted; it is trivially reversible. Storing passwords in ConfigMaps. Assuming encryption at rest is on by default, when it must be configured.
What usually comes next
How do you actually secure Secrets? Enable encryption at rest, lock down RBAC, and consider an external secrets manager. How are both consumed? As environment variables or mounted files. What about immutability? Both support an immutable flag to reduce API load.
A concrete example
An app reads its log level and an upstream URL from a ConfigMap, and its database password and TLS key from a Secret. The Secret is base64-encoded in YAML, RBAC limits who can read it, and the cluster has encryption at rest enabled so the value is not stored in plaintext in etcd, while the ConfigMap needs none of that protection.
Interview question
Which statement about Kubernetes Secrets is accurate?
- a.Secrets store sensitive data; base64 is only encoding, and real protection needs RBAC and encryption at restCorrect
- b.Secrets and ConfigMaps are functionally identical
- c.Secret values are encrypted by default because they are base64-encoded
- d.Secrets can only be consumed as environment variables, not files
Why? this is the answer
Secrets are for sensitive data, but base64 is encoding, not encryption, so security relies on RBAC and enabling encryption at rest. They differ from ConfigMaps and can be mounted as files too.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #configmap
- #secret
- #configuration
- #security
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles