security.networkPolicy.allowedIngressNamespaces is accepted but never applied

[makbill]

Summary

OpenClawInstance.spec.security.networkPolicy.allowedIngressNamespaces is a valid CRD field and
setting it succeeds, but the controller never actually adds those namespaces to the generated
NetworkPolicy's ingress rules. The field is silently a no-op.

Environment

• Chart: oci://ghcr.io/paperclipinc/charts/openclaw-operator, version 0.38.3
• Kubernetes: v1.35.5+k3s1 (k3s/k3d)

Steps to reproduce

1. Apply an OpenClawInstance with:

   spec:
     security:
       networkPolicy:
         enabled: true
         allowedIngressNamespaces:
           - some-other-namespace

2. Confirm the field landed: kubectl get openclawinstance <name> -o jsonpath='{.spec.security.networkPolicy}' — shows allowedIngressNamespaces: ["some-other-namespace"] correctly.
3. Inspect the generated NetworkPolicy: kubectl get networkpolicy <name> -o yaml

Actual behavior

The ingress[].from list only ever contains the same-namespace namespaceSelector — the
namespace(s) listed in allowedIngressNamespaces never appear, regardless of how long you wait
or how many times you force a reconcile (verified via annotation-triggered reconcile + watching
resourceVersion/generation on the NetworkPolicy object, which don't change, and via operator
logs, which don't mention NetworkPolicy at all during that reconcile cycle — this isn't a
propagation delay, the controller isn't attempting the update).

Expected behavior

Namespaces listed in allowedIngressNamespaces should produce additional namespaceSelector
entries in the generated NetworkPolicy's ingress from list.

Workaround used

Created a separate, additional NetworkPolicy targeting the same pod labels
(app.kubernetes.io/instance/app.kubernetes.io/name) with the extra namespace's ingress rule,
since Kubernetes unions multiple NetworkPolicies' rules for the same pod. Left the
operator-managed NetworkPolicy alone since editing it directly would just get reverted on the
next reconcile.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If this issue is still relevant, please leave a comment or remove the stale label.

[stubbi]

Thanks for the thorough writeup — the annotation-triggered reconcile and the resourceVersion/generation check are exactly the right things to have ruled out, which is why I want to be careful here rather than ship a speculative fix.

I can't find a code defect on this path, at the version you reported:

• BuildNetworkPolicy has iterated AllowedIngressNamespaces since the initial commit (internal/resources/networkpolicy.go:148), emitting one namespaceSelector ingress rule per entry.
• resources_test.go:1875 already asserts a monitoring entry produces that rule; it passes against the v0.38.3 tag.
• reconcileNetworkPolicy writes the whole spec via controllerutil.CreateOrUpdate (np.Spec = desired.Spec), so a spec change can't be partially applied.

Your observation that the operator logs never mention NetworkPolicy during the reconcile is the interesting part — it suggests reconciliation wasn't reaching step 2 at all, rather than reaching it and computing the wrong rules. That would point somewhere other than the NetworkPolicy code.

I've added end-to-end coverage in #592 for exactly what you described: on a real cluster, allowedIngressNamespaces produces the peer, and editing the field on an existing instance converges the policy. If the defect is real, that's the test that should catch it.

Keeping this open rather than closing it as non-repro. Three things would settle it:

1. Full operator logs for one reconcile cycle after the edit (kubectl logs deploy/openclaw-operator -n openclaw-operator-system), ideally at -v=1 — specifically whether NetworkPolicy reconciled appears at all.
2. The complete CR: kubectl get openclawinstance <name> -o yaml, including status.conditions and status.observedGeneration. If observedGeneration lags metadata.generation, the controller never processed your edit and the cause is upstream of this field.
3. Whether spec.security.networkPolicy.enabled was explicitly set, and whether an OpenClawClusterDefaults singleton exists in that cluster.

Also worth flagging since it touches the same code: #590 changes this area. Application allowlists (allowedIngressNamespaces/allowedIngressCIDRs) no longer grant the metrics port — that moves to a dedicated spec.networking.metricsIngress block (#578). Your ingress rules for application traffic are unaffected.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If this issue is still relevant, please leave a comment or remove the stale label.