NetworkPolicies in every chart (Gitea #5): the convention, the gate, and what it does not do
29 chart pages plus Chart-Style-Guide, CI-CD, Charts and Lessons-Learned.
Chart-Style-Guide gains section 15, and its core is the FOUR PORT CLASSES -
the part that is actually hard to get right. 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 those whose probes use a different port. A replica-to-replica bus
gets a bare podSelector - and, since policyTypes lists Egress, its outbound
side needs a rule of its own or the cluster never forms while every node looks
healthy.
The exec-probe distinction is written down as load-bearing rather than
pedantic: it is the whole reason valkey and minecraft-server are the tightest
policies in the repository and every HTTP-probed web app is looser.
CI-CD gains the networkpolicy job as section 8 (the later two renumbered), and
it ends with the measurement rather than a claim. Two experiments ran on the PR
and were reverted: cyberchef's probe port restricted to an address no probe can
come from stayed GREEN at 1m9s, and outline with its DNS egress rule removed
went RED at 5m59s. Together those say k3s exempts the kubelet's probe traffic
while enforcing everything else - so the install-test's net is an EGRESS net,
and a wrong ingress port is caught by the render assertion or not at all.
Every chart page gets a networkPolicy values table and an operating note naming
that chart's own trap, not a boilerplate one:
- keycloak carries the blast radius: it is the cluster's identity provider, its
http rule is the only source-restricted inbound rule in the repo, and nothing
in CI can catch a wrong controller - so the page asks for a real login and a
look at consumers' issuer URLs after the first upgrade.
- garage asks the reader to check their S3 consumers, because anything in
another namespace is blocked until it is in allowedNamespaces.
- bulwark names the quietest failure in the sweep: its probes test its own port,
so a jmapServerUrl on a blocked port yields a Ready pod serving an empty
webmail.
- gotenberg explains what its DNS-only cap COSTS - HTML conversion silently
loses remote assets - rather than only what it buys.
- satisfactory and homeassistant each argue their own Ingress-only policy;
satisfactory's deciding half is that it is the one chart with no install-test
at all, so an egress cap there would be the only one with no empirical check
behind it.
- paperless-ngx names the two pods of its release that the object does NOT
cover, including the consume CronJob whose pod template carries no labels.
- freesailarr explains why ten containers behind a VPN need only three egress
rules, and that extraPorts cannot help with an alternative WireGuard port
because it is TCP-only.
valkey and stalwart are corrected rather than extended. valkey's page now says
why having no probeSources is what makes it the tightest policy here and not an
incomplete one. stalwart's carries a dated correction: this page and the chart
both advised putting the ingress controller's namespace into allowedNamespaces
with ["ingress-nginx"] as the example, and both halves are wrong - ingress-nginx
is gone from the cluster entirely, and allowedNamespaces would have opened http
to every pod in that namespace anyway.
Charts drops the claim that valkey is "the first chart with a NetworkPolicy on
by default" and says instead that every chart has one, with the two shapes a
reader needs before opening any chart page.
Lessons-Learned gains four, all transferable:
- the net that existed for a different failure than the one it was built for,
and why both experiments were needed before either could be read;
- a comment that could not describe its own syntax (a template comment must not
spell out its own closing delimiter; the render then fails pointing at the
template, not at the sentence);
- three values that reached no rule and would have read as controls - a
convention about value NAMES is not a convention about which values exist;
- the subchart whose comments the parent could not fix, and the rule it
produced: before making a check a gate, ask which failures the author of this
diff can actually fix.
matrix-synapse: the Gateway API as an alternative to the Ingress (#114)
Two HTTPRoute objects, and the shape is forced rather than chosen: the Ingress
is ONE object with TWO host rules (homeserver at /, delegation nginx at
/.well-known/matrix), and an HTTPRoute's spec.hostnames applies to the whole
object, so two hostnames wanting different paths and different backends have
to be two objects. Noted on the page that #114 describes this chart as
rendering its Ingresses in a loop over several apps - that is freesailarr.
httpRoute.delegation.hostnames deliberately does not fall back to
httpRoute.hostnames: the server name is what remote homeservers resolve, and
the migration order depends on telling it apart from the homeserver's own
host.
One section is new in kind: Gateway mode is a BETTER FIT for Matrix
delegation. The server name is normally an apex domain already serving a
website, and ingress-nginx refuses a second Ingress on one hostname - which is
why the delegation rule has to sit inside this chart's single Ingress object.
HTTPRoutes on one listener and hostname are merged by the implementation,
longest match winning, so that route can sit beside whatever owns the apex.
And the loss section says which half matters. proxy-body-size 50m (plus the
nginx.org twin) is the real one, against a max_upload_size this chart cannot
see because the config comes from 1Password. The configuration-snippet is NOT:
more_set_headers is the headers-more module's OUTPUT-header directive, so
those headers go on the response and Synapse never sees them. The page says in
as many words not to re-create it at the Gateway and not to read its absence
as the cause of a rate-limiting problem - flagged as a reading of documented
semantics rather than an experiment.
Both version rows leave every chart page's at-a-glance table; the image
repository stays, because it does not rot. A plain app-version bump obliges
no wiki edit — that rule is deliberate and stays — so any number written
here is stale within a Renovate round, as urlaubsverwaltung's already was.
Chart.yaml is where the pair is read, exactly as the chart index has said
from the start.
Home and Workflow no longer promise version snapshots. Forge and tooling
described remotes named github and JLab-Git; the checkout has exactly one,
origin, pointing at Gitea. Workflow gains the rule the wiki never had:
fetch and rebase before every push, never force-push.
One page per chart - prerequisites, installation walkthrough, the required
1Password fields, the complete values reference and the chart's operating
traps - plus the long form of the workflow, the forge and its measured
differences, the pipelines, versioning, Renovate, the chart style guide, the
procedure for a new chart, local development, and the incidents each rule was
bought with.
Chart pages quote versions as snapshots; Chart.yaml stays authoritative,
because Renovate moves app versions continuously and never edits the wiki.
jklein