Config reload replays namespace updates once per endpoint #2762

Bug Report

General Information

• Environment description: Any deployment mode using dynamic config reload; easiest to observe in non-orchestrated mode with many endpoints sharing a namespace.
• Kernel version: Not applicable for reproducing this userspace control-plane inefficiency.
• Orchestration system version in use: Not applicable.
• Link to relevant artifacts: KubeArmor/core/unorchestratedUpdates.go, KubeArmor/core/kubeUpdate.go
• Target containers/pods: Multiple endpoints in the same namespace.

To Reproduce

1. Inspect WatchConfigChanges() in KubeArmor/core/unorchestratedUpdates.go.
2. Note that the config-change callback copies dm.EndPoints and then calls UpdateDefaultPosture("MODIFIED", ep.NamespaceName, ...) and UpdateVisibility("MODIFIED", ep.NamespaceName, ...) once for every endpoint.
3. Observe that both update paths are namespace-scoped, so repeated endpoints from the same namespace trigger the same work repeatedly.
4. Use a targeted test or benchmark with many endpoints sharing one namespace and trigger the config-reload handler; compare namespace update counts before and after deduplicating namespaces.

Expected behavior

A single config reload should perform one namespace-level posture update and one namespace-level visibility update per affected namespace.

Actual behavior

The callback repeats the same namespace-scoped posture and visibility updates once per endpoint, so hosts with many endpoints in one namespace do redundant work and produce extra log noise.

Screenshots

Not applicable.

Summary

A config reload in WatchConfigChanges() performs namespace-scoped posture and visibility updates once per endpoint instead of once per namespace.

Affected Area

KubeArmor/core/unorchestratedUpdates.go
KubeArmor/core/kubeUpdate.go

Steps to Reproduce

1. Open KubeArmor/core/unorchestratedUpdates.go and inspect the WatchConfigChanges() callback.
2. Confirm that it iterates over the copied endpoint slice and invokes UpdateDefaultPosture and UpdateVisibility for every endpoint.
3. Create many endpoints that share the same namespace and trigger a config reload.
4. Count update invocations or compare elapsed time before and after namespace deduplication.

Expected Behaviour

Each namespace should be updated once per config change regardless of how many endpoints it contains.

Actual Behaviour

The same namespace can be updated repeatedly, once for each endpoint in that namespace.

Technical Evidence

• WatchConfigChanges() currently copies dm.EndPoints under EndPointsLock and then iterates the copied slice.
• Inside that loop it logs Updating Default Posture for endpoint %s and calls UpdateDefaultPosture("MODIFIED", ep.NamespaceName, ...) plus UpdateVisibility("MODIFIED", ep.NamespaceName, ...) for every endpoint.
• Both update APIs are namespace-scoped, so repeated NamespaceName values re-run equivalent work.

Suspected Root Cause

The config-reload callback is structured around endpoint iteration rather than a deduplicated namespace set.

Proposed Direction

Build a deduplicated namespace set from the locked endpoint snapshot, then run the namespace-scoped posture and visibility updates once per namespace while preserving current correctness.

Acceptance Criteria

• One config reload performs one namespace-level posture update per namespace.
• One config reload performs one namespace-level visibility update per namespace.
• Focused test or benchmark coverage demonstrates reduced work for repeated namespaces without changing correctness-sensitive outcomes.