697 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
jklein	b4c9823e01	feat(stalwart): MTA-STS routes as a maintainable list, in both routing modes ... The policy route for mta-sts.<domain> belonged to another repository (jk-cluster-config) while pointing at this chart's own Service. It moves here as mtaSts.hosts, a list, so several domains - subdomains included - are maintainable in one place and in whichever routing mode is active. THE LIST IS THE SWITCH. No mtaSts.enabled: "enabled with an empty list" would be a state with no meaning that the chart would then have to catch. The schema rejects the key outright, so the rule is enforced rather than documented. Default [] renders nothing in either mode - the defaults and the unchanged CI fixture both produce a byte-identical helm template against origin/main. Entry form {host, tlsSecretName, clusterIssuer?}. The two TLS fields are read ONLY in Ingress mode; in Gateway mode TLS sits on the listener, so requiring them there would demand a value that does nothing. THE PATH IS HARDWIRED. RFC 8461 fixes /.well-known/mta-sts.txt, rendered with pathType Exact (type: Exact in the route). A values key for a protocol-mandated path can only ever be set wrong, and wrong is invisible from this side. Exact also matters in itself: a prefix on these hostnames would publish the mail server's whole management surface under them. ONE INGRESS PER CLUSTER ISSUER, NOT ONE OBJECT - and the plan's own three requirements forced that. cert-manager reads the two fields at different scopes: cluster-issuer is an ANNOTATION (object-scoped, and absent means nothing is issued for that object at all), while secretName is tls-entry-scoped and yields one Certificate per entry. So an object cannot both request a certificate and leave another host's secret alone, which is what an empty per-entry issuer has to mean. Measured in jk-cluster: ingress-shim names the Certificate AFTER THE SECRET and owns it from the Ingress, so a shared secret must sit in exactly one object (hence grouping the tls list by secret, reusing rss-bridge.tlsGroups' shape) and a secret may not span two issuer groups (hence the abort). Objects are named by issuer, not by index: an index is only free where the object holds no certificate, which is the precondition homeassistant's route naming states for itself. Gateway mode renders ONE HTTPRoute with every hostname - nothing differs per host there - attached to the same Gateway(s) as the WebUI route. WHAT THE CHART CANNOT PROMISE, AND THEREFORE NAMES: it registers a route, it does not create a domain. The domains live in Stalwart's data store, so an entry whose domain is missing there answers 404 at a correctly routed endpoint with every object green - and MTA-STS failures are silent on the SENDER's side, which delivers in the clear and logs nothing here. Same for the _mta-sts.<domain> TXT record and the policy's content. The subdomain trap is documented too: mta-sts.sub.<domain> is one label below *.<domain>, so a parent wildcard certificate does not cover it. Not folded into certificate.extraDnsNames deliberately - that would hang the MAIL certificate on this list, letting a bad policy entry take STARTTLS and IMAPS with it. Minor, additive, empty default: 1.2.0+upv0.16.25 -> 1.3.0+upv0.16.25. CI: ci/httproute/stalwart.yaml enters all three shapes of the entry form (with issuer, without, and a subdomain), taking the HTTPRoute render test from 56 assertions over 21 charts to 58 over 21 - stalwart from 2 to 4. The Ingress half cannot be covered there, since an overlay's whole job is to switch the mode off, so ci/stalwart/test-values.yaml carries two entries and the install-test has a real API server accept them. Fixes #123	2026-10-13 10:41:10 +00:00
jklein	649417b428	Merge pull request 'feat(keycloak): one hostname per realm, in both routing modes' (#125) from feat/keycloak-realm-hosts into main	2026-10-13 10:38:09 +00:00
jklein	5cdb2a6227	Merge origin/main into feat/keycloak-realm-hosts, and settle README line 184 ... The rss-bridge Gateway-API round landed while this branch was open, and the two rounds shared exactly one line: the sentence in README.md that carries the whole history of the httproute-match assertion count. Merged rather than rebased on purpose: the branch is already pushed and its history is not rewritten here, so nothing of the other round's text can be lost to a force push. Their half is kept verbatim, including the delta rule they added - that 58/22 and 60/21 were measured on branches which did not contain each other, so the delta is what either number can be trusted for, and the running total belongs to the first branch that holds both. This branch IS that first branch, so the open question is now answered with a measurement instead of an addition: 62 assertions over 22 charts, 0 failed, read off ci/run-httproute-match-test.sh on this merge. keycloak contributes 8 of them, plus the two "not checked" lines for its realm routes' backend-less redirect rules.	2026-10-13 10:29:55 +00:00
jklein	f530f58b1d	docs(rss-bridge): #51 was closed, and the cause was never identified (2.1.1) ... PR #124 merged at 12:25 and the maintainer closed #51 one second later, on the strength of that round's green install-test. Three statements that merged with #124 are stale as a result, and they are stale in the direction that matters - they describe a failing test and an open issue: - rss-bridge/templates/rss-bridge.httproute.yaml and values.yaml said the install-test "fails on the Gitea runner (#51)", in the present tense, and values.yaml added "and that test is still red". - ci/httproute/rss-bridge.yaml said "#51 is not closed on the strength of a colour", which was true when written and is now the opposite of what happened. Replaced with what is actually known, and the emphasis moved to the part that outlives the colour: the test went green on a render byte-identical to main, which rules the chart out and leaves the runner - and THE CAUSE WAS NEVER IDENTIFIED. The diagnostic programme in #51 (docker info for userns and the dind configuration, the same image in a local k3d without remapping) was not executed. So a recurrence is a fresh finding rather than a known quirk, and the overlay comment now says so where whoever sees the red will be reading. Also carries the wording change that was already on this branch when #124 merged: the reproduced green is phrased as "every run of that branch since" rather than pinned to a count, because each commit recording the count invalidated it - a third green arrived with the push after "two". Patch bump, per the rule #40 was argued on: a comment in a chart directory is still a change to that chart, so it is a patch plus a publish. No template output changes - the render for the fixture values is byte-identical to the pre-#124 main, which the tests re-confirm.	2026-10-13 10:28:09 +00:00
jklein	a411ec3c90	docs(rss-bridge): phrase the reproduced green without a run count ... The count was pinned at "two consecutive runs" and a third green arrived with the next push, which is a regress: every commit that records the number invalidates it. Phrased as "every run of that branch since" instead, which is stable, still establishes that it is not a fluke, and cannot go stale in main. The caution it carries is unchanged and is the one that matters: it is a colour, not a cause. Nobody has identified what changed on the runner, and #51's diagnostic programme is still unexecuted.	2026-10-13 10:25:55 +00:00
jklein	8896fc8d7d	docs(README): the 58/22 figure is a delta, not a running total ... Gitea #122 (one hostname per keycloak realm) is in flight concurrently and raises keycloak's share from 4 assertions to 8. Its round was measured at 60 over 21 on a branch that does not contain rss-bridge, while the 58 over 22 here was read on a branch that does not contain the realm hostnames. Neither total includes the other, so stating 58/22 as the figure after the sweep would be stale in main the moment the second of the two PRs merges. Says so now: the delta is what either round can claim, and the running total is whatever the first run on main prints once both have landed. Same rule, and the same wording, as the wiki's CI-CD page carries for the two rounds.	2026-10-13 10:20:48 +00:00
jklein	23ac537e24	docs(rss-bridge): the green install-test reproduced, so say "twice" rather than "one run" ... The previous commit recorded the install-test going green and hedged it with "it is one run". Pushing that commit produced a second run, on a second commit, and it was green too - run 792 job 2623 (1m10s) and run 794 job 2638 (1m14s), both with the chart genuinely in the matrix. So the hedge was understated in one direction and the real caution lies elsewhere. Corrected to say what is actually true: it reproduced over two consecutive runs, so it is not a fluke - and nobody has identified what changed on the runner, which is the reason #51 stays open. A green test does not explain itself, and the diagnostic programme in that issue's body (docker info on the runner for userns and the dind configuration, the same image in a local k3d without remapping) remains unexecuted. "Close an issue on a cause, not on a colour" is unaffected by the count.	2026-10-13 10:17:42 +00:00
jklein	7a2eb29e9e	feat(keycloak): one hostname per realm, in both routing modes ... keycloak.realmHosts gives a realm a hostname of its own: this release's Service published under a further name, with that name's bare / sent to /realms/<realm>/account/. It renders in BOTH modes - one Ingress per entry carrying nginx.ingress.kubernetes.io/app-root, or one HTTPRoute per entry whose Exact match on / carries a RequestRedirect filter - because a routing value in this repository is mode-independent by design - ingress.domain is read in Gateway mode too - so a feature rendering in one mode only would silently disappear when an installation switched. Default []: nothing renders, and the render is byte-identical to 1.2.0 for the fixture's values in both modes. Minor, additive, no value becomes required. ONE OBJECT PER ENTRY, not one with several hostnames. spec.hostnames applies to the whole object and a rule's matches are path-based, so inside a shared route every entry would match Exact: / and the realm could not be told apart. Names therefore carry the LIST INDEX, as homeassistant's per-host routes do and for the same reason - a realm name is not a dependable object-name fragment. The consequence is written down rather than left to be discovered: reordering the list renames and recreates the objects. THE WORK IS IN THE INGRESS HALF, NOT THE ROUTE. Two convention rules do not survive these objects, and both deviations are required rather than tolerated: tlsSecretName is a per-entry value with NO default, because these hostnames already have certificates and several entries typically share one, so a derived name would ask cert-manager for a second certificate for a name a wildcard already covers; and the cert-manager annotation is OPTIONAL per entry, because cert-manager keys a Certificate by the secret it writes and only one object per secret may request it - the same deliberate omission the qBittorrent object in freesailarr makes. Annotations are per entry too: of the four hostnames this was written for, three carry the proxy-buffer pair and one does not, which a chart-global block could not express. statusCode: 302 is written out at the field's own default. 301 and 302 are both Support: Core, so the portability trap of #119 - an implementation declining an Extended code sets Accepted: False on the WHOLE route - does not apply here; ingress-nginx emits 302 for app-root, and a value that is only accidentally right documents nothing. Five render aborts, each against a failure that reports nothing: an entry without a host (ingress-nginx reads an empty host as a catch-all for the whole controller), without a realm (/realms//account/, a 404 behind a healthy hostname and certificate), without a tlsSecretName in Ingress mode (the controller's default certificate, a browser-only failure), a repeated host or one the release already publishes (webhook rejection in Ingress mode, two merged routes decided by object age in Gateway mode), and a filled list with both modes off (no object at all, and nothing in the release that reveals the list was ignored). The entry-shape checks sit in a shared helper so they exist in both modes, and the Ingress template skips them while httpRoute.enabled is also true so that the specific message cannot hide the mutual-exclusion one. CI: the two entries live in ci/keycloak/test-values.yaml, which ci/httproute/keycloak.yaml is applied on top of, so one definition covers both modes - two Ingress objects in the install-test, two HTTPRoutes in the render test. They cover both Ingress forms, with and without a clusterIssuer, and the render test holds their inertness in Gateway mode. The httproute match test goes from 56 assertions over 21 charts to 60, keycloak's share from 4 to 8 plus two "not checked" lines for the backend-less redirect rules. The #118 prefix/redirect pairing correctly does not fire: it is scoped to rules that strip a prefix, and a realm route strips nothing. NOT IN THIS CHANGE: the migration. Nothing in jk-cluster-config is touched. With the default [] no running system changes, so the order a takeover has to run in is documented instead - remove the objects in the owning repository first, then install with the list filled, because the reverse or both at once is rejected by ingress-nginx's admission webhook and leaves a Fleet bundle in ErrApplied until forceSyncGeneration is raised. Whether anything there depends on those objects BY NAME is unchecked and named as unchecked. Fixes #122	2026-10-13 10:13:08 +00:00
jklein	7d365c912c	docs(rss-bridge): the install-test went green, and the chart is ruled out as the cause ... This chart's install-test had failed on the Gitea runner since the move (#51): php-fpm as uid 33 unable to read /app/index.php, the startup probe 403ing through its whole 150s budget, the pod never Ready. The chart was deliberately kept OUT of ci/excluded-charts.txt so that a pass would be noticed rather than silenced. It passed, in this PR. Measured from the run: k3d cluster up, helm install in Ingress mode, pod 1/1 Ready in 22s with 0 restarts, no "Permission denied" anywhere in the job, and all eight check contexts green. The chart is ruled out as the cause by a diff rather than by an argument: the rendered output for the fixture values is BYTE-IDENTICAL to origin/main - proven in the previous commit to justify the Minor bump - so the pod spec that succeeded is, line for line, the pod spec that had been failing. The implicated layer is the runner, which is where #51 had already placed the burden of proof. The control case arrived for free, from evidence collected for an unrelated reason. What this does NOT establish, and the docs say so: that it is repaired. It is one run, nobody has identified what changed on the runner, and an intermittent effect needs several runs per side. #51 therefore stays open and is to be closed on a cause, not on a colour - which was the standing instruction there before the green arrived. Corrected accordingly, because shipping documentation that says the test fails while it demonstrably passed is the half-finished state this repo tries not to leave behind: - README: the httproute-test paragraph, guideline 4's closing passage on the last chart of the sweep, and the chart table row. - rss-bridge/templates/NOTES.txt: the Gateway branch no longer claims the chart has no successful install-test. What remains true, and is what it now says, is that the install-test installs the INGRESS mode, so the Gateway mode is render-only - the same position as all 21 other charts of the sweep rather than a worse one. - ci/httproute/rss-bridge.yaml: same correction, plus why the overlay stays load-bearing either way. The wiki carries the same correction in the same round (rss-bridge, CI-CD) plus a Lessons-Learned entry on the decision that produced the signal: an excluded test is not a quiet test but a blind one, because you also lose the moment the fault stops existing.	2026-10-13 10:10:28 +00:00
jklein	45b2d2ea4e	feat(rss-bridge): Gateway-API as an alternative to the Ingress (last chart) ... rss-bridge was the twenty-second and last chart of the Gateway-API sweep: 22 charts carried an Ingress template, 21 an HTTPRoute template, and the difference was exactly this one. It had been held back as frozen by #51 - a runner defect, not a property of the chart - and that freeze is lifted. One HTTPRoute carrying ALL THREE hostnames, because nothing differs per host: every name serves the same Service at "/", measured on the live Ingress. spec.hostnames is a list, so one object is the whole answer and a second would repeat one rule. (Unlike homeassistant, whose paths differ per host, or matrix-synapse, whose two routes want different backends.) httpRoute.hostnames is its own MANDATORY value, which is a third shape for this repository and follows from the values rather than from taste. Most charts fall back to ingress.domain; freesailarr and homeassistant reject a hostnames key outright, because a chart-global list could not say which app or host entry it belonged to. This chart has no ingress.domain either, but its names are unambiguous - and the ingress.hosts list it would otherwise reuse carries per-host tlsSecretName values that address nothing once TLS sits on the Gateway's listener. Reusing it would drag a structure whose other half is meaningless into the new mode. rss-bridge.tlsGroups is therefore INERT in Gateway mode, and that is named as a simplification rather than quietly translated: the helper exists only to group hosts by TLS secret name, and there is nothing left to group. The required() on ingress.hosts needed no change to become conditional - it already sits inside the Ingress template behind ingress.enabled - so what is new is that values.yaml and the schema now say so. The ingress.enabled-derived-value screen that caught sure, freesailarr and ytdlp-web-player was run here and came back CLEAN: outside the Ingress template the only readers of an ingress value are NOTES.txt, which knows its own mode, and tlsGroups, called only from behind the switch. The app takes no base URL in its environment, so no "published" helper is needed. First chart of the sweep whose Gateway branch has NO loss to explain, and it was measured rather than assumed (read-only kubectl against the live object): the running Ingress carries the cert-manager annotation plus Helm and Rancher/Fleet bookkeeping, and not one nginx.ingress.kubernetes.io annotation. The group-3 screen came back empty, so NOTES.txt says so positively instead of copying a loss paragraph from another chart. Also corrects the last occurrence in the repository of the outdated sentence "charts in this repo deliberately have no dependencies" (rss-bridge/templates/_helpers.tpl) - dependencies are admissible but expensive since #214, and ytdlp-web-player, stalwart and paperless-ngx use subcharts. The reason the helper is duplicated is unchanged, only its content: sharing it would mean a library chart, a second artefact to publish, version and pull for about one change a year. Minor, not major: additive, defaults unchanged, and relaxing a required is not a tightening. Proven with an EMPTY helm template diff against origin/main for the defaults (229 lines, byte-identical); the Gateway mode with its overlay renders the HTTPRoute in place of the Ingress and nothing else changes. appVersion untouched - 2026-09-30 is the newest date tag the registry has, everything newer is sha-* and latest. ci/run-httproute-match-test.sh goes from 56 assertions over 21 charts to 58 over 22. The overlay at ci/httproute/rss-bridge.yaml has to SUPPLY hostnames, the second in the repository that does (homeassistant's was the first, for a different reason), because this chart has no fallback. NOT PROVEN, and stated in the PR as well: that traffic flows. No Gateway controller runs in CI and no HTTPRoute reaches "Accepted: True" there. For this chart there is additionally NO successful install-test at all - it fails on the Gitea runner in either mode (#51, reproduced on two images while the same chart and image run healthy in the cluster). The chart is deliberately NOT added to ci/excluded-charts.txt: an exclusion would silence the signal, and the day the runner is fixed the test goes green by itself. So the only red contexts expected here are "Install-test / Install-test rss-bridge" and the collective "Validate Helm Charts / Install-test". Fixes #114 Fixes #40	2026-10-13 09:58:11 +00:00
jlab-renovate-bot	6517643cd6	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.17.0	2026-10-13 09:38:25 +00:00
jlab-renovate-bot	96dd1adbda	Update l4rm4nd/vouchervault Docker tag to v1.30.3	2026-10-13 09:06:04 +00:00
jklein	6d79d8f270	docs(README): group 3 of the Gateway-API sweep, and four corrections it forced ... The figures: the HTTPRoute render test goes from 37 assertions over 15 charts to **56 over 21**, with the per-chart breakdown, and the sweep is finished except for the frozen rss-bridge - so #114 still cannot be closed while #51 is open. FOUR CORRECTIONS, because three of #114's descriptions of the group-3 shapes and one of this file's own forward-looking claims did not survive contact with the charts. The corrected list is a table in section 4, since that is what somebody will copy from: - bulwark has ONE Ingress, not two. keycloak has two. - bulwark has NO rewrite-target and cannot have one: NEXT_PUBLIC_BASE_PATH is compiled into its bundle. #114's table reached "bulwark, freesailarr" by grepping for the string, and every occurrence in that chart is an explanation of why the annotation does not help. freesailarr is therefore still the only chart the #118 prefix/redirect pairing applies to - the HTTPRoute-test section said bulwark would meet it "when group 3 lands", and now says why it does not. - matrix-synapse does NOT render in a loop over several apps (that is freesailarr): one Ingress object with two HOST rules, which has to become two HTTPRoute objects because spec.hostnames applies to the whole object. - stalwart does not render a routing object per node group - its Services and StatefulSets do; one route targets ingress.nodeGroup's own http Service. THREE NEW CONVENTIONS, written where the next sweep will read them: - SCREEN THE LIVE OBJECT, not only the chart. Four of group 3's six charts carried an annotation the chart never sets and the Gateway mode drops - keycloak's proxy buffers on BOTH its Ingresses, matrix-synapse's body size and snippet, stalwart's whole CORS block, bulwark's body size. None of them appears in a git grep of this repo. At #118 this was found after shipping; here it was measured beforehand with read-only kubectl, and that measurement is now part of the procedure. - READ THE DIRECTIVE before calling an annotation load-bearing. matrix-synapse's configuration-snippet uses more_set_headers, which is the headers-more module's OUTPUT-header directive - so those headers go on the response and Synapse never sees them. The scariest-looking loss in the group is not a loss, and its NOTES.txt says not to re-create it. - "NO COUNTERPART" IS A CLAIM TO CHECK AGAINST THE PINNED CRDs, and for CORS it is false. Grepped out of gateway-api v1.6.3 standard channel: HTTPRoute filters carry a full cors field (GEP-1767), Support: Extended, and responseHeaderModifier is Extended too rather than Core. stalwart still renders neither, and the three reasons are recorded - no CORS values to render from, Extended support is not support (Cilium accepts the filter and forwards the preflight anyway), and the preflight is the half a bare header filter cannot do while Authorization in the allowed headers makes every request preflighted. Also: pathType ImplementationSpecific has no counterpart and is a chart DEFAULT in homeassistant - PathPrefix on "/", render abort on any other path, and RegularExpression deliberately not offered. The ingress.enabled-derived-value screen is closed: ytdlp-web-player was the third and last find, and its guard is the one that is needed MORE in Gateway mode, because the ingress-nginx admission webhook never sees an HTTPRoute and the silent outcome is an authentication bypass that depends on DNS. A subchart does not come along: oauth2-proxy has no Gateway support, so in the recommended configuration the subchart's Ingress publishes the release in both of the chart's modes. And stalwart is the only chart in the sweep still rendering a Certificate in Gateway mode, for its mail listeners. The homeassistant documented-exception bullet now covers its Gateway mode: no httpRoute.hostnames key (the second chart without it), one route per ingress.hosts entry, index-based route names and what reordering the list costs. Part of #114	2026-10-13 08:59:09 +00:00
jklein	e4b41577ae	feat(ytdlp-web-player): Gateway-API as an alternative to the Ingress ... Group 3 of the #114 sweep, last chart - and the one that carried the group-2 pattern this sweep was told to look for. It reads ingress.enabled OUTSIDE its Ingress template, in ytdlp-web-player.validate, and in Gateway mode ingress.enabled is false by construction, so that guard would have gone silent. Fixed with ytdlp-web-player.published = ingress.enabled OR httpRoute.enabled - the freesailarr.published / sure.publishedOverTls shape, identical to ingress.enabled while httpRoute.enabled is false, which is why it changes no existing render. AND THE GUARD IS NEEDED MORE IN GATEWAY MODE, NOT LESS. It refuses to publish the application and the oauth2-proxy on the same host: - In INGRESS mode the consequence of ignoring it is loud: ingress-nginx's admission webhook rejects the second Ingress and the Fleet bundle goes to ErrApplied. - In GATEWAY mode THE WEBHOOK NEVER FIRES. It compares Ingress objects with Ingress objects, and an HTTPRoute is a different kind - so nothing rejects anything, both objects stay valid, and one hostname is served over two data paths that are NOT equivalent: the proxy's Ingress goes through AUTHENTICATION and this chart's HTTPRoute goes straight to the application. Which one a client reaches depends on what DNS resolves to. That is an authentication bypass that comes and goes with a DNS record and that no Kubernetes object reports. So the Gateway-mode abort has its own message saying exactly that. Both messages exercised, plus the collision reached through httpRoute.hostnames rather than through the ingress.domain fallback, and the guard still firing when only the Deployment is rendered. THE SUBCHART HAS NO GATEWAY SUPPORT, and this chart cannot give it one - upstream's chart is consumed as it comes (README, "Chart dependencies"). It renders an Ingress or nothing. So in the RECOMMENDED configuration, where the proxy sits in the data path and owns the host, the publishing object is the SUBCHART'S INGRESS in both of this chart's modes, and turning httpRoute on buys nothing. The route is for the proxy-disabled case, or for the application on a host of its own - which is the documented unauthenticated bypass. Said in the template header, in values.yaml, in the schema and in the proxy branch of NOTES.txt, because someone migrating hosts will otherwise set the value and wonder why nothing moved. The 16k proxy-buffer-size this chart recommends is NOT lost by this switch, and that needed stating rather than assuming: it belongs on the PROXY's Ingress (oauth2-proxy.ingress.annotations) as the second half of the 4kB session-cookie trap, and the subchart keeps rendering an Ingress. This chart's own ingress.annotations default is {} and it sets nothing but the cert-manager annotation, so there is no chart-side annotation loss to name. CORRECTED CLAIM: values.yaml and the schema both said that everything the Ingress needs is read only inside its template, so switching it off freed BOTH ingress.domain and ingress.clusterIssuer. clusterIssuer is still freed; domain is now read by the HTTPRoute, so it is freed only with both modes off. The reason the claim was made still holds and is kept - the application has no base-URL setting and builds no absolute links. NOTHING WAS MEASURED ON A LIVE INGRESS OF THIS CHART, because there is none. Measured 2026-10-12: the release runs in namespace jlab-player with both Deployments Ready, and NOT ONE of the cluster's 23 Ingress objects is in that namespace - neither this chart's nor the subchart's. What publishes it instead could not be determined: this workspace's identity may not list httproutes or secrets, so neither a hand-written HTTPRoute nor the release's Helm values are readable. Recorded as the open question it is, in values.yaml and in the overlay, rather than guessed at. Minor: additive, defaults unchanged. Empty helm template diff against origin/main with ci/ytdlp-web-player/test-values.yaml. Part of #114	2026-10-13 08:59:09 +00:00
jklein	b10800da2a	feat(homeassistant): Gateway-API as an alternative to the Ingress ... Group 3 of the #114 sweep, and the one chart where the convention had to bend rather than the chart. homeassistant is the DOCUMENTED INGRESS EXCEPTION (README): upstream's flexible values, a list of hosts each with its own list of paths, instead of the repo's required domain/clusterIssuer pair. The exception stays - nothing here unifies it. NO httpRoute.hostnames KEY, which is the freesailarr shape from group 2 and for the same reason: there is no ingress.domain to fall back to, and a chart-global hostname list could not say which host entry - and therefore which set of paths - it belonged to. So httpRoute carries only enabled and parentRefs, the hostnames come from ingress.hosts, and the chart renders ONE HTTPRoute PER ENTRY with one rule per path of that entry. One object with several hostnames would be wrong, not merely different: an HTTPRoute's rules apply to every hostname of the object, and per-host paths are this chart's whole point. The schema rejects httpRoute.hostnames outright, so the absence is enforced rather than merely intended. ingress.hosts is therefore read in BOTH modes and is not an Ingress-only value. ingress.className, ingress.tls and ingress.annotations are not read in Gateway mode: class and certificate belong to the Gateway's listener, and there is no annotation channel. pathType IS THE SHARP EDGE, AND THE CHART'S DEFAULT IS THE AWKWARD VALUE. Ingress has Exact/Prefix/ImplementationSpecific; the Gateway API has Exact/PathPrefix/RegularExpression. Exact and Prefix map cleanly. ImplementationSpecific - the default in values.yaml - means "ask the controller" and has NO counterpart, so: - on "/" it renders as PathPrefix. Every controller treats a root ImplementationSpecific path as a prefix match, so the chart's own default works in this mode unchanged (verified: the untouched default renders a valid route). - on ANY OTHER path the render ABORTS, naming the value and asking for Prefix or Exact. In ingress-nginx - this chart's default class - an ImplementationSpecific sub-path is a REGEX, and PathPrefix is not one. Mapping it silently would change how the path matches while the render stayed green, which is exactly the class of defect #118 was. RegularExpression is deliberately not offered as an escape hatch: its support level is Implementation-specific, which decision 1 of #114 forbids. NOTHING WAS MEASURED ON THE LIVE CLUSTER FOR THIS CHART, because there is nothing to measure: homeassistant is NOT DEPLOYED in jk-cluster (checked 2026-10-12 - 23 Ingress objects cluster-wide, none this chart's, and no workload of it in any namespace). So it is the one chart of the six with no operator-supplied annotation to lose. values.yaml and NOTES.txt say that as an absence of evidence about this installation rather than as a property of the chart. Route NAMES carry the entry's INDEX, not its hostname - a hostname is not a dependable object-name fragment. Consequence named in values.yaml and in the template: reordering ingress.hosts renames routes and therefore recreates rather than edits them. Harmless, since a route holds no state and no certificate. ci/httproute/homeassistant.yaml has to SUPPLY HOSTS, which no other overlay in the sweep does, and it adds coverage the install-test never had: this chart's ingress.enabled defaults to FALSE and the fixture does not switch it on, so no routing object was exercised at all before. Two entries on purpose - a plain one, and one with two paths including an Exact - because that second entry is what proves the chart renders one object per host rather than one object with several hostnames. 5 assertions over 2 routes and 3 rules. NOTES.txt asks $published where it asked ingress.enabled, and the trusted_proxies section now warns that moving from an Ingress to a Gateway CHANGES the proxy's pod network: a list carried over unchanged turns every request into a 400 if the CIDR differs, or silently keeps attributing every client to one address if it does not. Minor: additive, defaults unchanged. Empty helm template diff against origin/main, both with the fixture as it stands and with ingress.enabled=true. Part of #114	2026-10-13 08:59:09 +00:00
jklein	3e969c5659	feat(stalwart): Gateway-API as an alternative to the Ingress ... Group 3 of the #114 sweep. ONE route - not one per node group. #114 describes this chart as rendering "per node group"; its SERVICES and StatefulSets are, the routing object is not and must not be. The route targets exactly ingress.nodeGroup's own http Service and keeps both of the Ingress's guards, because the WebUI's setup and management screens are not safe to spread over a group that may not run the management tasks. ingress.nodeGroup is therefore shared by both modes: it names where the management surface is published from, which is not a property of the Ingress. THE MAIL CERTIFICATE STAYS, and this is the only chart in the sweep where anything of the TLS path does. stalwart.certificate.yaml covers STARTTLS on 25 and implicit TLS on 465/993; those connections pass through neither an ingress controller nor a Gateway. So in Gateway mode ingress.domain is still required (the certificate's dnsNames read it), ingress.clusterIssuer is still required unless certificate.clusterIssuer is set, and the Certificate must NOT be removed as part of a migration - deleting it drops SMTP and IMAP back to Stalwart's self-signed certificate, with clients seeing a name mismatch while every Kubernetes object stays green. Verified in the render: Gateway mode emits Certificate + HTTPRoute and no Ingress. WHAT THIS MODE DROPS - AND HERE IT BREAKS A SECOND CHART OF THE SAME GROUP. Measured on 2026-10-12, the live Ingress on mail.bekemeyer-klein.de carried, all of it operator-supplied through ingress.annotations (this chart sets none of it): enable-cors: true cors-allow-origin: https://webmail.bekemeyer-klein.de cors-allow-methods: GET, POST, OPTIONS cors-allow-headers: Authorization, Content-Type That origin is BULWARK, the webmail chart in this same group. Without the CORS configuration the browser-side webmail cannot call this server's JMAP endpoint at all, and the failure is entirely client-side: a console error, nothing in the server's logs. AND "no counterpart" WOULD HAVE BEEN WRONG. Measured by grepping the CRDs this repo pins (gateway-api v1.6.3 standard channel, ci/gateway-api-crds.sh) rather than inferred: HTTPRoute's filters carry a full 'cors' field (GEP-1767) with allowOrigins/allowMethods/allowHeaders/allowCredentials/maxAge, and its documented level - verbatim from that CRD - is "Support: Extended". responseHeaderModifier is in the same CRD and is also Extended, not Core. The chart still does not render it, for three reasons in order: 1. The chart has NO CORS values. The live configuration is the operator's, and the chart sets no CORS annotations in Ingress mode either - so rendering a filter means inventing a values surface that would exist in Gateway mode only. That asymmetry is its own defect and its own work. 2. Extended support is not support. A rejected route is rejected WHOLE, which would take the WebUI and JMAP down together (the reasoning #119 reached for statusCode); and the observed failure is quieter - Cilium accepts filters.type: CORS and forwards the preflight upstream anyway (cilium/cilium#45272), i.e. Accepted: True with the behaviour absent. 3. Half a CORS is worse than none, and the translatable half is the useless one HERE. A responseHeaderModifier can add the Access-Control-Allow-* headers; the PREFLIGHT has to be answered BY THE GATEWAY, which the CORS filter's own contract states and a bare header filter cannot do. Because the allowed headers include Authorization, EVERY webmail request is preflighted - so the expressible half is exactly the half that does not help. Named, not rebuilt (decision 2 of #114), in values.yaml, in the schema and in the Gateway branch of NOTES.txt, with the operational instruction: configure CORS at the Gateway with that implementation's own support BEFORE moving this host, and test it from the webmail in a browser - curl sends no preflight, so it passes while the webmail fails. NOTES.txt now asks $published (ingress.enabled OR httpRoute.enabled) where it asked ingress.enabled, and two paragraphs that named the ingress controller specifically now name the Gateway in that mode: the auto-ban step (switching API does not avoid or reset it - one proxy address instead of another) and the NetworkPolicy paragraph, where the namespace to allow is the Gateway's data plane rather than an ingress controller's. Minor: additive, defaults unchanged. Empty helm template diff against origin/main with ci/stalwart/test-values.yaml. Part of #114	2026-10-13 08:59:09 +00:00
jklein	e54cfe5fdd	feat(matrix-synapse): Gateway-API as an alternative to the Ingress ... Group 3 of the #114 sweep. TWO HTTPRoutes - and the shape is not the one the issue described. #114 says this chart renders its Ingresses in a LOOP OVER SEVERAL APPS. It does not; that is freesailarr. It renders ONE Ingress object with TWO HOST rules: the homeserver on ingress.domain at "/", and the delegation nginx on matrix.delegation.serverUrl at "/.well-known/matrix". An HTTPRoute's spec.hostnames applies to the WHOLE object, so two hostnames that want different paths and different backends have to be two objects. That is the only faithful translation, not a stylistic choice. httpRoute.delegation.hostnames deliberately does NOT fall back to httpRoute.hostnames. The server name is what REMOTE homeservers resolve and is a different thing from the homeserver's own hostname; the migration order - homeserver host first, server name last - depends on telling them apart, and a chart-global hostname list covering both would erase the distinction. httpRoute.delegation.parentRefs falls back to httpRoute.parentRefs, which matters because the server name is usually an apex domain behind a different Gateway. ONE THING THIS MODE IMPROVES, and it is the awkward part of Matrix delegation. Under ingress-nginx two Ingress objects cannot both claim one hostname - the admission webhook rejects the second - which is why the delegation rule has to live inside this chart's single Ingress object even though the apex domain usually belongs to a website. HTTPRoutes attached to the same listener for the same hostname are merged by the implementation, longest match winning, so the /.well-known/matrix route can sit beside whatever owns that apex. WHAT THIS MODE DROPS, MEASURED ON THE LIVE OBJECT ON 2026-10-12 - and ONE OF THE TWO IS NOT WHAT IT LOOKS LIKE. The live Ingress carried, all of it operator-supplied through ingress.annotations (this chart sets none of it): nginx.ingress.kubernetes.io/proxy-body-size: 50m nginx.org/client-max-body-size: 50m nginx.ingress.kubernetes.io/configuration-snippet: | more_set_headers "X-Forwarded-For $remote_addr"; more_set_headers "X-Forwarded-Proto $scheme"; more_set_headers "Host $host:$server_port"; 1. THE BODY SIZE IS THE REAL LOSS. Synapse's media repository takes uploads; its own ceiling is max_upload_size in homeserver.yaml, which this chart cannot see because the whole config arrives from 1Password. The effective limit is the smaller of the two, and in this mode the proxy half becomes the GATEWAY'S default - neither number anyone can point at is necessarily the one that decides. No counterpart in the Gateway API, so per decision 2 of #114 it is documented, not rebuilt. nginx.org/client-max-body-size is the same limit spelled for NGINX Inc's controller, a hedge across both implementations, and it goes for the same reason. (#114's own measured table did not list matrix-synapse under proxy-body-size at all; the live object has it.) 2. THE SNIPPET IS NOT LOAD-BEARING, which took checking rather than assuming. It looks like what Synapse's x_forwarded setting depends on - client IP for rate limiting, and federation. It is not: more_set_headers is the headers-more module's OUTPUT-header directive ("Replaces (if any) or adds (if not any) the specified output headers"), the request-side directive being more_set_input_headers. So those three headers are added to the RESPONSE TO THE CLIENT; Synapse never sees them, and what it reads with x_forwarded: true is the REQUEST's X-Forwarded-For, which ingress-nginx supplies itself. The Gateway API's ResponseHeaderModifier could not rebuild it anyway (it knows no nginx variables), and should not: NOTES.txt says in as many words not to re-create it and not to read its absence as the cause of a rate-limiting or federation problem. Stated as what it is - a reading of the directive's documented semantics. Nothing here observed a Synapse instance with and without the snippet. NOTES.txt now asks $published (ingress.enabled OR httpRoute.enabled) wherever it used to ask ingress.enabled - the server-name/serverUrl mismatch warning, the "clients work fine" aside and the scaled-to-zero paragraph were all really asking whether anything publishes the release. Minor: additive, defaults unchanged. Empty helm template diff against origin/main with ci/matrix-synapse/test-values.yaml. Part of #114	2026-10-13 08:59:09 +00:00
jklein	9625d8b182	feat(bulwark): Gateway-API as an alternative to the Ingress ... Group 3 of the #114 sweep. One route, one rule, at the root - and THREE EXPECTATIONS ABOUT THIS CHART DID NOT SURVIVE CONTACT WITH IT: - #114 says bulwark has TWO Ingress objects. It has ONE. keycloak has two. - #114's measured table lists bulwark under rewrite-target. It has no rewrite-target annotation and CANNOT have one: NEXT_PUBLIC_BASE_PATH is compiled into the bundle, so the application cannot be served under a sub-path, and stripping a prefix at the proxy would yield a page that loads and then fetches everything from the wrong place. Every occurrence of the string "rewrite-target" in this chart - values.yaml, the schema, the Ingress template - is an explanation of exactly that. A grep for the string finds the refutations and counts them as occurrences. - ci/run-httproute-match-test.sh said in its header that bulwark was the second rewrite-target chart and would meet the #118 prefix/redirect assurance when group 3 landed. Group 3 landed and it does not: with no URLRewrite on a prefix other than "/", the assurance's precondition is never met here. The header is corrected rather than left standing, and it now says freesailarr is the only chart the pairing applies to. So no redirect rule is added, and none is needed. WHAT THIS MODE DROPS, MEASURED ON THE LIVE OBJECT rather than inferred. On 2026-10-12 the live Ingress on webmail.bekemeyer-klein.de carried nginx.ingress.kubernetes.io/proxy-body-size: 25m supplied by the OPERATOR through ingress.annotations - values.yaml recommends exactly that value and explains why the chart cannot pick it, so the chart sets nothing and a reader of this repository alone would not find it. It is the single annotation this installation depends on, and the Gateway API has no body-size counterpart: implementation policy, not routing. Per decisions 1 and 2 of #114 it is NAMED, not rebuilt - in values.yaml, in the schema and in the Gateway branch of NOTES.txt, in this application's own terms: an attachment above the Gateway's default is rejected before Bulwark sees a byte, the 413 comes from the proxy, and it arrives after the user has written the mail and attached the file. CORRECTED CLAIM, the same one garage and calibre-web-automated needed: the Ingress template, the bulwark.publicUrl helper and the schema all stated that nothing outside the Ingress template FUNCTIONALLY reads ingress.domain. The HTTPRoute reads it, so the claim held only while both modes were off. All three now say so, and the route carries a required() of its own. bulwark.publicUrl follows the ACTIVE mode instead of always printing ingress.domain. The two differ exactly when httpRoute.hostnames is set, which is how a migration off the Ingress runs - and printing the old host there would hand the operator an OIDC redirect URI for the hostname being migrated away from, a failure that surfaces as a rejected login at the identity provider and says nothing about this chart. Minor: additive, defaults unchanged. Empty helm template diff against origin/main with ci/bulwark/test-values.yaml. Part of #114	2026-10-13 08:59:09 +00:00