MutatingPolicy CEL Engine Namespace Resolution#

The MutatingPolicy CEL engine (pkg/cel/policies/mpol/engine/) exposes two evaluation entry points — Handle() and Evaluate() — that resolve the namespace object inconsistently, causing divergent behavior between admission-time and background (mutate-existing) policy evaluation.

The Inconsistency#

Handle() (admission webhook path) explicitly resolves the namespace via e.nsResolver before forwarding to handlePolicy():

var namespace *corev1.Namespace
if ns := request.Request.Namespace; ns != "" {
    namespace = e.nsResolver(ns)
}

Evaluate() (background/inline path) passes nil unconditionally 1:

r, patched := e.handlePolicy(ctx, mpol, attr, request, nil, true)

Because the background processor in pkg/background/mpol/processor.go calls engine.Evaluate() — not Handle() — any policy that relies on namespaceSelector or the namespaceObject CEL variable during background reconciliation receives a nil namespace context.

Impact#

namespaceSelector matching is silently broken for mutate-existing policies. When handlePolicy() calls e.matcher.Match(...), the matcher receives a nil namespace and therefore cannot evaluate labels against the selector. The result is that the selector is ignored: mutations are applied to all matching resources regardless of namespace labels 2.

namespaceObject CEL variable is always null in Evaluate(). The prepareData() function in pkg/cel/policies/mpol/compiler/eval.go populates the namespaceObject CEL activation key from whatever *corev1.Namespace it receives. When Evaluate() passes nil, CEL expressions referencing namespaceObject.metadata.labels (or any sub-field) will fail at runtime rather than returning expected values.

Affected scenarios:

Namespace Data Flow#

The namespace object flows top-down through the call stack:

Handle() / Evaluate()
  └─ handlePolicy(…, namespace *corev1.Namespace, …) [engine.go:181]
       └─ CompiledPolicy.Evaluate(…, namespace, …) [policy.go]
            └─ prepareData(attr, request, namespace) [eval.go:23-66]
                 └─ compiler.NamespaceObjectKey → CEL activation map

prepareData() converts the namespace via utils.ObjectToResolveVal(namespace) and injects it at compiler.NamespaceObjectKey. A nil input produces a null CEL value rather than a panic — the failure is silent at the matching layer 3.

Proposed Fix (Issue #16953)#

The open bug report proposes mirroring Handle()'s namespace resolution in Evaluate():

+var namespace *corev1.Namespace
+if ns := attr.GetNamespace(); ns != "" {
+ namespace = e.nsResolver(ns)
+}
 for _, mpol := range mpols {
     if predicate != nil && predicate(mpol.Policy) {
- r, patched := e.handlePolicy(ctx, mpol, attr, request, nil, true)
+ r, patched := e.handlePolicy(ctx, mpol, attr, request, namespace, true)

Note that existing tests for Evaluate() use a synthetic nsResolver but do not catch this bug because Evaluate() never calls e.nsResolver() — fixing this will also require updating those test cases 2.

Historical Context#

namespaceObject support in MutatingPolicy was added in PR #15625; before that, the variable was absent from the CEL activation map entirely 3. The current bug is the second generation of this class of missing-namespace fix — the engine correctly wires the resolver in Handle() but forgot to replicate it in Evaluate().

A similar class of issue was filed for ValidatingPolicy admission matchConditions 4, suggesting namespace resolution gaps are a recurring pattern across CEL policy types. See the CEL Context Injection knowledge article for the full fix history across policy types.

Key Files#