ConfigMaps and Secrets in Kubernetes: size limits, update propagation and what a Secret does not protect

What it is

A ConfigMap holds non-confidential key-value data; a Secret holds a small amount of sensitive data. Both are consumed by Pods as environment variables, as command-line arguments through those variables, or as files in a mounted volume. The ConfigMap documentation (cited) states that a ConfigMap is not designed to hold large chunks of data and that its data cannot exceed 1 MiB; the Secret documentation (cited) sets the same 1 MiB limit per Secret. Both objects can be marked immutable, after which their data cannot be changed and the kubelet stops watching them.

Why it matters

Two properties are routinely misunderstood. First, update propagation: according to the cited documentation, a ConfigMap consumed in a volume is eventually refreshed after the kubelet's periodic sync plus its cache propagation delay, whereas ConfigMaps consumed as environment variables are not updated automatically and require a Pod restart, and a container that mounts a ConfigMap through subPath never receives updates. Second, secrecy: Secrets are, by default, stored unencrypted in etcd; anyone with API access can retrieve or modify a Secret, anyone with etcd access can read it, and anyone who can create a Pod in a namespace can read every Secret in that namespace through that Pod. Base64 is an encoding, not protection.

How to apply

• Keep configuration that changes with the release in the image or the manifest, and put only environment-specific values into ConfigMaps; version large files elsewhere.
• Mount as a volume without subPath when the application can re-read files; otherwise trigger a rollout on change, for example by hashing the ConfigMap into a Pod annotation so the Deployment template changes.
• Follow the steps the Secret documentation lists: enable encryption at rest for Secrets, write RBAC rules that grant get on Secrets only to the service accounts that need them, restrict Secret access to specific containers, and consider an external secret store.
• Mark release-bound ConfigMaps and Secrets immutable and create a new object per version; this also reduces API server watch load.
• Never print Secret objects in CI output: kubectl get secret -o yaml shows the base64 form, which is trivially decoded (kubectl describe hides the values and shows only their sizes).

Pitfalls

Namespace scope: a Pod can only reference Secrets in its own namespace. The ConfigMap task page (cited) states that a referenced ConfigMap or key that does not exist prevents the Pod from starting unless the reference is marked optional; the same optional field exists for Secret references. Environment variables are inherited by every child process and tend to end up in diagnostic output; files with restrictive modes are the safer projection for credentials.