Wiki Page Revisions
4 Commits
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 jklein
|
f775e451d1
|
NetworkPolicy follow-up (Gitea #5): the gotenberg switch, and three things that were load-bearing and written nowhere
Chart-Style-Guide, gotenberg and keycloak. THE CONVENTION SENTENCE that explains the whole shape of this rollout, and was missing: no chart ships allowedNamespaces pre-filled, ever. 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; filling it is the DEPLOYMENT adaptation, made where the namespace layout is visible. So the release-side one-liners this sweep produces are the expected procedure rather than a defect list, and the major on each chart is what announces them. ingressController is the single exception, because it names a cluster component and not a tenant. THE ONE CLUSTER SETTING THIS CONVENTION DEPENDS ON AND CANNOT CHECK: Traefik must not run with hostNetwork. Measured 2026-10-14 - the rke2-traefik 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, while the nodes sit on entirely different addresses), and only because of that does a podSelector match it. On host networking those pods share the node's network namespace, stop being selectable as pods, the ingressController entry matches nothing, and every web chart in the repository goes dark at once - while every policy is still accepted and still reads as correct. The symptom to recognise is exactly that shape: all web traffic stops together and every pod stays Ready, because the probe path does not run through the controller. Same class of dependency as --enable-certificate-owner-ref in #126, and it is recorded both here 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. AND WHY THE ingressController RULE WORKS AT ALL: a policy applies to traffic that came through a Service. A Service is only destination NAT and the policy is evaluated at the POD's interface, so a ClusterIP exempts nothing. What the Service changes is the SOURCE ADDRESS - pod to ClusterIP to pod preserves it, so a podSelector can still match the Traefik pod; NodePort traffic with the default externalTrafficPolicy: Cluster is masqueraded to a node, which is why those rules cannot be restricted by source and are left open instead. stalwart's template already carried the second half; the first is the one everything rests on. gotenberg gains networkPolicy.egress.remoteAssets, off by default - the maintainer's decision, and it keeps restrictive-by-default intact: a named switch rather than an opening, so the trade is a decision someone made instead of an unplaceable [80, 443] in extraPorts. Its page now carries both measured halves: paperless-ngx sends the .eml to TIKA for parsing and the resulting HTML HERE for rendering, two separate cluster-internal endpoints - so EMBEDDED images are MIME parts inside the file and need no network from either service (which is why apache-tika stays DNS-only), while REMOTE images are fetched by Chromium at render time and are silently dropped with the switch off. The PDF is produced and is simply missing them. Named as unverified, because it was not checked: whether paperless re-embeds what 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 the policy. keycloak's page gets the measurement that makes its blast radius smaller than the page previously implied: every readable in-cluster consumer uses the PUBLIC name (bulwark's OAUTH_ISSUER_URL, homarr's AUTH_OIDC_ISSUER, the paperless releases through their socialaccount block), so their traffic arrives from Traefik and is permitted as shipped. A search for the in-cluster Service name across pod environments and ConfigMaps returned only Keycloak's own pods reaching keycloak-pg-rw.jlab-pg.svc.cluster.local:5432 - which also confirms the egress rule derived from keycloak.db.port is right for the live release. The login test stays the acceptance criterion, and the residual risk is stated rather than dismissed: 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 the test to pass. |
||
|
jklein
|
81980279c4
|
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. |
||
|
jklein
|
311293e164
|
chart pages carry no version numbers any more
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. |
||
|
jklein
|
f62f2e5871
|
Fill the wiki as the repository's knowledge base
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. |