feat!: NetworkPolicy in the last five charts - the sweep is complete

matrix-synapse, paperless-ngx, freesailarr, valkey, stalwart. One major each.
All 29 installable charts plus template-chart now render a policy, and
ci/run-networkpolicy-test.sh passes over all 30 with 206 assertions held.

MATRIX-SYNAPSE renders TWO policies, one per workload, and the split is the
decision in that file. Synapse federates - it must be able to reach any
homeserver on the internet, so 443 and 8448 go to any destination - while the
delegation nginx serves two static JSON documents and calls nobody, so its
egress is DNS and nothing else. A single policy over both pods would have to
permit the union, handing full federation reach and the database port to an
nginx whose job is to return a constant, and it would read as one decision
rather than as a widening. networkPolicy.egress.extraPorts deliberately does
not reach the delegation policy for the same reason.

PAPERLESS-NGX names the two pods of its own release that this object does NOT
cover: the valkey subchart's pod, which carries its own labels and needs no
cover because the valkey chart ships a tighter policy of its own; and the
consume CronJob's pods, whose pod template carries NO LABELS AT ALL, so no
podSelector can match them. That second one is a real gap in the convention. It
is tolerable only because the job moves files between mounted volumes and
reaches the SMB share through a CSI volume the node mounts - the pod opens no
connection of its own - and if that ever changes the CronJob needs labels
before it can need a policy.

FREESAILARR is ten containers in one pod behind a VPN, and simpler than that
sounds: they share a network namespace, so all inter-container traffic is
localhost and no policy sees any of it. Because the namespace belongs to
gluetun, everything the *arr containers send is encapsulated before it leaves,
so three rules describe the whole outbound surface - DNS, UDP 51820 for the
tunnel, and 443 for gluetun's server-list API, which cannot go through the
tunnel because it runs before the tunnel exists. The tunnel rule is the one
that can break this chart and also the best covered: gluetun's health server
answers 200 only while the tunnel is up and all three of its probes address it,
so a blocked 51820 is a pod that never goes Ready - in the install-test, which
brings up a real tunnel.

VALKEY AND STALWART, the two charts that had a policy before this issue, are
pulled onto the convention without a single rule changing. What changed:

  - the reasoning moved out of "#" comments, which are part of the rendered
    object and travel into the cluster, into template comments. Both files
    failed the new check; that is what it is for.
  - stalwart gains networkPolicy.ingressController, which fixes a hole its own
    comment described without being able to solve: it advised putting the
    controller's namespace into allowedNamespaces, which is namespace-granular
    and would have opened the http port to every pod in kube-system.
  - stalwart's example was WRONG and is corrected. It suggested
    ["ingress-nginx"]; measured on 2026-10-14, ingress-nginx is gone from this
    cluster entirely and the controller is rke2-traefik in kube-system. A policy
    written against the old one would have been accepted, looked strict, and
    silently blocked all web traffic.

Their justified specifics are untouched: valkey stays Ingress-only, because it
opens no outbound connection and an egress rule would constrain nothing while
making the object look stricter; and it keeps 6379 restricted by source with no
probeSources at all, which is safe only because all three of its probes are
exec probes and put no packet on the network. The convention was written to
accommodate both, and homeassistant and satisfactory now invoke valkey's rule
in the other direction.

ONE CHANGE TO THE TEST, forced by a structural fact rather than by convenience:
the rendered-comment assertion now skips documents from a SUBCHART. A
dependency is fetched from the Helm registry, not from the copy in this
repository, so the policy paperless-ngx and stalwart bundle is whatever valkey
version is PUBLISHED - and nothing in the parent chart can change its rendered
comments. Holding the parent responsible would have made the test unfixable
until valkey's next release and would fail a chart for a file its own diff does
not contain. The subchart's own pull request is where it is caught, because this
test runs over every chart including valkey itself. All twelve failure paths
were re-run against the change.

Part of #5

freesailarr/templates/NOTES.txt

