5 Commits

Include renames

Author	SHA1	Message	Date
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
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	0c403b6100	gotenberg: small requests, explicit higher limits ... The computed limits (limitFactor 3 x request = 1536Mi memory, 30Mi ephemeral storage) were too small for real documents: a 12 MB HTML already gets the container OOM-killed, and the caller sees no HTTP error at all, just a dropped connection and a rising RESTARTS counter. Rather than raise the requests and reserve conversion-sized capacity on the node around the clock, requests and limits are decoupled: the requests stay as they were, and both limits are now set explicitly. The chart already supported this - an explicit limit wins over the limitFactor computation. Measured in a throwaway k3d cluster with the official image (HTML via Chromium), building on the series in the issue: 18 MB HTML, 2Gi -> OOMKilled 18 MB HTML, 2560Mi -> OOMKilled 18 MB HTML, 3Gi -> HTTP 200 in ~22s, 21 MB PDF 12 MB HTML, 1536Mi -> OOMKilled (the old computed limit) 12 MB HTML, 2Gi -> HTTP 200 in ~13s Memory beyond 3Gi buys nothing: gotenberg's own request timeout is 30s and the chart passes no flags to change it, so a document needing more memory has already run out of time (a 25 MB HTML misses the 30s even at 4Gi). The ephemeral-storage limit is raised in the same change, because raising memory alone only moves the failure. With 3Gi memory and the old 30Mi limit, /tmp peaked at 40 MB on a single conversion and at ~125 MB over a short series, and the pod was evicted: Pod ephemeral local storage usage exceeds the total limit of containers 30Mi That failure is worse than the OOM-kill: the pod does not restart, it is replaced, and the old one is left behind as Evicted. The defaults in the effectiveResources helper are updated in lockstep with values.yaml, so an erased "resources:" block (#99) falls back to the new explicit limits instead of the old computed ones. NOTES.txt is pulled along. Its numbers came from effectiveResources already, but the text described a threshold that has moved and advice that no longer holds: raising the request no longer drags the limit with it now that the limits are explicit. The warning is kept but no longer claims memory is the first limit you hit - with these limits, the 30s timeout is. Major, because the runtime behaviour changes and the pod may occupy more memory during large conversions than it was allowed to before. Fixes #106	2026-08-23 22:35:22 +02:00
jklein	8bc673d80d	gotenberg: null-safe hardening, probes and resources ... Retrofit of #99 for a chart that already carries a values.schema.json, plus the schema type change that goes with it. An override written without children is YAML null. Where the chart defines a default, Helm's coalescing deletes the default before schema validation runs, so the schema never sees the null and cannot reject it: the container rendered "securityContext: null" - unhardened, healthy, silent. Where the chart defines no default (resources.limits), the null survives into validation and a strict "object" type aborted the render. The defaultedDict helper from #96 handles the first case; widening the types of exactly these blocks to ["object", "null"] handles the second. All other keys stay strict, additionalProperties: false is untouched. The probes address the container port by name, so a rebuilt default probe needs no further context. Rendering with normal values is byte-identical to 5.0.0.	2026-08-23 20:37:12 +02:00
jklein	09d8a94bfc	Add NOTES.txt to the gotenberg chart ... Gotenberg has no Ingress, so the notes lead with the cluster-internal URL and point out that the Service listens on 80 while the container listens on 3000 — the mismatch a consumer such as paperless-ngx has to get right — plus the port-forward command for reaching it by hand. Three findings from measuring the running chart went in as warnings: - The chart passes no command-line flags, so Gotenberg's basic auth, OIDC, SSRF guards and request timeout cannot be enabled through values at all. - Memory, not disk, is the first limit to hit: at the default limit a large document gets the container OOM-killed, the caller sees the connection dropped rather than an HTTP error, and the notes give the exact kubectl command that prints OOMKilled. - Temp space is an emptyDir counted against ephemeral-storage, where running out looks different — the pod is evicted and replaced, not restarted. Both limits are read back through the chart's own resources helper, so the printed figures follow limitFactor and any override instead of being hardcoded. Refs #43.	2026-08-23 20:30:22 +02:00