# ConfigMap

> ConfigMaps carry non-secret configuration into pods as env vars or mounted files, capped at 1 MiB each, and cost nothing directly. ZopNight records only the shape: namespace, dataCount, and key names, never the values. That is enough to map shared configuration and spot orphans. Edits do not restart consuming pods, so stale config keeps running.

Source: https://zop.dev/integrations/kubernetes/configmap
Updated: 2026-08-19

---

A ConfigMap carries non-secret configuration into pods, as environment variables or mounted files. It has no direct cost and no quota pressure worth mentioning. What it has is influence, because ConfigMaps are the wiring diagram of how workloads are actually configured.

## Key names in, values never

Discovery deliberately records only the shape of each ConfigMap: its namespace, a `dataCount`, and the sorted list of key names. Values are never read into the inventory. That trade keeps configuration content (which routinely includes internal hostnames, tuning parameters, and things that should have been Secrets) out of the platform while still supporting the questions inventory exists to answer: which ConfigMaps exist, which look abandoned, and which workloads appear wired to the same configuration.

## No price tag, real blast radius

The cost of a ConfigMap is operational. A mounted ConfigMap updates in place, because kubelet refreshes the file eventually. Environment variables sourced from one are read once at container start, so pods keep running on stale values until something restarts them. Kubernetes does not restart consumers on edit. That asymmetry is behind a familiar incident shape: config changed, half the fleet picked it up on natural pod churn, the other half kept the old behavior for days.

## A 1 MiB ceiling, and what living near it means

Each ConfigMap is capped at 1 MiB. Objects approaching the cap are usually carrying files that belong in an image or a volume, such as large certificates bundles or entire static datasets, and they make every API read and watch touching them heavier. The recorded `dataCount` and key names make the bloated ones easy to shortlist without ever opening their contents.

```bash
kubectl get configmaps -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,KEYS:.data --no-headers | head -40
```

## Orphans accumulate by default

Nothing garbage-collects a ConfigMap when its last consumer is deleted, so long-lived namespaces accrete configuration for workloads that no longer exist. Reviewing key-name inventory against the workloads actually mounting each object is the cheap periodic cleanup; it costs nothing to keep the orphans, but they are noise every future migration and audit pays for.