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

stalwart/Chart.yaml

@@ -28,7 +28,7 @@ type: application
 # ci/stalwart/test-values.yaml as it stands on origin/main - measured, both
 # empty diffs. New optional values with unchanged defaults is exactly the minor
 # case (README, "Versioning").
-version: 1.3.0+upv0.16.25
+version: 2.0.0+upv0.16.25
 appVersion: "v0.16.25"
 
 maintainers:

stalwart/templates/stalwart.networkpolicy.yaml

@@ -1,15 +1,41 @@
 {{- /*
-One NetworkPolicy per node group.
+One NetworkPolicy per node group (Gitea #5).
+
+THIS CHART AND valkey ARE THE TWO THAT HAD A POLICY BEFORE #5, so the
+convention was derived from them rather than imposed on them. Three things
+changed here; everything else is the original and is right.
+
+  - THE REASONING MOVED OUT OF "#" COMMENTS into template comments. A "#"
+    comment is part of the RENDERED object: it travels into the cluster, shows
+    up in `helm get manifest` and `kubectl get -o yaml`, and lands in every
+    release diff. ci/run-networkpolicy-test.sh now fails on a rendered "#", and
+    this file was one of the two that failed it.
+  - networkPolicy.ingressController ARRIVED, and it fixes a real hole this
+    file's own comment described without being able to solve: it used to say
+    that setting probeSources means putting the ingress controller's namespace
+    into allowedNamespaces "or the Ingress goes dark". That works, but
+    allowedNamespaces is namespace-granular, so it would have opened the http
+    port to EVERY pod in the controller's namespace - kube-system, here. The
+    new value renders a namespaceSelector and a podSelector in ONE from-entry,
+    which is an AND, and narrows the source to the controller's pods.
+  - THE EXAMPLE IN values.yaml WAS WRONG AND IS CORRECTED. It suggested
+    allowedNamespaces: ["ingress-nginx"]. Measured on 2026-10-14: ingress-nginx
+    is GONE from this cluster - no DaemonSet, no pods - the only IngressClass is
+    traefik, and the controller is the DaemonSet rke2-traefik in kube-system. A
+    policy written against the old controller would have been accepted, would
+    have looked strict, and would have silently blocked all web traffic.
+
+WHAT DID NOT CHANGE, because it is the reason this file was the model:
 
 This object is the CEILING ON REACHABILITY, and that is its real job here: it
-holds no matter which ports the process actually bound. A node whose
-ClusterRole is missing from the database fail-opens into a full node and binds
-every listener - including IMAP and the admin interface on a group meant to
-take SMTP only - while staying Running with a green probe. The per-port
-Services publish only what was asked for, and this policy is the second,
-independent limit. See values.yaml for the source-level detail.
+holds no matter which ports the process actually bound. A node whose ClusterRole
+is missing from the database fail-opens into a full node and binds every
+listener - including IMAP and the admin interface on a group meant to take SMTP
+only - while staying Running with a green probe. The per-port Services publish
+only what was asked for, and this policy is the second, independent limit. See
+values.yaml for the source-level detail.
 
-!!! THE PORT NUMBERS HERE ARE POD PORTS (25/465/993/8080), NOT NODEPORTS !!!
+THE PORT NUMBERS HERE ARE POD PORTS (25/465/993/8080), NOT NODEPORTS.
 
 This is the easiest mistake to make in this chart, so it is spelled out. A
 NetworkPolicy is evaluated at the POD's network interface, after kube-proxy has
@@ -17,6 +43,8 @@ already translated the NodePort to the targetPort. Writing 30025 here would
 match nothing: the packet arrives at the pod on 25. The policy would then look
 strict, be accepted by the API server, and silently block every inbound
 connection - or, if it is the only rule, block the lot.
+ci/run-networkpolicy-test.sh now asserts this mechanically, against the
+containerPorts of the pod spec each policy selects.
 
 Egress is restricted BY PORT and not by destination, because a NetworkPolicy
 matches CIDRs and selectors and never hostnames - so dataStore.postgres.host
@@ -32,6 +60,7 @@ unenforced policy is accepted and filters nothing.
 {{- $egress := .Values.networkPolicy.egress -}}
 {{- $probeSources := .Values.networkPolicy.probeSources | default list -}}
 {{- $allowedNs := .Values.networkPolicy.allowedNamespaces | default list -}}
+{{- $ic := .Values.networkPolicy.ingressController | default dict -}}
 {{- range $group, $spec := fromYaml (include "stalwart.nodes" .) }}
 {{- $name := printf "%s-%s" (include "stalwart.fullname" $root) $group }}
 ---
@@ -49,9 +78,11 @@ spec:
     - Ingress
     - Egress
   ingress:
-    {{- /* The public mail ports: open to any source. They have to be - the
-           senders are the whole internet, and after NodePort masquerading the
-           source address is a control-plane node anyway. */}}
+    {{- /*
+    The public mail ports: open to any source. They have to be - the senders are
+    the whole internet, and after NodePort masquerading the source address is a
+    control-plane node anyway.
+    */}}
     {{- $publicPorts := list }}
     {{- range $portName := $spec.exposedPorts }}
     {{- $port := index $ports $portName }}
