ConfigMap
Does ZopNight manage 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.
Rules that fire on ConfigMap
No active rule family targets ConfigMap today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.
kubectl get configmaps -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,KEYS:.data --no-headers | head -40Orphans 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.