fix: disable argo-helm 10.x default NetworkPolicies

[venkatamutyala]

Problem

argo-helm chart 10.0.0 (released 2026-06-26) flipped global.networkPolicy.create from false to true. Its entire changelog entry for this is:

artifacthub.io/changes: |
  - kind: fixed
    description: Enable network policies for all components by default

Filed as kind: fixed, despite flipping every Argo CD component to default-deny ingress.

v0.23.0 (#67) moved these values to chart 10.2.2 and set networkPolicy.create: true explicitly — which matches the new chart default, so the policies ship either way.

Each generated policy sets policyTypes: [Ingress], which makes the selected pod default-deny and re-opens only what it lists. The metrics allow-rules are written as:

- from:
  - namespaceSelector: {}
  ports:
  - port: metrics      # by NAME, and no protocol

On a GlueOps cluster those rules do not take effect.

Impact, measured on a live cluster

Prometheus went from 75 up / 7 down, with every failure an Argo CD metrics endpoint:

target	port	result
argocd-application-controller-metrics	8082	connection refused
argocd-repo-server-metrics	8084	connection refused (×4 pods)
argocd-applicationset-controller-metrics	8080	connection refused
argocd-notifications-controller-metrics	9001	connection refused

argocd-server-metrics:8083 stayed up — its policy renders as ingress: [{}], a blanket allow, so it restricts nothing.

Worth noting the failure mode is connection refused, not a timeout, which reads like "nothing is listening" and sent the first round of diagnosis down the wrong path. This CNI rejects with RST rather than dropping.

Verification

helm upgrade --reuse-values --set global.networkPolicy.create=false on a live cluster. Dry-run diff first: the only change is the removal of the 5 NetworkPolicy objects (152 lines), nothing else.

Result: 82 up / 0 down. Every Argo CD target recovered on the same pod IPs that were refusing connections, and no pod restarted — so the metrics servers had been listening the whole time and the policies were blocking them. All Applications stayed Synced/Healthy.

Why false rather than fixing the rule

The rule is hardcoded in the chart template — no value reshapes it — and it is byte-identical in the latest chart, 10.9.2, so upgrading does not help. The per-component toggles are or'd with the global one (if or .Values.X.networkPolicy.create .Values.global.networkPolicy.create), so a component-level false cannot override a global true.

Chart 9.3.7 defaulted to false, so this preserves the behaviour every existing cluster already runs rather than changing it. It also decouples two unrelated risks currently bundled together: upgrading Argo CD 3.2.12 → 3.4.9, and introducing default-deny NetworkPolicies across every component — the latter arriving silently via a chart default, during a Kubernetes 1.35 platform upgrade, while removing the alerting you would use to catch problems.

Follow-up (not this PR)

Re-enabling is worth doing deliberately. repo-server is the policy with real value: it restricts port 8081 — which holds repository credentials and executes Helm/Kustomize rendering — to the four Argo CD components. The shape to aim for is create: true plus a supplemental allow-policy via extraObjects for the metrics ports by number, with scrape targets verified before rollout.

Also worth knowing: these policies are Ingress-only. There are no egress restrictions on Argo CD, which is one of the highest-privilege workloads in the cluster.

Related

Upstream has a recurring pattern of these policies breaking metrics and webhooks: argoproj/argo-helm#3431 → #3501, #3678 → #3681, #3915 → #3930, #3948 → #3950, #3569.

Blocks/relates to GlueOps/terraform-module-cloud-multy-prerequisites#741, which pins docs-argocd v0.23.0.

🤖 Generated with Claude Code