@@ -61,7 +92,10 @@ spec:
     - ports:
         {{- range $portName := $publicPorts }}
         {{- $port := index $ports $portName }}
-        # {{ $portName }}: published on nodePort {{ int $port.nodePort }}, reaching the pod on {{ int $port.containerPort }}
+        {{- /*
+        {{ $portName }}: published on a nodePort, reaching the pod on
+        {{ int $port.containerPort }} - which is the number that belongs here.
+        */}}
         - protocol: {{ $port.protocol | default "TCP" }}
           port: {{ int $port.containerPort }}
         {{- end }}
@@ -72,17 +106,38 @@ spec:
         - protocol: {{ $http.protocol | default "TCP" }}
           port: {{ int $http.containerPort }}
       {{- if or $probeSources $allowedNs }}
-      # Restricted because networkPolicy.probeSources or .allowedNamespaces is
-      # set. MIND THE KUBELET: probes come from the IP of the worker node
-      # running the pod, so that address has to be in probeSources or the pod
-      # never becomes Ready - and a pod that is never Ready reads as a broken
-      # application rather than as a policy.
+      {{- /*
+      Restricted because networkPolicy.probeSources or .allowedNamespaces is
+      set. MIND THE KUBELET: probes come from the IP of the worker node running
+      the pod, so that address has to be in probeSources or the pod never
+      becomes Ready - and a pod that is never Ready reads as a broken
+      application rather than as a policy.
+      */}}
       from:
         - namespaceSelector:
             matchLabels:
-              # Set by Kubernetes itself on every namespace (>= 1.21), so this
-              # needs no labelling work.
+              {{- /*
+              Set by Kubernetes itself on every namespace (>= 1.21), so this
+              needs no labelling work.
+              */}}
               kubernetes.io/metadata.name: {{ $root.Release.Namespace }}
+        {{- if $ic.namespace }}
+        {{- /*
+        The ingress controller, as ONE from-entry with TWO selectors - which is
+        an AND: those pods in that namespace. Written as two list entries it
+        would be an OR and would open the http port to every pod in the
+        controller's namespace. This is what replaced the old advice of putting
+        kube-system into allowedNamespaces.
+        */}}
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: {{ $ic.namespace | quote }}
+          {{- with $ic.podLabels }}
+          podSelector:
+            matchLabels:
+              {{- toYaml . | nindent 14 }}
+          {{- end }}
+        {{- end }}
         {{- range $allowedNs }}
         - namespaceSelector:
             matchLabels:
@@ -93,12 +148,18 @@ spec:
             cidr: {{ . | quote }}
         {{- end }}
       {{- else }}
-      # NO "from" SELECTOR, WHICH MEANS OPEN - deliberately, and only inside
-      # the cluster: http carries no nodePort, so nothing outside reaches it
-      # through this chart. The alternative was to guess the worker node CIDRs,
-      # and a wrong guess blocks every kubelet probe. Narrow it by setting
-      # networkPolicy.probeSources (and then .allowedNamespaces for the
-      # ingress controller, or the Ingress goes dark).
+      {{- /*
+      NO "from" SELECTOR, WHICH MEANS OPEN - deliberately, and only inside the
+      cluster: http carries no nodePort, so nothing outside reaches it through
+      this chart. The alternative was to guess the worker node CIDRs, and a
+      wrong guess blocks every kubelet probe. Narrow it by setting
+      networkPolicy.probeSources; the ingress controller is then added from
+      networkPolicy.ingressController, so the Ingress does not go dark.
+
+      Note that an empty "from: []" would be worse than no key at all: it also
+      allows everything, but while reading as a restriction.
+      ci/run-networkpolicy-test.sh rejects that form.
+      */}}
       {{- end }}
   egress:
     {{- if $egress.dns }}
@@ -109,10 +170,12 @@ spec:
           port: 53
     {{- end }}
     {{- if $egress.smtp }}
-    # Outbound delivery: port 25 on any host on the internet. Uniform for every
-    # group on purpose - the chart does not know which groups run the
-    # outboundMta task, the value would drift away from the database, and the
-    # failure mode of getting it wrong is mail silently not leaving.
+    {{- /*
+    Outbound delivery: port 25 on any host on the internet. Uniform for every
+    group on purpose - the chart does not know which groups run the outboundMta
+    task, the value would drift away from the database, and the failure mode of
+    getting it wrong is mail silently not leaving.
+    */}}
     - ports:
         - protocol: TCP
           port: 25
@@ -125,8 +188,12 @@ spec:
     {{- range $root.Values.networkPolicy.egress.extraPorts }}
     {{- $outPorts = append $outPorts (int .) }}
     {{- end }}
