jklein 73c2ec704f 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

2026-10-14 14:46:11 +00:00

..

_helpers.tpl

refactor(stalwart): name the MTA-STS Ingress objects by index, per the corrected rule

2026-10-13 11:03:36 +00:00

NOTES.txt

refactor(stalwart): name the MTA-STS Ingress objects by index, per the corrected rule

2026-10-13 11:03:36 +00:00

stalwart.certificate.yaml

feat(stalwart): new chart for the Stalwart mail server

2026-10-02 20:59:17 +00:00

stalwart.configmap.yaml

feat(stalwart): new chart for the Stalwart mail server

2026-10-02 20:59:17 +00:00

stalwart.httproute.yaml

feat(stalwart): MTA-STS routes as a maintainable list, in both routing modes

2026-10-13 10:41:10 +00:00

stalwart.ingress.yaml

refactor(stalwart): name the MTA-STS Ingress objects by index, per the corrected rule

2026-10-13 11:03:36 +00:00

stalwart.networkpolicy.yaml

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

2026-10-14 14:46:11 +00:00

stalwart.pdb.yaml

feat(stalwart): spread each node group over nodes and give each one a PDB

2026-10-07 19:36:04 +00:00

stalwart.secret.yaml

feat(stalwart): new chart for the Stalwart mail server

2026-10-02 20:59:17 +00:00

stalwart.service.yaml

feat(stalwart): new chart for the Stalwart mail server

2026-10-02 20:59:17 +00:00

stalwart.sfs.yaml

feat(stalwart): spread each node group over nodes and give each one a PDB

2026-10-07 19:36:04 +00:00