@@ -418,3 +418,72 @@ MORE THAN ONE REPLICA IS NOT MEANINGFUL
   config volumes, all of them fighting over the same media claims and the same
   VPN credentials.
 {{- end }}
+{{- if .Values.networkPolicy.enabled }}
+
+NETWORKPOLICY IS ACTIVE — WHAT IT CAPS, AND WHAT IT DOES NOT
+  {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy selects this workload's pods.
+  Inbound: the nine probed ports — gluetun's health server (9999) and the eight
+  web interfaces (8080, 9696, 8191, 7878, 8989, 5055, 6767, 5007) — plus
+  mediathekarr's newznab port (5008), which is RESTRICTED by source because
+  nothing probes it and its only consumer is Prowlarr in this same pod.
+  Outbound: DNS, UDP 51820 (the WireGuard tunnel) and TCP 443 (gluetun's
+  server-list API){{ with .Values.networkPolicy.egress }}{{ with .extraPorts }}, plus TCP {{ join ", " . }}{{ end }}{{ end }}.
+
+  THE TEN CONTAINERS TALK TO EACH OTHER OVER LOCALHOST, so none of that traffic
+  is governed by this object at all — they share a network namespace. And
+  because that namespace belongs to gluetun, everything the *arr containers
+  send is encapsulated into the tunnel before it leaves the pod: indexer and
+  tracker traffic needs no egress rule of its own.
+
+  IF THIS POD WILL NOT BECOME READY, SUSPECT THE TUNNEL RULE. gluetun's health
+  server answers 200 only while the tunnel is up, and all three of its probes
+  address it, so a blocked UDP 51820 shows up as a pod that never goes Ready
+  rather than as a network error. 51820 is WireGuard's and Mullvad's standard
+  port; Mullvad also offers 53, 123, 500 and 4500 for obfuscation, and a
+  release on one of those has to widen the rule in the template —
+  networkPolicy.egress.extraPorts is TCP only.
+
+  AND IF SEERR CANNOT REACH AN IN-CLUSTER SERVICE (Jellyfin, say), two things
+  have to be true, not one: its port in networkPolicy.egress.extraPorts, and
+  gluetun.vpn.firewallOutboundSubnets set — gluetun's own firewall blocks
+  cluster-internal egress before this policy is ever consulted.
+
+  Three limits belong in the same breath, because none of them is visible in
+  the object itself:
+
+  - EGRESS IS BY PORT, NEVER BY DESTINATION. A NetworkPolicy matches CIDRs and
+    selectors and cannot express a hostname, so every egress rule permits its
+    port to ANY address. That is a limit of the object, not a shortcut — this
+    cluster's CNI (Canal: Flannel plus Calico) has no FQDN rule either. An
+    outbound port the chart does not know about is BLOCKED: add it to
+    networkPolicy.egress.extraPorts, and expect to find out through an
+    application-level connection error rather than through this object.
+{{- if .Values.networkPolicy.probeSources }}
+  - THE PROBE PATH IS RESTRICTED in this release, because
+    networkPolicy.probeSources is set to
+      {{ join ", " .Values.networkPolicy.probeSources }}
+    Probes come from the IP of the WORKER NODE running the pod. If none of those
+    CIDRs covers the node this pod lands on, the kubelet's probes are dropped
+    and THE POD NEVER BECOMES READY — the rollout then times out and the symptom
+    looks like a broken application. Compare
+
+      kubectl -n {{ .Release.Namespace }} describe pod -l app={{ .Release.Name }}-{{ .Chart.Name }}-sfs
+
+    against `kubectl get node -o wide`.
+{{- else }}
+  - THE PROBED PORT IS OPEN INSIDE THE CLUSTER. networkPolicy.probeSources is
+    empty, so that rule carries no source selector at all and any pod the CNI
+    routes to can reach it. Not from the internet — but this is NOT pod-level
+    isolation. Narrowing it means listing the worker node IPs in
+    networkPolicy.probeSources, because the kubelet probes from the node's own
+    address and the chart cannot know it; a wrong guess there leaves the pod
+    permanently un-Ready.
+{{- end }}
+  - IT IS ONLY A BOUNDARY WHERE THE CNI ENFORCES POLICIES. Where it does not,
+    this object is accepted and filters nothing, so everything reads as
+    configured while nothing is filtered. `kubectl -n {{ .Release.Namespace }} get networkpolicy`
+    shows the object exists; only a connection attempt from an unrelated
+    namespace shows that it bites.
+
+  Switch it off with networkPolicy.enabled: false.
+{{- end }}

freesailarr/templates/freesailarr.networkpolicy.yaml

@@ -0,0 +1,253 @@
+{{- /*
+NetworkPolicy for freesailarr (Gitea #5).
+
+TEN CONTAINERS IN ONE POD, BEHIND A VPN, AND THE POLICY IS SIMPLER THAN THAT
+SOUNDS - for one reason worth stating first: the containers talk to each other
+over LOCALHOST. They share a network namespace, so none of that traffic ever
+reaches a network interface and NO NetworkPolicy has anything to say about it.
+Prowlarr reaching Radarr, Recyclarr reaching Sonarr, every one of those hops is
+invisible here. What this policy governs is only what enters or leaves the pod.
+
+INBOUND is the eight published web interfaces plus gluetun's health server, and
+almost all of them are probe ports - the kubelet opens an HTTP connection to
+each container's own interface - so they are one rule on the probe path. The
+newznab port of mediathekarr is the exception: nothing probes it, and its only
+consumer is Prowlarr in this same pod over localhost, so it is restricted by
+source and that costs nothing.
+
+OUTBOUND IS WHERE THIS CHART IS UNLIKE EVERY OTHER ONE HERE, because the pod's
+network namespace belongs to gluetun. Every connection the *arr containers make
+goes into the WireGuard tunnel and leaves the pod as UDP to the VPN endpoint -
+so a NetworkPolicy sees the OUTER packets and almost nothing else. Three rules
+cover it: DNS, UDP 51820 for the tunnel itself, and 443 for gluetun's own
+server-list API. Indexer and tracker traffic needs no rule of its own; it is
+already inside the tunnel.
+
+AND THE TUNNEL RULE IS THE ONE THAT CAN BREAK THIS CHART, which is also why it
+is well covered: gluetun's health server returns 200 only while the tunnel is
+up, and all three of its probes address it. A blocked UDP 51820 therefore means
+a pod that never becomes Ready - visibly, in the install-test, which brings up
+a real tunnel. 51820 is WireGuard's standard port and Mullvad's; Mullvad also
+offers 53, 123, 500 and 4500 for obfuscation, and a release using one of those
+needs networkPolicy.egress.extraPorts. Note that extraPorts is TCP only, so an
+alternative UDP port needs the rule here widened instead - said plainly,
+because it is a limit of the shared values shape and not an oversight.
+
+WHAT THIS OBJECT IS: a ceiling on reachability, not an authentication layer.
+Only the ports declared below are reachable at all - whatever else the process
+binds, now or after the next app update, is blocked without anyone having to
+notice it exists.
+
+WHAT IT IS NOT:
+  - EGRESS IS COARSE. A NetworkPolicy matches CIDRs and selectors and NEVER
+    hostnames, so "only to the database host" cannot be expressed at all. This
+    cluster's CNI is Canal (Flannel plus Calico for policy) and has no FQDN
+    rule; Calico's GlobalNetworkSet could express one but would bind this chart
+    to Calico, the same argument that kept implementation-specific objects out
+    of the Gateway-API sweep (#114). Each egress rule therefore permits its
+    PORT to any destination.
+  - NOT A BOUNDARY WHERE THE CNI DOES NOT ENFORCE ONE. An unenforced policy is
+    accepted by the API server and filters nothing, so everything reads as
+    configured while nothing is filtered.
+  - THE REASONING IS IN TEMPLATE COMMENTS, not in "#" comments: those are part
+    of the rendered object, travel into the cluster and appear in every release
+    diff. ci/run-networkpolicy-test.sh fails on a rendered "#".
+
+THE PORT NUMBERS BELOW ARE POD PORTS, NEVER NODEPORTS. A NetworkPolicy is
+evaluated at the pod's network interface, after kube-proxy has already
+translated a NodePort to the targetPort, so a NodePort number here would match
+nothing while looking strict - and, being the only rule for that port, would
+block every inbound connection instead. ci/run-networkpolicy-test.sh asserts
+every port here against the containerPorts of the pod spec this policy
+selects.
+*/ -}}
+{{- if .Values.networkPolicy.enabled }}
+{{- $np := .Values.networkPolicy }}
+{{- $ns := .Release.Namespace }}
+{{- $probeSources := $np.probeSources | default list }}
+{{- $allowedNs := $np.allowedNamespaces | default list }}
+{{- $ic := $np.ingressController | default dict }}
+{{- $routed := or .Values.ingress.enabled .Values.httpRoute.enabled }}
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+  labels:
+    app: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+spec:
+  {{- /*
+  Selects the StatefulSet's pods. ci/run-networkpolicy-test.sh fails if
+  this matches no pod spec of the same render - which is the mistake that
+  would otherwise leave a policy in the namespace filtering nothing, and
+  its usual cause is a label renamed in the workload template.
+  */}}
+  podSelector:
+    matchLabels:
+      app: {{ .Release.Name }}-{{ .Chart.Name }}-sfs
+  policyTypes:
+    - Ingress
+    {{- /*
+    Egress is listed, and for this chart it is unusually meaningful: because the
+    pod's network namespace belongs to gluetun, the only things that leave it are
+    the tunnel, DNS and gluetun's control-plane calls. Everything the applications
+    do is encapsulated. So three narrow rules really do describe the pod's whole
+    outbound surface - which is rare here.
+    */}}
+    - Egress
+  ingress:
+    {{- /*
+    THE PROBE PATH, nine ports of it. gluetun's health server (9999) plus the eight
+    web interfaces the kubelet probes directly: qBittorrent (8080), Prowlarr
+    (9696), FlareSolverr (8191), Radarr (7878), Sonarr (8989), Seerr (5055), Bazarr
+    (6767) and Mediathekarr (5007). Every one of them is addressed by at least one
+    httpGet probe, so none of them can be restricted by source without the worker
+    node's IP.
+
+    Recyclarr is absent from this list on purpose: it declares no port and its
+    probes are exec probes, so there is nothing to allow.
+    */}}
+    - ports:
+        - protocol: TCP
+          port: 9999
+        - protocol: TCP
+          port: 8080
+        - protocol: TCP
+          port: 9696
+        - protocol: TCP
+          port: 8191
+        - protocol: TCP
+          port: 7878
+        - protocol: TCP
+          port: 8989
+        - protocol: TCP
+          port: 5055
+        - protocol: TCP
+          port: 6767
+        - protocol: TCP
+          port: 5007
+      {{- if $probeSources }}
+      {{- /*
+      RESTRICTED, because the operator supplied probeSources. The kubelet's probes
+      come from the IP of the WORKER NODE running the pod, so that address has to be
+      in the list or the pod never becomes Ready - and a pod that is never Ready
+      reads as a broken application rather than as a policy.
+
+      The ingress controller is added to the same rule - this chart renders TWO
+      Ingresses, the main one and qBittorrent's, and both go dark the moment this
+      list is filled without it.
+      */}}
+      from:
+        - namespaceSelector:
+            matchLabels:
+              {{- /*
+              Set by Kubernetes itself on every namespace (>= 1.21), so this needs no
+              labelling work on a namespace this chart does not own.
+              */}}
+              kubernetes.io/metadata.name: {{ $ns }}
+        {{- if and $routed $ic.namespace }}
+        {{- /*
+        ONE from-entry with TWO selectors, which is an AND: pods carrying these labels
+        IN that namespace. Written as two list entries it would be an OR, and would
+        open the port to every pod in kube-system.
+        */}}
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: {{ $ic.namespace | quote }}
+          {{- with $ic.podLabels }}
+          podSelector:
+            matchLabels:
+              {{- toYaml . | nindent 14 }}
+          {{- end }}
+        {{- end }}
+        {{- range $allowedNs }}
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: {{ . | quote }}
+        {{- end }}
+        {{- range $probeSources }}
+        - ipBlock:
+            cidr: {{ . | quote }}
+        {{- end }}
+      {{- else }}
+      {{- /*
+      NO "from" SELECTOR, WHICH MEANS OPEN - deliberately, and only inside the
+      cluster, because this port carries no NodePort. The alternative was to guess
+      the worker node CIDRs, and a wrong guess blocks every kubelet probe: the pod
+      stays un-Ready, the rollout times out, and the cause looks like the
+      application. An empty "from: []" would be worse than either - it allows
+      everything too, but while reading as a restriction. Narrow it with
+      networkPolicy.probeSources.
+      */}}
+      {{- end }}
+    {{- /*
+    MEDIATHEKARR'S NEWZNAB PORT, and the one inbound port here that can be
+    restricted: no probe addresses it. Its only consumer is Prowlarr, which runs in
+    THIS pod and reaches it over localhost - traffic no NetworkPolicy sees at all -
+    so restricting this rule to the release's own namespace plus allowedNamespaces
+    costs nothing and removes a port from the cluster's reach.
+    */}}
+    - ports:
+        - protocol: TCP
+          port: 5008
+      from:
+        - namespaceSelector:
+            matchLabels:
+              {{- /*
+              Set by Kubernetes itself on every namespace (>= 1.21), so this needs no
+              labelling work on a namespace this chart does not own.
+              */}}
+              kubernetes.io/metadata.name: {{ $ns }}
+        {{- range $allowedNs }}
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: {{ . | quote }}
+        {{- end }}
+  egress:
+    {{- /*
+    DNS, unconditionally. There is no value to switch this off, and that is
+    deliberate: a knob whose only other setting breaks every name lookup in
+    the pod is a trap and not a feature.
+    */}}
+    - ports:
+        - protocol: UDP
+          port: 53
+        - protocol: TCP
+          port: 53
+    {{- /*
+    THE WIREGUARD TUNNEL, and the rule this chart cannot live without. Everything
+    the *arr containers do leaves the pod inside this tunnel, so blocking it
+    blocks all of them at once - and gluetun's health server, which all three of
+    its probes address, returns 200 only while the tunnel is up. The pod would
+    never become Ready.
+
+    51820 is WireGuard's standard port and Mullvad's. Mullvad also offers 53, 123,
+    500 and 4500 for obfuscation; a release using one of those must widen THIS rule,
+    because networkPolicy.egress.extraPorts is TCP only.
+    */}}
+    - ports:
+        - protocol: UDP
+          port: 51820
+    {{- /*
+    Outbound HTTPS, for gluetun's own control-plane traffic: it fetches and caches
+    the provider's server list over the API before the tunnel exists, so this
+    cannot go through the tunnel. Indexer and tracker traffic does NOT need a rule
+    here - it is already inside the tunnel by the time it leaves the pod.
+    */}}
+    - ports:
+        - protocol: TCP
+          port: 443
+    {{- with $np.egress }}
+    {{- with .extraPorts }}
+    {{- /*
+    Ports only, to any destination - see the header. This is the operator's
+    escape hatch from the egress cap, and the only alternative to switching
+    the whole policy off.
+    */}}
+    - ports:
+        {{- range . }}
+        - protocol: TCP
+          port: {{ int . }}
+        {{- end }}
+    {{- end }}
+    {{- end }}
+{{- end }}