-    # The data store, the blob store, the in-memory store and anything added
-    # through networkPolicy.egress.extraPorts. Ports only - see the header.
+    {{- /*
+    The data store, the blob store, the in-memory store and anything added
+    through networkPolicy.egress.extraPorts. Ports only - see the header. Unlike
+    most charts in this sweep these are the CONFIGURED ports rather than the
+    standard ones, because this chart holds them as values.
+    */}}
     - ports:
         {{- range $outPorts | uniq }}
         - protocol: TCP

stalwart/values.schema.json

@@ -304,6 +304,20 @@
           "description": "On by default. Only a real boundary where the cluster's CNI enforces NetworkPolicies; an unenforced policy is accepted by the API server and filters nothing.",
           "type": "boolean"
         },
+        "ingressController": {
+          "description": "The ingress controller allowed to reach the http port once probeSources or allowedNamespaces restricts it; with neither set the http rule carries no source selector and the controller reaches the port anyway. The two keys become ONE \"from\" entry and are therefore an AND - pods carrying podLabels IN namespace - which is why this is separate from the namespace-granular allowedNamespaces. The default is measured on this cluster (DaemonSet rke2-traefik in kube-system, which also serves the Gateway API here), not assumed; a policy written against the wrong controller is accepted, looks strict and silently blocks all web traffic.",
+          "type": ["object", "null"],
+          "additionalProperties": false,
+          "properties": {
+            "namespace": {
+              "type": ["string", "null"]
+            },
+            "podLabels": {
+              "description": "Label set the controller's pods carry, rendered verbatim as a podSelector's matchLabels. Kept open because the chart does not interpret the keys.",
+              "type": ["object", "null"]
+            }
+          }
+        },
         "probeSources": {
           "description": "Source CIDRs allowed to reach the http port, where the kubelet's probe traffic has to be permitted - probes come from the IP of the worker node running the pod. EMPTY MEANS OPEN (the rule renders without a 'from' selector), which is the deliberate choice: a guessed CIDR that misses the real node addresses blocks every probe, and a pod that never becomes Ready reads as a broken application rather than as a policy.",
           "type": ["array", "null"],

stalwart/values.yaml

@@ -504,16 +504,43 @@ networkPolicy:
   # (e.g. ["10.0.1.11/32", "10.0.1.12/32"]).
   #
   # And mind the companion trap: once this list is non-empty the http rule is
-  # restricted, which cuts off the ingress controller too unless its namespace
-  # is in allowedNamespaces below.
+  # restricted, which cuts off everything else that needs the port. The chart
+  # adds the release's own namespace, ingressController below and
+  # allowedNamespaces to the same rule for exactly that reason.
   probeSources: []
   # Namespaces allowed to reach the http port, matched on the
   # kubernetes.io/metadata.name label Kubernetes sets on every namespace
-  # itself. The release's own namespace is always allowed. Put the ingress
-  # controller's namespace here (e.g. ["ingress-nginx"]) as soon as
-  # probeSources is set. A name that does not exist matches nothing and is
-  # silently ineffective.
+  # itself. The release's own namespace is always allowed. A name that does not
+  # exist matches nothing and is silently ineffective.
+  #
+  # NOT FOR THE INGRESS CONTROLLER - use ingressController below. This value is
+  # namespace-granular, so naming the controller's namespace here would open
+  # the http port to EVERY pod in it (kube-system, in this cluster). The
+  # earlier version of this comment advised exactly that, with
+  # ["ingress-nginx"] as the example, and both halves of that advice are now
+  # wrong: see ingressController.
   allowedNamespaces: []
+  # The ingress controller allowed to reach the http port once probeSources or
+  # allowedNamespaces restricts it. With neither set the http rule carries no
+  # source selector at all and the controller reaches the port anyway, so this
+  # value only becomes load-bearing at the moment one of them is filled - which
+  # is also the moment the Ingress would otherwise go dark.
+  #
+  # The two keys are rendered as ONE "from" entry, which makes them an AND:
+  # pods carrying podLabels IN namespace. That is the whole point of having
+  # them separate from allowedNamespaces.
+  #
+  # MEASURED ON THIS CLUSTER, NOT ASSUMED (2026-10-14): ingress-nginx is GONE -
+  # no DaemonSet, no pods - the only IngressClass is "traefik" and it is the
+  # default, and the controller is the DaemonSet rke2-traefik in kube-system.
+  # The same Traefik serves the Gateway API here as well. A policy written
+  # against the wrong controller is accepted, looks strict, and silently blocks
+  # all web traffic; ingress.className says nothing about it, because a class
+  # names an implementation and not the pods the traffic comes from.
+  ingressController:
+    namespace: kube-system
+    podLabels:
+      app.kubernetes.io/name: rke2-traefik
   # Egress is restricted BY PORT, not by destination, and the reason is a limit
   # of the object rather than laziness: a NetworkPolicy matches ipBlock CIDRs
   # and pod/namespace selectors, never hostnames — so dataStore.postgres.host