feat(chart): add opt-in NetworkPolicy for the Topograph release

[resker]

Description

Adds an opt-in NetworkPolicy (networkPolicy.enabled, default false) covering all three chart components, so the chart can provision the network access its own workloads need on clusters that enforce a default-deny posture. Closes #383.

The policy selects the whole release by instance label. When enabled:

• Ingress — denied except intra-release traffic (so the node-observer can reach the API server) and the Prometheus scrape namespace when serviceMonitor.enabled.
• Egress — left unconstrained until extraEgress is set, so enabling the policy cannot break egress on clusters without a default-deny. When extraEgress is set, an Egress policyType is added with DNS and intra-release allows plus the supplied rules.

Because Kubernetes NetworkPolicy egress cannot target hostnames, the kube-apiserver and the provider's topology-source endpoint are operator-supplied via extraEgress (required under default-deny). Rather than auto-derive these per provider (their endpoints are hostnames/URLs, not addressable in a portable policy), the chart stays generic and docs/engines/k8s.md includes a per-provider egress table. extraIngress appends custom ingress rules.

Validation

• make chart-test green. helm-unittest covers off-by-default, the whole-release podSelector, the Prometheus ingress rule, and the egress shape.
• On a representative Kubernetes cluster (Calico CNI) with a namespaced default-deny NetworkPolicy: helm test succeeds under deny-all (release pods reach the API server), while a non-release pod is correctly blocked — confirming the intra-release allows are both sufficient and enforcing.

Note: the red govulncheck check is the pre-existing repo-wide stdlib advisory (GO-2026-5856), not from this chart-only PR; it clears on a rebase once #390 lands. All other checks are green.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.
• All commits are signed off per DCO (git commit -s).

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pull-request-393.docs.buildwithfern.com/topograph

[greptile-apps]

Greptile Summary

This PR adds an opt-in NetworkPolicy to the Topograph Helm chart. The main changes are:

• A new chart template for release-wide ingress and optional egress policy.
• New values and schema entries for custom ingress, egress, and DNS selector configuration.
• Helm unit tests for default rendering, Prometheus ingress, egress, and custom DNS selectors.
• Kubernetes engine docs and changelog updates for NetworkPolicy usage.

Confidence Score: 4/5

This is close, but the NetworkPolicy validation gaps should be fixed before merging.

• Empty-effective custom rules can still render into broad allow rules.
• An explicit empty DNS selector can broaden the DNS egress allow beyond DNS pods.
• The main render paths are covered, but these boundary cases still need enforcement.

charts/topograph/values.schema.json and charts/topograph/templates/networkpolicy.yaml

Security Review

The NetworkPolicy still has two security-boundary gaps: empty-effective custom rules can open traffic broadly, and an explicit empty DNS selector can allow DNS-port egress to all kube-system pods.

Important Files Changed

Filename	Overview
charts/topograph/templates/networkpolicy.yaml	Adds the NetworkPolicy template, including release-wide selection, ingress allows, optional egress, and DNS selector rendering.
charts/topograph/values.schema.json	Adds schema support for the new NetworkPolicy values and custom rule arrays.
charts/topograph/values.yaml	Documents defaults and examples for enabling the policy, setting custom DNS selectors, and supplying egress rules.
charts/topograph/tests/networkpolicy_test.yaml	Adds Helm tests for the main NetworkPolicy render paths.
docs/engines/k8s.md	Documents the chart policy, default-deny behavior, provider egress targets, and DNS selector override.

_{Reviews (4): Last reviewed commit: "feat(chart): make NetworkPolicy DNS pod ..." | Re-trigger Greptile}

[greptile-apps]

Empty rules still pass

minProperties: 1 rejects only the literal {} case. A rule like networkPolicy.extraIngress: [{ ports: [] }] or networkPolicy.extraEgress: [{ ports: [] }] still has one property, passes schema validation, and is rendered into the policy. With no effective peers or ports, Kubernetes can treat the rule as open traffic in that direction, so the intended deny policy can still be bypassed with schema-valid values. Please validate that custom rules contain the required non-empty from/to and/or ports fields for the direction being configured.

[greptile-apps]

Empty-effective rules pass minProperties: 1 only rejects the literal {} case. Values such as extraIngress: [{ from: [] }], extraIngress: [{ ports: [] }], extraEgress: [{ to: [] }], or extraEgress: [{ ports: [] }] still pass schema validation and render verbatim. Kubernetes treats empty or omitted from/to as all sources or destinations, and empty or omitted ports as all ports, so these values can still open the selected pods to broad ingress or egress. Please validate the effective rule shape for each direction, not only that the rule object has one key.

[greptile-apps]

Empty selector broadens DNS An explicit networkPolicy.dnsPodSelector: {} override bypasses this fallback and renders an empty matchLabels under the DNS podSelector. Kubernetes treats an empty pod selector as matching every pod in the selected namespace, so the DNS egress rule allows TCP and UDP 53 to any kube-system pod instead of only DNS pods. Please reject an empty DNS selector or treat it the same as unset before rendering.

[dmitsh]

This example combines the Kubernetes Service IP with the usual control-plane endpoint port. In-cluster client-go uses KUBERNETES_SERVICE_HOST/KUBERNETES_SERVICE_PORT, normally the Service IP on 443; kubectl get endpoints returns an endpoint IP normally on 6443. Depending on where the CNI evaluates policy relative to DNAT, operators may need either Service-IP:443 or endpoint-IP:6443, but Service-IP:6443 matches neither path and can leave all three components unable to reach the API after Egress isolation is enabled. Please correct this example and explain the CNI-dependent alternative consistently with the docs example/table.

[dmitsh]

When ingress.enabled or gatewayAPI.enabled is used, requests normally originate from an ingress/gateway controller in another namespace. This policy permits only same-release pods and, conditionally, the ServiceMonitor namespace, so enabling networkPolicy makes those chart-provided routes unreachable unless the operator happens to add the correct extraIngress rule. Since the controller selector is cluster-specific, please at least document this required extraIngress configuration beside the Ingress/HTTPRoute guidance and add combination tests; otherwise two supported chart features silently conflict.

[dmitsh]

serviceMonitor.namespace controls where the ServiceMonitor object is created, not necessarily the namespace of the Prometheus pod that performs the scrape. A central Prometheus can watch ServiceMonitors in other namespaces, so this selector can still block metrics even though serviceMonitor.enabled is correctly configured. Please use a separately configurable scraper namespace/selector (or require extraIngress and document it) rather than treating the ServiceMonitor resource namespace as the traffic source.