The <name>-config ConfigMap and its envFrom are a vestigial pair

[jacaudi]

Found while designing #2, verified at be6d4e4. Low priority — nothing is broken.

What is there

The <name>-config ConfigMap and the agent container's envFrom that consumes it are an inert pair:

• ConfigMapBuilder.ForWireguard sets Labels, an owner reference, and Data: map[string]string{} — nothing else (internal/resources/configmap.go:39-46).
• Nothing anywhere writes to its Data. The controller creates it (wireguard_controller.go:805-825) and never updates it.
• Its only consumer is the agent container's envFrom (internal/resources/deployment.go:177-183).
• The agent binary reads no environment variables at all — no os.Getenv, no envconfig, no viper anywhere in cmd/agent/ or internal/agent/. Its configuration arrives via flags and the --state file.

So: an always-empty ConfigMap injected into a binary that never looks at the environment. It exists only so the envFrom does not dangle.

Why this is being filed rather than fixed in #2

#2's design considered converting the ConfigMap to declarative reconciliation alongside the Deployment and Service, and correctly decided against it: with no data, there is no drift surface. That reasoning stands. This issue records the different finding underneath it.

The complication worth deciding deliberately

Because the operator creates the ConfigMap and never updates it, a user can hand-edit keys into it and they persist and get injected into the agent pod. That is an undocumented, accidental extension point. It would survive even a move to Server-Side Apply, since an empty Data map is dropped by omitempty and therefore never owned by the operator.

So deleting the pair removes a capability that someone may be relying on, even though nobody designed it.

Options

1. Delete both together. The ConfigMap and the envFrom. They must go together — removing only the ConfigMap makes pods fail to start, since envFrom without optional: true is a hard dependency. Cleanest end state; costs one pod-template change and therefore one rollout.
2. Keep and document it as a deliberate env-var escape hatch, with optional: true on the envFrom so a deleted ConfigMap cannot wedge pod startup.
3. Leave as-is. Costs nothing today; the finding is recorded here.

Worth weighing against #5 and #6, which add proper extension points for exactly this kind of customisation — if those land, the accidental hatch has less reason to exist.