715 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
jklein	38ea124c94	feat(rallly): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:47 +00:00
jklein	609bbaeab2	feat(patchmon): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:47 +00:00
jklein	1a7d5817c2	feat(paperless-ngx): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:47 +00:00
jklein	e09b3bb9f8	feat(outline): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:21 +00:00
jklein	b0572834e0	feat(matrix-synapse): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:21 +00:00
jklein	aedc6ff136	feat(gotenberg): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:21 +00:00
jklein	9950e935ab	feat(freesailarr): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:20 +00:00
jklein	5b53d62b5f	feat(calibre-web-automated): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:19 +00:00
jklein	fef9034862	feat(bulwark): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:19 +00:00
jklein	d7d6f8a907	feat(bentopdf): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:19 +00:00
jklein	7a3f15efc7	feat(apache-tika): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders against origin/main rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. Ambient does not bypass NetworkPolicy enforcement, so without the port a pod whose namespace has joined the mesh is unreachable. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed, and a pod that never becomes Ready reads as a broken application rather than as a policy. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:19 +00:00
jklein	009c93e3cd	feat(cyberchef): networkPolicy.ingress.ambientMesh ... Gitea #143. Additive, default false, so the render is byte-identical to the previous release - proven by diffing both renders rather than asserted. Switched on it adds 15008/TCP, ztunnel's HBONE tunnel, to the rule carrying the probe port, and - inside that rule's source-restricted branch - 169.254.7.127/32, the address the kubelet's probes arrive from once the pod is in the mesh. The two halves are one value because the second is the one nobody thinks of: 15008 added by hand leaves a policy that passes review and drops every probe the first time probeSources is narrowed. Minor, not major: additive value, unchanged default, unchanged render.	2026-10-19 17:56:19 +00:00
jklein	badfaa32cb	feat(template-chart): networkPolicy.ingress.ambientMesh, plus its checked CI exception ... Gitea #143. A pod cannot be reached inside Istio's ambient mesh unless its NetworkPolicy lets ztunnel's HBONE tunnel in - ambient explicitly does not bypass policy enforcement - and 15008 is deliberately no containerPort of the application, so assertion 2 of ci/run-networkpolicy-test.sh rejected it. The switch is a named intention rather than a free port list, and it renders two things that cannot be had separately: 15008/TCP inbound, and - where probeSources is non-empty - 169.254.7.127/32 as an additional peer, because inside the mesh the kubelet's probes are redirected away from the worker node's address. Whoever opens 15008 by hand has not added the probe address, and the first narrowed probeSources then drops every probe: the pod never becomes Ready and the symptom reads as a broken application. That is assertion 4 of the same script, one value further along. Assertion 2 keeps its edge. It gets ONE named exception for ONE port number, gated on one value, and it is not granted in the main loop at all - which renders every chart with the value at its default, so 15008 stays an ordinary failure there. The free-port variant was design A of #143 and would have opened the assertion for all 30 charts. Assertion 7 holds the exception to five things on two renders per chart: the port and the ipBlock are absent while the switch is off, 15008 is present while it is on, 15008 is still the ONLY ingress port that is not a containerPort, and wherever the rule carrying it restricts sources it also carries the ipBlock. The last one is reachable because these renders apply ci/networkpolicy/<chart>.yaml, where probeSources is non-empty. Built into the existing script, as for #136: the exception weakens assertion 2 and belongs beside it - a separate script could go green while the exception it is paired with is wrong, with nothing connecting the two. The job already runs over every chart on every pull request. Found by running it: the policy's name comes from Chart.yaml's name, not from the directory - template-chart is called "xxx". Not proven, and said so in values.yaml, the template header and the script's header: that 15008 alone suffices comes from Istio's documentation, and the probe-source half reaches no release, because probeSources is empty in every chart here. No namespace of this cluster carries istio.io/dataplane-mode, so there is no path on which either could be measured. What is proven is the render and the assertions.	2026-10-19 17:56:19 +00:00
jlab-renovate-bot	725d046dd9	Update Helm release valkey to v2	2026-10-19 13:12:44 +00:00
jlab-renovate-bot	79aa97475e	Update gotenberg/gotenberg Docker tag to v8.38.1	2026-10-19 13:01:59 +00:00
jlab-renovate-bot	da46744bb8	Update lukevella/rallly Docker tag to v4.15.5	2026-10-19 08:04:32 +00:00
jlab-renovate-bot	fd44644f14	Update itzg/mc-router Docker tag to v1.48.0	2026-10-17 15:09:07 +00:00
jlab-renovate-bot	0ae17ba94f	Update dependency aquasecurity/trivy to v0.76.0	2026-10-17 12:40:12 +00:00
jklein	95f3e8c1a1	docs(paperless-ngx): the policy header said TWO and listed three ... Pre-existing, and corrected here rather than left because the third item is the mail rule this PR rewrites. values.yaml already said THREE. Part of #136	2026-10-15 17:54:15 +00:00
jklein	1894e7d465	test(ci): assert a chart's egress ports against the POD ports of the chart it dials ... The four assertions from Gitea #5 hold ports against the pod spec the policy SELECTS. That is right for ingress and meaningless for egress: an egress port belongs to the destination, and for a database, a cache or the web that destination is in no render this repository has. So the mistake behind #136 - an egress rule naming a ClusterIP Service's port, which kube-proxy has already translated away by the time the policy is evaluated at the pod's interface - was not catchable within one chart. It is catchable across two, and paperless-ngx -> apache-tika, gotenberg is the only place in the repository where a chart dials another chart's Service (the three other policies naming port 80 aim at the internet, where there is no DNAT and 80 is the real port). The pairs are an explicit table rather than a discovery, because no render can know which Service another chart dials - the address is a value or a 1Password field - and a row naming a chart that no longer exists fails instead of being skipped. Each row is checked on two renders of the consumer: with the feature gate ON the egress ports must CONTAIN every pod port behind the peers' Services, resolved Service port -> targetPort -> containerPort, which is exactly the translation the policy is evaluated after; with the gate OFF the requirement must not apply and those ports must be absent, so a gated rule cannot quietly become one that permits what the release cannot use. The evidence line prints the chain ("port 80 -> targetPort 'tika-port' -> pod port 9998"), so a reader sees the DNAT rather than two numbers. Built into run-networkpolicy-test.sh rather than added as a new script with its own job: that job already runs over every chart on every PR, Helm is already the YAML parser through ci/yaml2json, and the verdict and summary plumbing is shared. python3 standard library only, no yq, no pyyaml, no Docker. Six fail paths executed, not assumed: a required port removed, a wrong number in its place, the peer chart renamed away, the policy name no longer following the <release>-<chart>-<kind> convention, the peers rendering no Service at all (an empty requirement reads like a satisfied one, so it fails), and the rule made unconditional, which is the fail path of the gate-off half. Measured: 30 charts, 210 assertions held (208 before), 0 failed, ~15s, no cluster. README's stated figure was 206 and is corrected here. Part of #136	2026-10-15 17:46:45 +00:00
jklein	530227405c	fix(paperless-ngx): egress names the Tika/Gotenberg POD ports, not the Service port ... The rule allowed outbound 80, the port the apache-tika and gotenberg Services listen on, and justified it in a comment: an egress rule names the port on the destination as the client dials it, and the client dials the Service. That is wrong. kube-proxy does a ClusterIP Service's destination NAT BEFORE the egress policy is evaluated at the pod's network interface, so the policy sees podIP:targetPort and never clusterIP:port - and those two charts forward 80 to 9998 and 3000. Deployed as 14.0.0+up3.3.1 it cut Paperless off from both services on 2026-10-15: mail import, EML, HTML and Office documents stopped, plain PDFs and images kept working, and the error was httpx.ConnectTimeout with no mention of a NetworkPolicy. The rule now names 9998, 3000 and 80. The 80 stays because it costs nothing and covers a foreign Tika that really does listen on 80. The refuted sentence is quoted rather than deleted: it reads perfectly, which is how it survived review, and the timeout-not-refused symptom is written down with it. No policy switch of its own: the rule stays gated on paperless.files.tikaGotenberg.enabled, because a second value that can drift from the feature re-arms this very outage. New networkPolicy.egress.mailImport opens IMAPS 993, off by default - paperless' mail accounts are rows in its database, so the chart cannot derive the rule. Plain IMAP (143) and POP3 stay in extraPorts, and 993 is noted as a real destination port, because a mail server outside the cluster has no DNAT in the path. Minor: one additive value, and a fix that widens a rule. Nothing breaks, no value becomes required, appVersion unchanged. Part of #136	2026-10-15 17:39:24 +00:00
jlab-renovate-bot	1ef23e9ce9	Update outlinewiki/outline Docker tag to v1.11.0	2026-10-15 15:05:15 +00:00
jklein	ec9e64187b	Merge pull request 'feat!: a NetworkPolicy in every chart, on by default' (#133) from feat/network-policies-all-charts into main	2026-10-14 23:07:39 +00:00
jklein	b617068b16	Merge origin/main: Renovate's stalwart v0.16.26 into this branch ... Renovate automerged the stalwart app patch onto main while this PR was open (1fd6c56: 1.3.0+upv0.16.25 -> 1.3.1+upv0.16.26), which collided with the major this PR gives the same chart. The PR went mergeable: false, with an approval and green checks - the conflict was the only thing in the way. Resolution: version: 2.0.0+upv0.16.26 with appVersion: "v0.16.26". My major absorbs their patch rather than being added to it, and the +up suffix follows appVersion as the scheme requires - verified, suffix == appVersion with dashes normalised. Also corrects the justification comment above that line, which had gone stale in a misleading direction: it argued MINOR, from a diff, for the two previous rounds (#96's spread constraint and PDB, both gated on a computed replica count the chart never reaches; #123's MTA-STS routes, whose list ships empty) - both of which rendered byte-for-byte identically against the previous version. It then sat directly above a 2.0.0. The comment now says why #5 fails that same test on every count: a new value, a changed rendered form, and an object that reaches a RUNNING release on upgrade and changes what can reach the pod. The old evidence is kept as history rather than deleted, because the contrast is the useful part. A merge rather than a rebase, deliberately: the branch is already pushed and force-pushing a reviewed branch is destructive, so main comes in instead. Part of #5	2026-10-14 22:59:37 +00:00
jklein	b31a18918c	docs(gotenberg): point the values comments at the switch, not at extraPorts ... Two leftovers from before the switch existed. The summary still told the reader to set egress.extraPorts: [80, 443] for remote assets, and the extraPorts hint still offered the same pair as its headline case - both now say to use egress.remoteAssets instead, and the extraPorts hint says why: a bare 80/443 in that list records no reason, which is the whole argument for the named value. Also sharpens the sentence that matters: HTML conversion keeps the EMBEDDED content and loses the images it would have FETCHED. The two words were doing the work and the old wording blurred them. Part of #5	2026-10-14 21:21:35 +00:00
jklein	e3f6256244	feat(gotenberg): a named switch for remote assets, off by default ... The maintainer's decision, and it keeps restrictive-by-default intact: not an opening but networkPolicy.egress.remoteAssets, whose purpose is in its name instead of being an unplaceable [80, 443] in extraPorts. Additive inside the major this chart already carries in this PR, so no second version step. WHAT IT BUYS, measured rather than assumed. paperless-ngx splits a mail into two steps with two separate cluster-internal endpoints: the .eml goes to TIKA for parsing (PAPERLESS_TIKA_ENDPOINT) and the resulting HTML comes here for rendering (PAPERLESS_TIKA_GOTENBERG_ENDPOINT). Of the images in that HTML, EMBEDDED ones are MIME parts inside the file and need no network from either service - which is why apache-tika stays DNS-only and is unchanged - while REMOTE ones (<img src="https://...">) are fetched by Chromium here, at render time. With the switch off they are silently dropped: the PDF is produced and is simply missing them, nothing fails, nothing is logged, no probe notices. That invisibility is the reason the switch exists. NOT CHECKED, and written down as not checked rather than implied: whether paperless-ngx re-embeds the images Tika extracted before handing the HTML over. If it does not, embedded images would be lost too - but that would be pre-existing paperless behaviour and not this policy, so the switch is not a fix for it. The SSRF argument is unchanged and is why the default is off: Gotenberg drives a headless Chromium and 3000 is its probe port, so the service is reachable from the whole cluster, and outbound web access turns anything that can POST here into a way of fetching arbitrary URLs. Two things the implementation needed, and one of them was a real defect. The NOTES.txt branch read .Values.networkPolicy.egress.remoteAssets directly, which fails the whole render with "nil pointer evaluating interface {}.remoteAssets" when an operator erases the egress block - the schema permits null there, and issue #99's rule is that an erased block means "the default applies", not a broken render. It is null-safe now, and an erased block falls back to DNS-only, which is the restrictive direction. And ci/networkpolicy/ gotenberg.yaml makes the switch's ON state permanent in CI rather than checked once by hand: it renders both the switch's egress rule and the source-restricted probe branch, so all five assertions run over the toggle in both positions on every pull request. Worth having precisely because assertions 2 and 3 look at INGRESS rules - an egress mistake has no other mechanical check. Also, three things that were load-bearing and written nowhere: - NO CHART SHIPS allowedNamespaces PRE-FILLED. A chart naming mc-router or stalwart in its defaults would bake in an assumption about this cluster's namespace layout, which a chart cannot keep true. Restrictive is the default and filling it is the DEPLOYMENT adaptation - so the release-side one-liners this sweep produces are the expected procedure, not a defect list, and the major on each chart is what announces them. ingressController is the one exception, because it names a cluster component rather than a tenant. - A POLICY APPLIES TO TRAFFIC THAT CAME THROUGH A SERVICE, and that is why the ingressController rule works at all. A Service is only destination NAT and the policy acts at the pod's interface. What the Service changes is the SOURCE ADDRESS: pod -> ClusterIP -> pod preserves it, so a podSelector can still match Traefik; NodePort traffic with the default externalTrafficPolicy: Cluster is masqueraded to a node, which is why those rules are left open. stalwart's template already carried the second half; the first half is the one everything rests on. - AND THE ONE CLUSTER SETTING THIS CONVENTION DEPENDS ON AND CANNOT CHECK: Traefik must not run with hostNetwork. Measured 2026-10-14 - the DaemonSet has none and its pods carry real pod IPs (10.42.3.120, 10.42.4.94, 10.42.0.187 in the pod CIDR 10.42.0.0/16, nodes on entirely different addresses), and only because of that does a podSelector match it. On host networking those pods share the node's namespace, stop being selectable, and EVERY WEB CHART GOES DARK AT ONCE while every pod stays Ready, because the probe path does not run through the controller. Same class as --enable-certificate-owner-ref in #126: undetectable from here. It is in README and in the header of template-chart's policy, so whoever changes the controller's networking meets the consequence on the thing they are changing. Part of #5	2026-10-14 21:19:34 +00:00
jlab-renovate-bot	1fd6c56c2e	Update docker.io/stalwartlabs/stalwart Docker tag to v0.16.26	2026-10-14 18:05:16 +00:00
jklein	be3e2cdd47	test(ci): exercise minecraft-server's NodePort branch, which nothing rendered ... Found by reviewing my own diff rather than by a failure, which is the only reason it is worth a commit of its own. minecraft-server's game-port rule has two branches read from the same value the Service reads: OPEN when server.service.type is NodePort, RESTRICTED to the namespace otherwise. All four releases in this cluster use ClusterIP and so does the install-test fixture - so the OPEN branch was rendered nowhere at all. Not by the chart defaults, not by the fixture, not by lint. It is also the branch where naming server.service.outwardPort instead of server.port would be the classic NodePort mistake, and assertion 2 can only see a rule it has been given. The overlay switches the Service to NodePort and RCON on, so both unreachable branches are now rendered on every pull request. RCON is in there for a reason too: its rule is gated on server.rcon.enabled exactly as the containerPort is, that pairing was wrong once while this chart was being written, and switching the feature on keeps the PAIR under test rather than just the gate. The overlay guard had to be made conditional for this to be possible, and the refinement is sound rather than a workaround. It demanded that any chart with an overlay render a source-restricted PROBE rule - but minecraft-server has no probe rule at all, because all three of its probes are exec probes, and it therefore offers no probeSources. The guard now applies only to charts that offer that value, so it still catches an overlay that stopped reaching the restricted probe branch (template-chart, the case it was written for) without rejecting an overlay that exists for a different unreachable branch. All twelve failure paths re-run against the change; the suite is 30 charts, 208 assertions, 0 failed. Part of #5	2026-10-14 15:29:16 +00:00
jklein	8233617f57	docs: the NetworkPolicy convention and its render test ... README gains two sections and CLAUDE.md the binding compact summary. "NetworkPolicies (#5)" under Chart style guidelines carries the part that is actually hard to get right: the FOUR PORT CLASSES, and that the class decides the rule. A port a network probe addresses stays open until probeSources is set, because the kubelet probes from the worker node's IP and no chart can know it. A NodePort-published port stays open because the source is already masqueraded. Everything else can be - and is - restricted by source, which is why the charts with a real inbound restriction are exactly the ones whose probes use a different port: keycloak's 8080, garage's s3 and web, minecraft-server's RCON, teamspeak-server's query interface. And a cluster bus between a release's own replicas gets a bare podSelector, with the reminder that policyTypes Egress means the outbound side needs its own rule or the cluster never forms while every node looks healthy. The exec-probe distinction is written down as load-bearing rather than pedantic, because it is the whole reason valkey and minecraft-server are the tightest policies here and every HTTP-probed web app is looser. What the policies do NOT do has its own list, including the two that will surprise someone: most dependency ports are the STANDARD ones rather than the configured ones, because connection details live in 1Password items the charts never parse - with keycloak, stalwart and minecraft-router named as the exceptions that derive theirs from values; and a subchart's pods are not covered, with ytdlp-web-player's oauth2-proxy as the sharp case and paperless-ngx' valkey as the opposite. The three Ingress-only charts are listed with their individual arguments rather than a blanket excuse, and gotenberg is contrasted against them: it keeps a DNS-only cap on purpose, because it drives a headless Chromium on a port the whole cluster can reach. "NetworkPolicy render test" under CI/CD documents the gate, and ends with what the pipeline cannot prove - including the measurement from this PR that k3s exempts kubelet probe traffic from policy, so the install-test's net is an EGRESS net. That is stated there rather than implied, because it is the reason assertion 2 matters: a wrong ingress port is caught mechanically or not at all. Part of #5	2026-10-14 14:48:21 +00:00
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
jklein	28a0230ef0	feat!: NetworkPolicy in the NodePort and game-server charts, on by default ... garage, minecraft-router, minecraft-server, samba, teamspeak-server, satisfactory. One major each. These are the charts the plan said to leave for last, and they earned it - three of them changed the convention rather than just consuming it. GARAGE is the clearest illustration after keycloak. Its four ports split three ways: s3 and web are RESTRICTED by source (no probe touches them), admin is the probe path and stays open inside the cluster - which is uncomfortable, because admin is also the admin API, and that is said out loud instead of glossed - and rpc gets the narrowest rule the object can express, a podSelector with no namespaceSelector. All four numbers come from garage.settings. MINECRAFT-SERVER is the tightest policy in the repository, and the reason is worth knowing: all three of its probes are EXEC probes, which put no packet on the network, so no port has to stay open for the kubelet and no probeSources value is needed at all. RCON and metrics are restricted outright. The game port has two branches rendered from the same value the Service reads - server.service.type NodePort means players arrive from the internet and the rule must be open; anything else means the only path is in-cluster, so the rule is restricted and the router's namespace has to be in allowedNamespaces. MINECRAFT-ROUTER derives its egress from the routing table instead of guessing: server.backendPort plus the "port" override of every mapping that sets one. Add a backend on a non-standard port and the policy follows. What it cannot express is the destination - mappings name hosts, and this object matches no hostname - so the rule is wider than the routing table, and that is written down. SATISFACTORY gets policyTypes: [Ingress] and no egress section, and the second half of the reason is the deciding one. Steam's content delivery is not a pinnable port set (SteamCMD over TCP 80/443/27015-27050, master servers over UDP 27000-27100 and 4380, changed by Valve, re-downloaded on every update) - and this is the ONE chart with no install-test at all, because the image is multiple GB and the first start pulls over 10GB. An egress cap here would be the only one in the sweep with no empirical check behind it, on the chart whose correct port set is least knowable. SAMBA and TEAMSPEAK-SERVER carry the NodePort lesson explicitly: the rules name 445/139 and the pod's voice and file-transfer ports, never the NodePorts, and teamspeak's file is explicit that its pod port and NodePort happening to share a number is a coincidence of its values rather than a pattern to copy. Teamspeak's voice rule is UDP, and the file says why that matters: a TCP rule on the same number is accepted, looks complete, and drops every voice packet. THREE THINGS THE CHECKS CAUGHT WHILE THIS BATCH WAS WRITTEN, all of them real: - minecraft-server's RCON rule named a port the pod does not declare. The containerPort is gated on server.rcon.enabled and the rule was not, so assertion 2 rejected it. The rule now carries the same gate. - samba and satisfactory would have shipped allowedNamespaces and probeSources values that reach NO rule - every one of their inbound rules is open to any source. A value that silently does nothing is worse than one that is absent, because it reads as a control, so both are gone from those two charts and from their schemas, with the reason in values.yaml. teamspeak-server loses probeSources for the same reason and keeps allowedNamespaces, which its web-query rule uses. - the policy templates no longer declare template variables they do not use. samba keeps one, satisfactory none. Part of #5	2026-10-14 14:37:51 +00:00
jklein	96c23b7912	feat(keycloak)!: NetworkPolicy, on by default - the full convention in one chart ... Major. This is the richest policy of the sweep and the one with the largest blast radius, and it is the only chart whose three ports fall into three different classes - so it is where the convention is visible in full: http (8080) NOT addressed by any probe, so it CAN be restricted by source, and it is: own namespace, allowedNamespaces, and the ingress controller. The only real inbound restriction in this whole rollout, possible only because the probes use a different port. management (9000) the port all three probes address, so it stays open inside the cluster. That matters here specifically: this surface carries health and metrics UNAUTHENTICATED, and "no Ingress" was its only protection before this object. The policy turns "anything that can route to the pod" into "anything inside the cluster"; probeSources closes the rest. jgroups (7800) the cluster bus, restricted to the pods this policy itself selects - a podSelector with no namespaceSelector, the narrowest rule the object can express. All four port numbers come from keycloak.settings rather than being written down twice, so moving keycloak.ports.http moves the policy with it. And the egress rule for the database is the CONFIGURED port, keycloak.db.port - this is the one chart in the sweep that does not have to guess, because its database port is a value instead of a field inside an opaque secret. The outbound cluster-bus rule is not a duplicate of the inbound one: policyTypes lists Egress, so a replica dialling its peer is subject to this policy too, and without it the bus would be open inbound and blocked outbound - a cluster that never forms, with two nodes that each look healthy. THE BLAST RADIUS IS WRITTEN INTO THE CHART, because nothing in CI can catch it: this release is the cluster's identity provider, no ingress controller runs in the install-test, and the probes use 9000 - so the pod becomes Ready whether or not the http rule is right. NOTES.txt therefore asks for two checks after the first upgrade: log in, and look at whether any consumer uses the in-cluster Service address instead of the public issuer URL (those namespaces need allowedNamespaces). Not allowed at all, and named as the likely first surprise: SMTP, because the mail server is configured per realm where the chart cannot see it. The test's overlay guard is tightened in the same commit, and keycloak is why. It counted any source-restricted rule, and this chart restricts two of them in its own defaults - so the guard would have been satisfied while the probe branch, the only branch an overlay exists to reach, was never rendered. It now counts restricted PROBE rules. All twelve failure paths were re-run against the change. Part of #5	2026-10-14 14:30:30 +00:00
jklein	e1adcef71f	feat!: NetworkPolicy in nine more charts, on by default ... bulwark, calibre-web-automated, patchmon, rallly, urlaubsverwaltung, voucher-vault, zipline, sure, homeassistant. One major each. These are the charts with real outbound dependencies, and they all share one limitation that is now written into every one of them: THE EGRESS PORTS ARE THE STANDARD ONES, NOT THE CONFIGURED ONES. Databases, caches and OIDC issuers arrive as connection URLs or as fields inside 1Password items that the charts never parse, so a chart cannot know where its dependency listens and cannot validate a guess. A dependency somewhere else is blocked, and networkPolicy.egress.extraPorts is the escape hatch. That is the upgrade risk of this rollout, stated per chart instead of discovered per release. Four of them differ in ways that mattered: HOMEASSISTANT gets policyTypes: [Ingress] and NO egress section at all, and that is the decision in the file rather than an omission. Its outbound traffic is the union of every integration an operator enables - mDNS and SSDP discovery, MQTT, a Zigbee or Z-Wave bridge on whatever port its firmware chose, ESPHome, printers, speakers, inverters, cloud APIs, NTP - which no chart can know. A cap would protect little, since the devices sit on the node's own LAN, and would break integrations one at a time, months apart, each looking like a flaky device rather than like a policy. So valkey's rule applies in the other direction: policyTypes names only what there is something to restrict. URLAUBSVERWALTUNG allows BOTH 5432 and 3306, deliberately. It is handed a full JDBC URL inside a 1Password item and never parses it, so it cannot tell PostgreSQL from MariaDB - and this cluster runs both. Allowing one would break half the possible deployments on upgrade, with the symptom buried in a Java stack trace. A small widening against a large and silent failure. RALLLY derives its SMTP rule from rallly.smtp.enabled rather than always rendering it: with mail switched off there is nothing to permit, and a rule that permits nothing makes the object look stricter than it is. BULWARK is the chart where the cap can fail most quietly. Its probes test its own port and say nothing about the JMAP server, so a jmapServerUrl on a port the policy does not allow yields a Ready pod serving an empty webmail. 443 is allowed, Stalwart's in-cluster 8080 is not, and both halves of that are in values.yaml and NOTES.txt. PATCHMON and HOMEASSISTANT select their pods by the BARE release-and-chart label, with no -deployment or -sfs suffix. Copying a selector from a neighbouring chart would have matched nothing and left a policy that filters nothing - which is precisely the first assertion of the render test. Five CI fixtures gain networkPolicy.egress.extraPorts, and they are the only place in the repository where the cap's cost is actually exercised: the CI dex runs on 5556 rather than 443 (patchmon, rallly, urlaubsverwaltung, voucher-vault) and the CI JMAP server on plain 8080 (bulwark). Part of #5	2026-10-14 14:26:25 +00:00
jklein	6bde72192f	fix(ci): put outline's extraPorts entry where it belongs in the fixture ... The previous commit appended the networkPolicy block in the middle of the secrets: mapping, so dbSecretRef was absorbed into it. The chart's own values.schema.json caught it immediately - "at '/networkPolicy': additional properties 'dbSecretRef' not allowed" - which is exactly what issue #68 built that schema for: a key the chart does not read is a named error at render time instead of a silently missing secret. Part of #5	2026-10-14 14:21:45 +00:00
jklein	ee9ae8a724	feat!: NetworkPolicy in six more charts, on by default ... bentopdf, apache-tika, gotenberg, rss-bridge, searxng, ytdlp-web-player. One major each, networkPolicy.enabled defaults to true. Three of them differ from the simple case in ways worth naming: GOTENBERG gets DNS-only egress as a deliberate, documented trade. It drives a headless Chromium, and 3000 is its probe port - so it is reachable from the whole cluster by default, and an egress rule for 80/443 would turn a service anyone can POST to into a way of fetching arbitrary URLs. The price is the remote-asset half of HTML conversion: inline content converts, images the page would have fetched silently do not. That degrades a PDF instead of failing a pod, so nothing alerts on it, which is why it is in the template header, in values.yaml and in NOTES.txt, with extraPorts: [80, 443] named as the knowing opt-in. RSS-BRIDGE, SEARXNG and YTDLP-WEB-PLAYER get the open internet on their web ports, because reaching other people's servers IS the application and this object cannot name a host. Said plainly in each, so none of them reads stricter than it is. What the cap still buys is real: no other outbound port, so a compromised pod reaches no database, no mail server and no SSH anywhere. APACHE-TIKA and GOTENBERG render no Ingress - their consumers are other pods, in other namespaces here - so neither gets an ingressController value and both say in NOTES.txt that narrowing probeSources means listing the consumers' namespaces in allowedNamespaces in the same change, or extraction and conversion stop. YTDLP-WEB-PLAYER names the gap this convention has: its oauth2-proxy subchart renders its own Deployment with its own labels and ships no policy, so with the proxy enabled the pod that actually faces the Ingress is unrestricted in both directions. Nothing in this chart can change that - an upstream chart is consumed as it comes - so it is written down instead. ci/outline/test-values.yaml gains egress.extraPorts: [5556]. The CI dex runs there rather than on 443, and Outline fetches the discovery document at boot - so this is the chart's documented escape hatch used for exactly the case it was written for, and the one place in the repo where the cap's upgrade risk is actually exercised. Part of #5	2026-10-14 14:20:39 +00:00
jklein	de995d0f53	Revert the enforcement experiment, and record what it measured ... Both experiments are in, and together they answer the question the scope of #5 rests on - with an answer that is not the one the plan assumed. MEASURED, run 888 on this branch: Install-test cyberchef SUCCESS, 1m9s probe port 8080 restricted to 192.0.2.11/32, which cannot be the k3d node's address Install-test outline FAILURE, 5m59s DNS egress rule removed, so "postgres" and "redis" do not resolve and /_health cannot pass So: POLICIES ARE ENFORCED in the install-test - outline's pod never became Ready and rollout status timed out after six minutes, which is the net this rollout needs. But THE KUBELET'S PROBE TRAFFIC IS EXEMPT from policy in k3s: cyberchef became Ready in 69 seconds with its probe port restricted to an address no probe can come from. What that changes, and what it does not: - The plan's claim was "a policy that blocks the probe path makes the install-test red". That is NOT true here, and it is now measured rather than assumed. The install-test's net is for EGRESS and for anything the application itself needs, not for the probe path. - It does not undermine the rollout, because this convention never restricts a probe port by default - the rule is rendered without a "from" until an operator sets probeSources. The trap CI cannot see is therefore not triggered by this PR; it is triggered by a deliberate narrowing, which is what the NOTES.txt sentence and ci/run-networkpolicy-test.sh's fourth assertion exist for. - It raises the stakes for the render assertions. A wrong ingress port - the NodePort mistake above all - would leave the pod Ready in CI (probes exempt) and no ingress controller runs there either, so nothing in the pipeline would notice. That failure is caught mechanically by assertion 2 or not at all. - And it says nothing about the production cluster, whose CNI is Calico, not k3s'. There, probe traffic is subject to policy, which is exactly why the default stays open. Part of #5	2026-10-14 14:17:49 +00:00
jklein	813c923070	test(outline): does the install-test enforce policies at all? [EXPERIMENT, reverted next] ... The first experiment did not settle it. Restricting cyberchef's probe port 8080 to 192.0.2.11/32 - an address that cannot be the k3d node's - left the install-test GREEN, which has two very different causes: either k3s' policy controller exempts the kubelet's probe traffic (good news for this convention, whose default leaves the probe port open anyway), or it enforces nothing at all (no net under this rollout). This separates them without touching a probe. Outline's egress rule for DNS is removed, so the pod cannot resolve "postgres" or "redis" - and all three of its probes hit /_health, which checks both stores. Expected: RED, which proves egress is enforced. Green means nothing is enforced in CI and the scope has to be renegotiated. Reverted in the next commit either way. Part of #5	2026-10-14 14:07:26 +00:00
jklein	77b978d669	feat(outline)!: NetworkPolicy, on by default ... Major, as every chart in this rollout is. Inbound 3000 only; outbound DNS plus 5432, 6379 and 443. Those three egress ports are the STANDARD ones and not the configured ones, which is this chart's real limitation and is written into values.yaml, the template header and NOTES.txt rather than left to be discovered: Outline's database, Redis and OIDC provider all arrive as connection URLs inside 1Password items that the chart never parses, so it cannot know where they listen and cannot validate a guess. A dependency on another port is blocked, and because all three probes hit /_health - which checks Postgres and Redis - the symptom is a pod that never becomes Ready rather than an error anyone reads. networkPolicy.egress.extraPorts is the escape hatch. That same property is what makes this chart the right place for the enforcement experiment in the next commit. Also reverts the cyberchef fixture from the first experiment: with the probe port restricted to an address that is not the node's, the install-test went GREEN, so the claim that it catches a blocked probe path does not hold as written. The next commit establishes whether policies are enforced in CI at all. Part of #5	2026-10-14 14:07:06 +00:00
jklein	d3ef3729f8	test(ci): prove the install-test enforces NetworkPolicies [EXPERIMENT, reverted next] ... The scope of Gitea #5 - 29 charts at once, default on - rests on the claim that the install-test enforces policies, so a policy that blocks the probe path goes red in CI rather than silently in production. k3d is created without --disable-network-policy, but a flag read off a workflow file is not evidence. This commit restricts cyberchef's probe port 8080 to 192.0.2.11/32, an RFC 5737 documentation address that cannot be the k3d node's IP. The kubelet probes from the node's own address, so they are dropped and the pod must never become Ready. Expected: the cyberchef install-test goes RED on rollout status. If it goes green, policies are not enforced in CI and the scope has to be renegotiated. Reverted in the next commit either way. Part of #5	2026-10-14 14:00:11 +00:00
jklein	31d37c9767	feat(cyberchef)!: NetworkPolicy, on by default ... Major, as every chart in this rollout is: networkPolicy.enabled defaults to true, so the object reaches running releases on the next upgrade. The simplest policy of the sweep, and the one to read first. CyberChef is a static web app - nginx serves files, the recipes run in the visitor's browser, the pod holds no state and calls nothing - so what the policy buys is the two CEILINGS rather than any source restriction: inbound is capped at 8080, the single port the pod declares, and outbound at DNS, which is as tight as the object goes without breaking name resolution. The 8080 rule carries no source selector by default, and that is deliberate rather than an oversight: 8080 is the port all three probes address, and the kubelet probes from the IP of the worker node running the pod, which no chart can know. Guessing it wrong leaves the pod permanently un-Ready, a symptom that reads as a broken application. Narrowing it is networkPolicy.probeSources, and the restricted branch then also carries the ingress controller - measured as the rke2-traefik DaemonSet in kube-system, which serves this chart's HTTPRoute as well, since the same Traefik backs the Gateway API here. Part of #5	2026-10-14 13:59:51 +00:00
jklein	36bcfd3b11	feat(ci): assert every rendered NetworkPolicy against its own render ... The part that carries the rollout of Gitea #5. 29 charts get a policy that is on by default, and every way one of them can be wrong is SILENT: the API server accepts a policy that filters nothing just as readily as one that filters everything, and neither is a render error, so neither the build nor a rollout sees it. ci/run-networkpolicy-test.sh holds every rendered NetworkPolicy against the pod specs, probes and Services of the SAME render: 1. the podSelector really matches a pod of that render - otherwise the object sits in the namespace, is listed by kubectl, reads as a boundary and filters nothing, usually because a label was renamed in another file; 2. every INGRESS port is a containerPort of the selected pods, which catches the NodePort mistake mechanically. Egress ports are deliberately excluded: an egress port belongs to the DESTINATION, and comparing it would fail every chart that reaches a database; 3. no ingress rule allows every source by accident. "from: []" always fails - it allows everything while reading as a restriction. A MISSING "from" is the documented open form and is accepted only where the render justifies it: every port of the rule is addressed by a network probe, or published by a NodePort Service. That is stricter than the plan's wording, which banned both forms, and it had to be, because the precedents use the second one on purpose; 4. the probe path. For every port a NETWORK probe addresses, the policy either leaves it unrestricted or the chart offers networkPolicy.probeSources AND says in NOTES.txt that a list missing the node's IP leaves the pod permanently un-Ready. exec probes are excluded by design - they run inside the container and put no packet on the network, which is exactly why valkey and minecraft-server can restrict their port by source with no probeSources at all. Two guards beyond the four: a chart that renders NO policy fails, because that is how this issue decayed in the first place - garage and keycloak were both created after #5 and both arrived without one. And a "#" comment inside a rendered policy fails, because it is part of the object and is shipped to the cluster. Helm is the parser through ci/yaml2json, as in the other render tests: the runners have neither pyyaml nor yq, and a hand-written parser could read nothing, find nothing and leave this green over a chart it never looked at. Every failure path was run, not just the green ones, and one of them earned its keep immediately: the probeSources check was a substring test, so a chart whose key had been deleted while the comment above it still discussed the value passed. It now looks for the key. Part of #5	2026-10-14 13:56:06 +00:00
jklein	1001de620a	feat(template-chart): the reference NetworkPolicy, on by default ... The reference implementation for Gitea #5: one NetworkPolicy per workload, networkPolicy.enabled defaulting to true, plus the values block, the schema entry and the NOTES.txt section that go with it. The shape is taken from the two charts that already had one - valkey and stalwart - rather than invented, because they carry the expensive lessons: policyTypes only where there is something to restrict, namespaces always spelled out because an empty "from" allows everything, kubernetes.io/metadata.name so no foreign namespace needs labelling, POD ports and never NodePorts, egress by port because the object cannot express a hostname, and the probe path left open by default because the kubelet probes from the node's own IP. Three things are written down rather than assumed. The ingress source is measured on the cluster and is NOT what the issue body assumes: ingress-nginx is gone, the only IngressClass is traefik, and the controller is the DaemonSet rke2-traefik in kube-system - which also serves the Gateway API here, so one source covers both the Ingress and the HTTPRoute path. Egress stays coarse: with Canal (Flannel plus Calico) there is no FQDN rule, and Calico's GlobalNetworkSet would bind every chart to Calico, the same argument that kept implementation-specific objects out of #114. And a policy is only a boundary where the CNI enforces one - unenforced, it is accepted and filters nothing. All reasoning sits in Go template comments, not in "#" comments: those are part of the rendered object and travel into the cluster. Writing this header also found the second-order trap, which is now in the header itself - prose inside a template comment must not spell out the comment's own closing delimiter, or the parser ends the comment early and the remaining prose is emitted as manifest content. Part of #5	2026-10-14 13:55:50 +00:00
jlab-renovate-bot	c9edbb1750	Update docker.io/searxng/searxng Docker tag to v2026.10.13-22c64b8d3	2026-10-13 19:53:10 +00:00
jlab-renovate-bot	262776d18d	Update ghcr.io/paperless-ngx/paperless-ngx Docker tag to v3.3.1	2026-10-13 19:36:04 +00:00
jklein	39844fc92c	ci: hold every scalar that must be a string, and the required podAffinity ... The test Gitea #11 asked for ("whoever fixes this ships a test case that would have caught it"), plus the guard for the fix #101 introduces. ci/run-yaml-scalar-render-test.sh renders every chart with the fixtures the install-test already uses and asserts three properties Kubernetes itself requires, so no per-chart expectations are needed: a CronJob schedule is a non-empty string, every env[].value of every container and initContainer is a string, and every label and annotation value is a string. The first catches the loud failure - the render aborting with a YAML error that names the template and not the value - and the other two catch the quiet one, where the render succeeds and the API server rejects the object at apply time. WHY A NEW JOB AND NOT THE INSTALL-TEST. The object that carried the defect is rendered by no fixture at all: paperless-ngx' consume CronJob sits behind smbConnection.enabled, false in the chart defaults and false in its install-test fixture, since the CI cluster has no SMB CSI driver. Nothing in this repository ever produced it. So the overlays under ci/yaml-scalar/ are the test, not the scaffolding: they switch such objects on AND feed them hostile values, and the script fails when an overlay stops reaching its object or when the run asserted nothing at all. The fail path was exercised in all three shapes against a throwaway copy of the chart as it stands on main, not reasoned about: the bare schedule aborted with "yaml: line 6: did not find expected alphabetic or numeric character"; with only the schedule quoted, the star-valued env entry aborted on the StatefulSet instead; and with only the bool-looking value left - a render that succeeds - the type assertion named the variable, the container and the API server's message. Green repo-wide otherwise: 30 charts, 408 scalars, 0 failed. ci/run-selector-match-test.sh additionally holds every requiredDuringSchedulingIgnoredDuringExecution podAffinity term against all pod templates of the same render (Gitea #101). That case is not the gap the script's header describes: a preference that cannot be met is dropped and an anti-affinity over zero pods is satisfied, but a REQUIRED term matching no pod can never be satisfied and the pod stays Pending for good. paperless-ngx' mover selects a label written in another template, which is exactly the copy this test holds - renaming it would leave both templates rendering perfectly while the mover silently stopped moving. Exercised by doing that rename in a throwaway copy: one FAIL naming the selector, the pod templates it missed and the labels actually present. Six charts still render their env block bare (matrix-synapse, minecraft-router, minecraft-server, rallly, satisfactory, teamspeak-server). They are green only because no fixture of theirs sets a hostile value; README now says so instead of repeating template-chart's claim that every chart quotes. Part of #11 Part of #101	2026-10-13 19:10:26 +00:00
jklein	4b2bde505d	feat(paperless-ngx)!: quote every operator scalar, pin the consume mover, drop oidcSecretRef ... Three issues on one chart, bundled because they share values.yaml, values.schema.json and the version line, and because the first half of #11 lives in the same template as #101. Gitea #11, first half: the consume CronJob's schedule was rendered bare, so a schedule in the commonest cron notation there is - a star, a slash, an interval - aborted the render with a YAML parse error pointing at the template while the operator's value appeared nowhere in the message. Quoting it in the values file does not help; Helm passes the content through. Reproduced before the fix, at the line the issue names, and fixed with | quote. Gitea #11, second half: secrets.oidcSecretRef is removed, values and schema both. No template ever read it, so no OnePasswordItem was created and nothing reached the pod - the quiet kind of defect that looks like successful configuration. It is not reimplemented, and the reason is in paperless: the whole OIDC configuration travels in one json environment variable with no _FILE variant, so a secretKeyRef cannot substitute a fragment into it. The operational question is answered by #83 - Keycloak marks a client public per client, so nothing forces a confidential one here. In the same breath, oidc.provider.tokenAuthMethod is restricted to "none". Its comment named client_secret_basic as the example, which asks the provider for an authentication this chart cannot perform: it configures no client secret and cannot. The two values read together looked like a working secret setup, and the symptom was a login dying at the callback with invalid_client. No live release sets it (measured against all three instances). Gitea #112 asked for an extraEnv and the chart already had the standard additive env block - the issue was measured against a deployed 12.2.0 and read only the top-level keys. What was actually broken is the block itself: it rendered its operand bare, so a "*"-leading value aborted the render and "true" or "0755" arrived as a bool or an integer, which the API server rejects after a green render. It is brought to the repository's documented quoted form (template-chart carries the rule), which is what makes an arbitrary PAPERLESS_* variable settable in practice. PAPERLESS_LOGGING_DIR is documented as the worked example, with the cross-reference it needs: the root cause is the NFS-exported RWX data volume in jk-cluster-config #360 and this does not fix it - it only moves the log off that volume. The two Ingress upload-size annotations had the same bare render and are quoted too. Gitea #101: the consume mover now runs on the node of the StatefulSet pod, via a required podAffinity on its label. It mounts the RWX consume volume, and Longhorn's CSI driver refuses that mount unless it finds a workload pod in Pending, so a mover on another node left the StatefulSet node's kubelet retrying every two minutes - 291 events in 10 hours in both releases with SMB on, none in the release without the CronJob. A static nodeSelector would be wrong because the StatefulSet pod is not pinned either, and preferred would reproduce the bug more rarely and harder to find. The cost of a required term is handled rather than left open: concurrencyPolicy: Forbid, a startingDeadlineSeconds that also keeps the controller away from its 100-missed-schedules stop, and an activeDeadlineSeconds that fails a job which cannot be placed instead of leaving one Pending pod per schedule. scaleDown already suspends the CronJob; what remains is paperless.replicas: 0 with SMB on, which now reports a bounded, visible failure. successfulJobsHistoryLimit is deliberately untouched: Longhorn's check asks for the existence of a Pending pod, not the absence of Succeeded ones, so those three pods are the error message's evidence and not its cause. Side defect fixed on the way: every read of smbConnection.cron dereferenced the block directly, so an override that had erased it aborted with a nil-pointer error naming an internal template path instead of falling back to the defaults this chart promises everywhere else. Measured on origin/main; all reads now go through a merged-defaults helper that preserves an explicit false. Major: a value is removed and fails the strict schema afterwards, and runtime placement changes. Fixes #11 Fixes #101 Fixes #112	2026-10-13 19:09:45 +00:00
jklein	59d2614384	feat(ci): the chart bump follows the app bump ... The version-bump hook classified every app update that was not a major as a chart patch, so an app minor arrived as a patch - the mechanism behind the sonarr incident, where a security default was switched off inside a bump the conventions told the reviewer not to read (Gitea #128). ci/renovate-bump-chart.sh now takes the level from Renovate's update type, passed in as a second argument: major -> major, minor -> MINOR, patch/digest/pin -> patch. The level comes from Renovate rather than from comparing appVersion because an appVersion comparison is blind to the case that prompted the rule - freesailarr keeps a hand-maintained appVersion for ten upstreams, and prowlarr's 2.5.2 -> 2.6.5 moved an image tag in values.yaml while appVersion stood still. Three properties come with it: - Maximum, not replacement. The chart jump is the greater of the chart's own classification and the app jump, so a value that becomes required stays a major under an app patch. Mechanically it is also what makes a grouped branch deterministic: the hook runs once per update from the same base commit, so without it the last call would win. - Non-semver app versions stay at patch for a minor (seven charts). In CalVer and date tags the second position is a month; in a four-part or suffixed version the positions are not semver positions. An app major is not subject to it. - A missing or unknown update type falls back to the pre-#128 behaviour. postUpgradeTasks only runs where the command is allow-listed on the shared instance, which is not visible from here and fails silently, so the worst case is the old classification rather than every chart PR red on the version check. ci/run-bump-level-test.sh holds 49 cases against the version string the script writes, wired up as the bump-level job: a wrong level is a valid version string, so the PR would go green and the only symptom would be a number that understates what it publishes. The convention texts follow in CLAUDE.md and README, including the limit the decision deliberately keeps: the reading duty was rejected, so the incident stays repeatable and the honest number is the whole of the remedy. Fixes #128	2026-10-13 18:47:44 +00:00
jklein	978e6fbaa8	refactor(stalwart): name the MTA-STS Ingress objects by index, per the corrected rule ... Maintainer's decision, and it reverses this chart's naming rather than the style guide's rule. The objects become <release>-stalwart-mta-sts-ingress, -1, -2, ... in this repo's idiom ({{ if $i }}-{{ $i }}{{ end }}), the same as homeassistant's routes and keycloak's realm Ingresses, inlined in the template instead of behind a helper of its own. WHY IT GOES THIS WAY. This chart named by issuer, reading the style guide's index rule as resting on "a route holds no state and no certificate" and observing that these objects hold one. That reading was right and the rule's STATED REASON was wrong: the parallel #122 round named by index, cited the same rule as binding, and entered keycloak into it - whose realm Ingresses hold certificates too. Two charts did opposite things for one shape, and the rule had been extended onto cases its own precondition excluded. #125 is merged and published, so the reason is repaired and the naming unified on index; keycloak is not touched. What actually carries the index rule, in three steps that have different standing and are written as such in the template header and the style guide: cert-manager here runs WITHOUT --enable-certificate-owner-ref (MEASURED by the maintainer - absent from the Deployment's args and from the ControllerConfiguration its --config names, which carries only kind: ControllerConfiguration and enableGatewayAPI: true); by that default the Certificate is collected with its Ingress but the SECRET IS NOT (DOCUMENTED behaviour, not measured here), so a rename recreates the Certificate object against a surviving secret and issues nothing; and NO RENAME WAS APPLIED against a cluster. The promise therefore hangs on a cluster-level flag this repository does not control - with it on, a reorder would cost a fresh ACME request per renumbered object. UNCHANGED: the structure. One Ingress per distinct clusterIssuer, one rule per host, tls grouped by secret, and the abort when one secret spans two issuers - grouping is a cert-manager question and naming is a style question, and they are independent. TWO THINGS THE RENAME OBLIGES. 1. NOTES.txt now prints the mapping - index, object name, issuer, secrets and hosts per object, the way keycloak's does for its realms - because the name no longer carries the issuer and nothing else in the cluster says which object holds which. 2. The reordering hazard is documented as SHARPER than homeassistant's: there an index names a host, here it names an issuer GROUP derived from the list, so moving one entry can change the grouping and renumber objects that were not themselves moved. AN ASYMMETRY WITH keycloak, named in the template header: there both modes render one object per entry, so the index question arises twice. Here it arises on the Ingress side ONLY - Gateway mode renders one HTTPRoute carrying every hostname, because TLS is none of the route's business, so there is no index and no name to go stale. Version stays 1.3.0+upv0.16.25: nothing is published yet, so nothing is being renamed in a release. Re-measured after the rename, not assumed: three empty helm template diffs against origin/main (defaults, CI fixture, overlay), helm lint --strict clean three ways, every abort path still firing with the structural one still winning over the per-entry one, the schema still rejecting mtaSts.enabled, and the HTTPRoute render test still at 64 assertions over 22 charts - object names are not assertions.	2026-10-13 11:03:36 +00:00
jklein	71b757bf9f	docs(README): the MTA-STS delta on top of both landed rounds, measured at 64/22 ... Second rebase of this branch, and the last one the parallel rounds force. Both have now merged - rss-bridge plus its documentation corrections, and the realm hostnames of #122 - so line 184 carries the chain 56/21 -> 58/22 -> 62/22 with the delta convention #124 introduced. That chain is kept WORD FOR WORD and this round's delta is appended to it; the only change to the line is an append, verified line by line against origin/main rather than asserted. THE NUMBER IS READ, NOT COMPUTED, and that distinction is this paragraph's own rule. 62 + 2 = 64 is arithmetic over a branch that had a different substructure when its 2 were measured; the figure committed here comes from ci/run-httproute-match-test.sh on THIS branch, rebased onto the main that already holds both other rounds: 64 assertions over 22 charts, 0 failed, with stalwart contributing 4. It is therefore the first figure in that sentence that is a genuine running total rather than a delta - the first run that contains all three rounds, which is exactly where the convention says to read it. The earlier 58/21 and 60/22 in this branch's history were each correct for the substructure they were measured on and are both superseded. The commit that set 60/22 was dropped in this rebase rather than carried, since its only content was a number that no longer holds.	2026-10-13 10:42:18 +00:00
jklein	771c26500c	fix(stalwart): let the mode conflict, not the MTA-STS entry, name the defect ... With BOTH routing modes on and an mtaSts entry missing its tlsSecretName, the render reported mtaSts.hosts[0] (mta-sts.example.com) has no tlsSecretName, and in Ingress mode every entry needs one which is true and is the wrong diagnosis: the values file's defect is that ingress.enabled and httpRoute.enabled are both true, and "in Ingress mode" is a claim about a configuration that is not coherent at all. Whoever met it would add a tlsSecretName, re-run, and reach the real message one round later - or conclude the MTA-STS feature was the problem. Measured on this chart, not reasoned about. And it is the second occurrence of a defect the parallel keycloak round of Gitea #122 found on its own realm list, independently and in the same round, which is what makes it a rule rather than one chart's story: a specific validation must not be reachable in a state that a structural validation already rejects. Ordering is not the fix and could not be - Helm renders templates in an order a chart cannot pin, so this template may not assume the httproute template's abort runs first. Scope is: the Ingress-mode MTA-STS block is now gated on ingress.enabled AND NOT httpRoute.enabled, so in the incoherent combination it validates nothing and the only fail left is the one that names the real problem. The per-entry guard is NOT dead by this - verified reachable with ingress.enabled alone. Defaults, the unchanged CI fixture and the overlay all still render byte-identically against origin/main, and the HTTPRoute render test still holds 58 assertions over 21 charts.	2026-10-13 10:41:10 +00:00