feat!: a NetworkPolicy in every chart, on by default #133
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#133
Reference in new issue
Block a user
Rollout of Gitea #5: every chart gets a NetworkPolicy,
networkPolicy.enabled: trueby default, one major per chart — following the plan approved in the last comment on the issue.This PR is in progress. It opens early on purpose: the enforcement proof the whole scope rests on has to run in CI before 29 charts are switched over, and partial work that is pushed survives an interrupted agent. The chart list below is kept current as commits land.
What was measured, not assumed
Re-verified against the live cluster before anything was written, because the issue body describes a cluster that no longer exists:
traefik, as the default; nonginxclasskube-system, DaemonSetrke2-traefik, pod labelapp.kubernetes.io/name: rke2-traefik,web=8000 websecure=8443 traefik=8080 metrics=9100One addition to the plan's table, and it matters: the GatewayClass controller is
traefik.io/gateway-controllerandcluster-gatewayholds no pods of its own. The samerke2-traefikDaemonSet serves both the Ingress and the HTTPRoutes from the Gateway sweep (#114), so one source selector covers both paths — no second controller entry is needed anywhere.A policy written against ingress-nginx would have been accepted, would have looked strict, and would have silently blocked all web traffic.
And one cluster setting this whole convention rests on and cannot check: Traefik runs without
hostNetwork, so its pods have real pod IPs (10.42.3.120,10.42.4.94,10.42.0.187in the pod CIDR10.42.0.0/16, nodes on entirely different addresses) — and only because of that does apodSelectormatch it. On host networking those pods would share the node's namespace, stop being selectable as pods, and every web chart would go dark at once while every pod stayedReady, because the probe path does not run through the controller. Same class as--enable-certificate-owner-refin #126; recorded in README §15 and in the header oftemplate-chart's policy so whoever changes the controller's networking meets it there.The convention
Per chart,
templates/<chart>.networkpolicy.yaml, valuesnetworkPolicy.{enabled,allowedNamespaces,probeSources,ingressController,egress.extraPorts}.Each port of a workload falls into one of four classes, and the class decides the rule:
fromby default and restricted onceprobeSourcesis set. The kubelet probes from the IP of the worker node running the pod, which no chart can know; a guessed CIDR that misses it drops every probe and the pod never becomes Ready — a symptom that reads as a broken application.execprobes are not in this class: they run inside the container and put no packet on the network, which is exactly whyvalkeyandminecraft-servercan restrict their port by source with noprobeSourcesat all.from, because the source is the internet and arrives already masqueraded.allowedNamespaces, and the ingress controller where the chart routes HTTP to that port.No chart ships
allowedNamespacespre-filled. A chart namingmc-routerorstalwartin its defaults would bake in an assumption about this cluster's namespace layout, which a chart cannot keep true — so the default is empty and restrictive, and filling it is the deployment adaptation. That is why this PR produces a list of release-side one-liners: they are the expected procedure, not a defect list, and the breaking-change major on each chart is what announces them.ingressControlleris a separate value rather than a line inallowedNamespacesfor one reason: its two keys render as onefromentry, which is an AND. Puttingkube-systemintoallowedNamespacesinstead would open the port to every pod inkube-system.What these policies do NOT do
Written per chart rather than quietly accepted:
GlobalNetworkSetcould express one but would bind every chart to Calico — the same argument that kept implementation-specific objects out of #114. So it is not used.CI:
ci/run-networkpolicy-test.sh+ theNetworkPolicyjobEvery rendered policy is held against the pod specs, probes and Services of the same render. Helm is the parser through
ci/yaml2json, as in the other render tests — the runners have neitherpyyamlnoryq.podSelectormatches a pod spec of that render;containerPortof the selected pods — this catches the NodePort mistake mechanically. Egress ports are deliberately excluded: an egress port belongs to the destination;probeSourcesand the consequence inNOTES.txt.Plus two guards: a chart that renders no policy fails (which is how this issue decayed —
garageandkeycloakwere 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 ships to the cluster.Assertion 3 is stricter than the plan's wording, deliberately. The plan banned a missing or empty
from.from: []always fails — it allows everything while reading as a restriction. A missingfromis the documented open form that both precedents use on purpose, so it is accepted only where the render itself justifies it: every port of the rule is probed, or published by a NodePort Service. Anything else is an allow-all nobody chose.All failure paths were executed, not only the green ones — 12 cases, and one earned its keep immediately: the
probeSourcescheck 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.What stays unprovable
satisfactoryhas no install-test coverage at all (ci/excluded-charts.txt). For that one chart the review is the only net.Charts — all 29, plus the reference
template-chart(reference) ·apache-tika·bentopdf·bulwark·calibre-web-automated·cyberchef·freesailarr·garage·gotenberg·homeassistant·keycloak·matrix-synapse·minecraft-router·minecraft-server·outline·paperless-ngx·patchmon·rallly·rss-bridge·samba·satisfactory·searxng·stalwart·sure·teamspeak-server·urlaubsverwaltung·valkey·voucher-vault·ytdlp-web-player·ziplineOne major each.
ci/run-networkpolicy-test.sh: 30 charts, 206 assertions held, 0 failed.The charts worth reviewing first, because they decided things
keycloakhttprule is the only genuinely source-restricted inbound rule in the sweep — possible only because the probes use the management port. If the ingress-controller source is wrong, every login in the cluster stops, and nothing in CI can see it: no controller runs there and the probes use 9000, so the pod goesReadyeither way. Port numbers and the database port are derived fromkeycloak.settings.homeassistant,satisfactorypolicyTypes: [Ingress], no egress section. Each argues it in its own file.satisfactory's deciding half: it is the one chart with no install-test at all, so an egress cap there would be the only one in the sweep with no empirical check behind it, on the chart whose correct port set (Steam's CDN) is least knowable.minecraft-serverexecprobes, so no port has to stay open for the kubelet and noprobeSourcesvalue exists. Its game port has two branches rendered from the same value the Service reads.gotenbergnetworkPolicy.egress.remoteAssetsas a named switch, off by default, for releases that need remote images. Measured: paperless sends the.emlto Tika and the resulting HTML here, so embedded images are MIME parts needing no network (Tika stays DNS-only) while remote ones are fetched by Chromium and silently dropped with the switch off.bulwarkjmapServerUrlon a port the policy blocks yields aReadypod serving an empty webmail.matrix-synapsesamba,satisfactory,teamspeak-servervalkey,stalwartstalwartgainsingressControllerand a correction: it advisedallowedNamespaces: ["ingress-nginx"], and both halves of that are wrong.Keycloak's blast radius, measured
The
keycloakrow above is the largest risk in this PR, and it is now smaller than it first read. Every readable in-cluster consumer addresses Keycloak by its public name, so its traffic arrives from Traefik and is permitted by the rule exactly as shipped:bulwarkOAUTH_ISSUER_URL = https://id.mail.bekemeyer-klein.de/realms/mailhomarrAUTH_OIDC_ISSUER = https://bk.id.bekemeyer-klein.de/realms/bekemeyer-kleinpaperless-{jk,cmk,ngx}PAPERLESS_SOCIALACCOUNT_PROVIDERSblockA search across pod environments and ConfigMaps for the in-cluster Service name (
keycloak-keycloak-service,*.keycloak.svc) returned only Keycloak's own pods, reachingkeycloak-pg-rw.jlab-pg.svc.cluster.local:5432— which incidentally confirms the egress rule derived fromkeycloak.db.portis right for the live release.The login test after the upgrade stays the acceptance criterion, because a consumer whose issuer URL lives in a secret or a realm import is not covered by that search. What changed is that there is now a measured reason to expect it to pass.
Three things the checks caught while this was written
minecraft-server's RCON rule named a port the pod does not declare — thecontainerPortis gated onserver.rcon.enabledand the rule was not. Assertion 2 rejected it.sambaandsatisfactorywould have shipped values that reach no rule. Every one of their inbound rules is open to any source, soallowedNamespacesandprobeSourcesdid nothing. A value that silently does nothing is worse than one that is absent, because it reads as a control — both are gone from those charts and their schemas, with the reason invalues.yaml.probeSourcesassertion was a substring test, so a chart whose key had been deleted while the comment above it still discussed the value passed. Found by running the fail path; it now looks for the key.gotenberg's newNOTES.txtbranch read.Values.networkPolicy.egress.remoteAssetsdirectly, which fails the whole render withnil pointer evaluating interface {}.remoteAssetswhen an operator erases theegressblock — the schema permitsnullthere, and issue #99's rule is that an erased block means the default applies, not a broken render. Null-safe now, and an erased block falls back to DNS-only, which is the restrictive direction.Docs
README.md(style guideline §15 + the CI section) andCLAUDE.md(the binding compact summary). Wiki, pushed as8198027:Chart-Style-Guide§15,CI-CD§8 (later jobs renumbered),Charts, all 29 chart pages plustemplate-chart, and fourLessons-Learnedentries — the net that existed for a different failure than the one it was built for; a template comment that could not describe its own syntax; three values that reached no rule; and the subchart whose comments the parent could not fix.Fixes #5
The enforcement proof: measured, and the answer is not the one the plan assumed
Two experiments on this branch, run 888. Both are reverted; the commits are kept for the record (
d3ef372,813c923,de995d0).Install-test cyberchef192.0.2.11/32— an RFC 5737 documentation address that cannot be the k3d nodeInstall-test outlinepostgresandredisdo not resolve and/_healthcannot passPolicies ARE enforced in the install-test. Outline never became Ready and
rollout statustimed out after six minutes. That is the net this rollout needs, and it exists.But the kubelet 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 originate from. So the specific claim in the plan — "eine Policy, die den Probe-Pfad blockiert, sollte den Pod nie Ready werden lassen und den Install-Test rot machen" — does not hold here. It is now measured instead of assumed.
Why I kept going rather than stopping
The net holds for the failures this rollout can actually produce, and the one it misses is not reachable from the defaults:
fromuntil an operator setsprobeSources, so the trap CI cannot see is not triggered by this PR — only by a deliberate narrowing, which is exactly what theNOTES.txtsentence and the fourth CI assertion are for.If you read the trade differently, this is the point to say so: the scope question is still open until the chart commits land, and I will rework rather than argue.
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 #5garage, 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 #5matrix-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 #5Release-side actions this PR creates — measured against the live cluster
I have not touched
jk-cluster-configand opened no PR there, as instructed. This is the list of what the merge will need on the release side, separated into what I could verify and what only you can.Verified against the live cluster — the egress guesses are right
The convention's weakest point is that most egress ports are the standard ones rather than the configured ones. For this cluster they match:
postgres-18-postgresqlmaria-db-mariadburlaubsverwaltungallows both)*-valkey-service(6 of them)paperless-ngxallows 80 ✅So no existing release should lose its database, cache or OIDC on upgrade. No ServiceMonitor or PodMonitor exists in the cluster, so the restricted metrics ports (
minecraft-server19565) break no scrape.Needs a values change at release level — measured, not guessed
All four Minecraft servers run a
ClusterIPService, which means the restricted branch ofminecraft-server's game-port rule applies to every one of them:Players reach them through
minecraft-router, which runs in themc-routernamespace. So each of those four releases needs:Without it the server is unreachable and the symptom is a connection timeout in a game client with a perfectly healthy pod behind it. This is the single most likely outage from this PR, and it is four one-line values changes.
Needs checking by you — I cannot read the values that decide it
garage— its s3 rule is restricted by source, andstalwarthasSTALWART_S3_ACCESS_KEY/SECRET_KEYwired, so it is using an S3 store. If that store is garage's in-cluster address, garage needsallowedNamespaces: ["stalwart"]. I cannot tell: Stalwart's blob store is an object in its database, created in the WebUI, so the host appears in no chart value and no readable object. Any other S3 consumer in another namespace needs the same.keycloak— thehttprule is the only source-restricted inbound rule in the PR and this release is the cluster's identity provider. Consumers using the public issuer URL come through Traefik and are covered; one using the in-cluster Service address (keycloak-keycloak-service:8080) is a pod in another namespace and is blocked. The discovery URLs live in 1Password items, so I cannot check them. Verify with a real login, not withkubectl— and note that CI cannot catch this at all: no controller runs there and the probes use port 9000, so the pod goesReadyeither way.bulwark— 443 is allowed, Stalwart's in-cluster 8080 is not. Ifbulwark.jmapServerUrlpoints at the in-cluster Service, it needsegress.extraPorts: [8080]. The failure is quiet: the probes test bulwark's own port, so the pod comes upReadyand serves an empty webmail.paperless-ngx— if any release fetches mail, it needs IMAP (993, or143) inegress.extraPorts. The mail accounts are rows in its database, so no chart value shows them.keycloakagain — SMTP is not allowed. If a realm sends verification or password-reset mail, it needsegress.extraPorts: [587](or 465).Not affected
apache-tikaandgotenbergkeep working untouched: their ports are the probed ones, so the rules stay open by default and the fourpaperless-*namespaces reach them as before. An action is only needed there if someone setsprobeSources.Install-test evidence: all 28 installable charts green with their policy active
73c2ec7(the final five charts)28a0230(NodePort and game servers)96c23b7(keycloak)e1adcef(nine charts with dependencies)28 of 28 installable charts have passed at least once with the policy on, and no leg has failed on any commit of this branch. (
satisfactoryandtemplate-charthave no install-test at all —ci/excluded-charts.txt.)Five of those matter more than the rest, and all five are in
73c2ec7:freesailarr— the install-test brings up a real WireGuard tunnel, and gluetun's health server answers 200 only while the tunnel is up. Its passing is the empirical check on theUDP 51820egress rule, which is the one rule that can take the whole pod down.matrix-synapse— both policies applied and both workloads becameReady.paperless-ngx— installs alongside thevalkeysubchart's own policy.stalwartandvalkey— the two rewritten precedents, with no rule changed.And the four charts whose CI fixtures sit on a non-standard dependency port are the ones that actually exercise the egress cap's cost:
patchmon,rallly,urlaubsverwaltungandvoucher-vaultreach a CI dex on 5556 rather than 443,bulwarka JMAP server on plain 8080, andoutlinethe same dex. Each needednetworkPolicy.egress.extraPortsin its fixture — the chart's documented escape hatch, used for exactly the casevalues.yamlnames. Remove any one of those entries and the install-test shows what the cap does to a dependency on an unexpected port.The render test on the runner
Validate Helm Charts / NetworkPolicy— Successful in 13s, over all 30 charts. Locally: 30 charts, 208 assertions held, 0 failed, and all twelve failure paths produce their finding.Note that the chart manifests at
HEADare byte-identical to73c2ec7: the two commits after it changed onlyREADME.md/CLAUDE.mdandci/. So the install-test evidence above applies to the charts as they stand.HEAD's own run is still working through the queue — one runner, 28 legs per commit.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 #5Follow-up applied: the Gotenberg switch, plus three things that were load-bearing and written nowhere
Restrictive-by-default is unchanged everywhere.
minecraft-server's game port stays closed,garage3900/3902 stay closed, and the release-side list is now described as the expected procedure rather than a risk register.gotenberggets a named switch, off by default —e3f6256,b31a189networkPolicy.egress.remoteAssets: false. Not an opening and notextraPorts: [80, 443]: a value whose purpose is in its name, so the trade is a decision someone made rather than a port pair nobody can place. Additive inside the major this chart already carries — no second version step.Both halves, measured and written at the switch, in
values.yamland inNOTES.txt:.emlto Tika (PAPERLESS_TIKA_ENDPOINT), the resulting HTML here (PAPERLESS_TIKA_GOTENBERG_ENDPOINT).apache-tikastays DNS-only and is untouched.<img src="https://…">) are fetched by Chromium, here, at render time, and with the switch off they are silently dropped — the PDF is produced and is simply missing them. That invisibility is the reason the switch exists at all.One real defect found implementing it: the new
NOTES.txtbranch read.Values.networkPolicy.egress.remoteAssetsdirectly, which fails the whole render withnil pointer evaluating interface {}.remoteAssetswhen an operator erases theegressblock — the schema permitsnullthere, and #99's rule is that an erased block means the default applies, not a broken render. Null-safe now; an erased block falls back to DNS-only, the restrictive direction.Both switch positions are permanently under test, not checked once:
ci/networkpolicy/gotenberg.yamlrenders the switch's egress rule and the source-restricted probe branch, so all five assertions run over it on every PR. Worth having because assertions 2 and 3 look at ingress rules — an egress mistake has no other mechanical check. With the switch off (its default, and what the install-test uses) no rule is added at all, so assertions 2 and 3 are untouched. Verified in both positions plus theegress: nulledge case.Three things now written down
allowedNamespacespre-filled, ever. A chart namingmc-routerorstalwartin its defaults would bake in an assumption about this cluster's namespace layout — a claim a chart cannot keep true. Restrictive is the default; filling it is the deployment adaptation. This is the sentence that turns the release-side list from a risk into the procedure, and the major on each chart is what announces it.ingressControlleris the single exception, because it names a cluster component rather than a tenant.ingressControllerrule works at all. A Service is only destination NAT and the policy acts at the pod's interface, so a ClusterIP exempts nothing. What changes is the source address: pod → ClusterIP → pod preserves it (so apodSelectorcan match the Traefik pod); NodePort traffic with the defaultexternalTrafficPolicy: Clusteris masqueraded to a node, which is why those rules are left open.stalwartalready carried the second half; the first is the one everything rests on.hostNetwork. Measured — the DaemonSet has none and its pods carry real pod IPs (10.42.3.120,10.42.4.94,10.42.0.187in10.42.0.0/16, nodes on entirely different addresses). On host networking they share the node's namespace, stop being selectable as pods, theingressControllerentry matches nothing, and every web chart goes dark at once — while every policy is still accepted and still reads as correct. The symptom to recognise: all web traffic stops together and every pod staysReady, because the probe path does not run through the controller. Same class as--enable-certificate-owner-ref(#126). Recorded in README §15 and in the header oftemplate-chart's policy, so whoever changes the controller's networking meets it on the thing they are changing.Keycloak's blast radius is smaller than my report assumed
Every readable in-cluster consumer uses the public name —
bulwark'sOAUTH_ISSUER_URL,homarr'sAUTH_OIDC_ISSUER, the paperless releases through their socialaccount block — so their traffic arrives from Traefik and is permitted as shipped. A search across pod environments and ConfigMaps for the in-cluster Service name returned only Keycloak's own pods, reachingkeycloak-pg-rw.jlab-pg.svc.cluster.local:5432— which also confirms the egress rule derived fromkeycloak.db.portis right for the live release.The login test stays the acceptance criterion, since a consumer whose issuer URL lives in a secret or a realm import is not covered by that search. What changed: there is now a measured reason to expect it to pass rather than a hope. On the PR body and the
keycloakwiki page.Wiki pushed as
f775e45(fetch + rebase, no force). Local suite: 30 charts, 208 assertions, 0 failed; all twelve fail paths still fire. CI on the new HEAD to follow.CI re-proved on the new HEAD
b31a189—OVERALL: success, 95 tasks, 0 failuresRender tests, all over every chart:
NetworkPolicyResource quantitiesYAML scalarsSelector matchHTTPRoute matchBump levelAll 28 install-test legs green (
Validate Helm Charts / Install-test, Successful in 44m14s) —gotenberg1m19s with the switch change,freesailarr3m20s with a real WireGuard tunnel,keycloak2m13s,paperless-ngx2m53s,stalwart1m25s,valkey1m16s.And the commit that actually carries the switch,
e3f6256, is independently green on its own full run: 95 tasks, 28/28 install-test legs,gotenbergincluded.Local: 30 charts, 208 assertions held, 0 failed; all twelve fail paths still produce their finding. The switch verified in both positions plus the
egress: nulledge case — with it off (the default, and what the install-test installs) it adds no rule at all, so assertions 2 and 3 are untouched; with it on,ci/networkpolicy/gotenberg.yamlkeeps it and the source-restricted probe branch under all five assertions on every PR.Every commit on the branch is signed (
%G?=G), noCo-Authored-By, no "Generated with" footer. Wiki atf775e45.Nothing left from my side — the PR is green and waits on you. I have not merged and have not armed auto-merge.
Branch updated — the PR had gone
mergeable: falseunder an automerge, nowtrueagainNothing to do with the review. Renovate automerged a stalwart app patch onto
mainwhile this PR was open (1fd6c56,1.3.0+upv0.16.25to1.3.1+upv0.16.26), which collided with the major this PR gives the same chart. Approval and green checks were already in place; the conflict was the only thing in the way.Resolved as
version: 2.0.0+upv0.16.26,appVersion: "v0.16.26"— my major absorbs their patch rather than being added to it, and the+upsuffix followsappVersionas the scheme requires (verified: suffix equalsappVersionwith dashes normalised).A merge rather than a rebase, deliberately: the branch is pushed and reviewed, and force-pushing it would be destructive — so
maincame in instead. The branch now containsmainin full, with zero commits behind.And it caught a stale comment worth fixing. The block above that version line argued MINOR, from a diff for the two previous rounds — #96 spread constraint and PDB (gated on a computed replica count the chart never reaches) and #123 MTA-STS routes (whose list ships empty) — both of which rendered byte-for-byte identically against the previous version. It was then sitting directly above a
2.0.0. It 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, because the contrast is the useful part.Local re-verification after the merge: NetworkPolicy 30 charts, 208 assertions, 0 failed; selector-match, quantity, HTTPRoute and YAML-scalar all green. CI is re-running on
b617068— I will confirm it green.Still not merged and no auto-merge armed.
Post-merge verification — all four checks pass
Merged by @jklein as
ec9e641. The in-flight PR checks showing "Canceled" are the merge cancelling its own run, not a failure.Fixes #5auto-closed it, which works because the issue is in this repositorymainec9e641, everypublish-helm-chartincludedapache-tika 11.0.0,cyberchef 10.0.0,freesailarr 5.0.0,gotenberg 9.0.0,keycloak 2.0.0,matrix-synapse 8.0.0,minecraft-server 7.0.0,paperless-ngx 14.0.0,samba 8.0.0,satisfactory 8.0.0,stalwart 2.0.0,valkey 2.0.0; none missingf775e45at the tip, both commits present, 30 chart pages carrying anetworkPolicysectionThe one thing that now needs doing outside this repository
The charts are published, so the policies reach a release on its next upgrade — and
minecraft-serveris the case that needs a values line before that happens. All four releases run aClusterIPService, so the restricted branch applies and players arrive throughminecraft-routerin its own namespace:for
mc-vanilla-server,mc-oceanblock-2-server,mc-ftb-skies-2-serverandmc-sultan-saladin-server. Without it the server is unreachable and the symptom is a connection timeout in a game client with a perfectly healthy pod behind it. The rest of the release-side list, and the two items only you can check (garage/stalwart's S3 host, and a Keycloak login), are in the earlier comment — that list is the expected procedure, not a defect register.Thanks for the review. Nothing further from my side.