12 Commits

Include renames

Author	SHA1	Message	Date
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
jlab-renovate-bot	1698fc0aeb	Update itzg/mc-router Docker tag to v1.47.2	2026-10-07 14:35:14 +00:00
jklein	e0b552d93e	Replace the obsolete no-dependencies rationale in every chart helper ... The doc comments on the resources and defaultedDict helpers justified the copy-per-chart with "charts in this repo deliberately have no dependencies". That rule fell with #214: a dependency is admissible now, just expensive, and it sits in the README as guideline 14, not 13. The justification still holds, but its reason is a different one - sharing the helper would mean a library chart, a second artefact to publish, version and pull for something that changes about once a year. searxng got that wording in PR #38; this carries it to 21 further charts, 40 occurrences in all. rss-bridge is deliberately left out. Its install-test fails on the Gitea runner for a reason that predates this branch, and touching the chart would keep it in the install-test matrix and the check red. Its copy of the sentence is carried by #51, which has to open the chart anyway. Comments only: every touched chart renders byte-identical against its ci/<chart>/test-values.yaml. Each published chart takes a patch bump, appVersion and +up suffix untouched; template-chart is never published and takes none, but is corrected because every new chart inherits from it. Two repo files carried the same claim at no version cost: validate-charts.yml explained the all-charts quantity render test with it, and change-app-version.yml still counted nine images for freesailarr - MediathekArr made it ten.	2026-09-27 10:27:57 +00:00
jlab-renovate-bot	c36c5ee2c5	Update itzg/mc-router Docker tag to v1.47.1	2026-09-22 22:02:23 +00:00
jlab-renovate[bot]	9c0e1e6306	Update itzg/mc-router Docker tag to v1.46.5	2026-09-08 21:33:57 +00:00
jklein	c6583468c7	minecraft-router: NOTES.txt and exponential-notation fix (4.1.0+up1.46.4) ... Teil von #157: multiplyQuantity turned every number from the null-safe fallback helpers into a float64 via fromYaml, and Go's "%v" switches float64 to exponential notation from about 1e6 upwards. A bare byte count like 1048576 became "1.048576e+06": the integer path aborted the render on the suffix check, while the non-integer path (a fractional limitFactor) rendered the invalid quantity silently and only failed at the API server. Both string conversions now go through the canonical formatNumber helper, identical to the fix already merged for template-chart, voucher-vault and zipline. Teil von #43: adds a NOTES.txt. minecraft-router has no Ingress and no URL, so the notes name the actual way in - the NodePort Service and the fact that the routing decision is made on the hostname from the Minecraft handshake - print the effective routing table, and state the traps: the nodePort outside the default range, mappings as the only source of routes (no Kubernetes auto-discovery in this chart), the restart a routing change costs, that a Ready router says nothing about any backend, and that API writes do not survive a restart. Conditional blocks for the out-of-range nodePort, scale-to-zero, more than one replica and server.env. No production domain anywhere; examples use example.com and cluster-internal names. Minor bump, appVersion unchanged.	2026-08-29 00:32:25 +02:00
jklein	6c73ef874b	Eight charts: seccompProfile RuntimeDefault and qualified images ... Sets seccompProfile.type: RuntimeDefault in the pod security context of minecraft-router, outline, urlaubsverwaltung, zipline, voucher-vault, satisfactory, patchmon and calibre-web-automated, so the container runtime's default syscall filter applies to every container in the pod. The value lives in the pod context rather than the container context because it covers init containers and any container added later without being repeated; a container that needs a different filter can still override it under securityContext.container, which wins over the pod value. Five of the eight also get the docker.io/ prefix on their previously unqualified image references, so the pull no longer depends on the runtime's default-registry setting: itzg/mc-router, outlinewiki/outline, urlaubsverwaltung/urlaubsverwaltung, l4rm4nd/vouchervault (twice, app and init container) and guacamole/guacd:1.6.0. zipline, satisfactory and calibre-web-automated were already qualified with ghcr.io. Verified in a throwaway k3d cluster against real application work, not just a Running pod, and with Seccomp: 2 (filter mode) read from /proc/<pid>/status inside each container: - minecraft-router: a Minecraft handshake for a mapped domain travels through the router to a backend and the backend's status payload comes back to the client. - outline: all migrations apply (45 tables), OIDC discovery succeeds and the server-rendered page answers 200 with <title>Outline</title>. - urlaubsverwaltung: Liquibase applies 79 changesets (35 tables), the app seeds its settings and vacation types, /login answers 200. - zipline: 27 migrations applied, then a full round trip - first user created, login, token, upload, and the file downloaded back byte-exact from the PVC. - voucher-vault: the init container's collectstatic output is served (200, 22 KB), Django has its 22 tables and uWSGI answers 200 with <title>VoucherVault</title>. - satisfactory: application behavior is NOT proven - the image is multiple GB and pulls 10 GB+ of game files on first start, which is why the chart sits in ci/excluded-charts.txt. What is proven is that the rendered pod securityContext is accepted server-side and yields Seccomp: 2 with uid/gid 1000 on a substitute image. - patchmon: both containers run under the pod profile and both report Seccomp: 2. The server applies 47 migrations (44 tables), connects to Postgres and Redis and serves its dashboard; guacd answers a real Guacamole "select rdp" instruction with its full args list, over the same 127.0.0.1:4822 path the chart wires up. - calibre-web-automated: the readOnlyRootFilesystem: false deviation is unaffected - id abc is still uid 1000 (not the 911 the image falls back to in read-only mode), /config and the Calibre metadata.db are owned by 1000, and both the root s6 init and the uid-1000 application report Seccomp: 2. calibredb 9.1 runs and adds a book. Its IPC worker prints a traceback while doing so, but an unconfined control pod on the same image prints the same class of traceback, so it is not the filter. trivy config now reports "0 to act on" for all eight; the untouched samba still shows KSV-0104 and KSV-0030, which confirms these charts are what closed the findings. No values.schema.json needed changing: in all eight schemas securityContext.pod is type ["object", "null"] with no property restrictions, so the new key validates as it stands. The #99 null paths still hold - nulling securityContext or securityContext.pod falls back to the defaults including the new one. Renovate resolves the prefixed guacd reference: a local dry-run lookup (renovate 44.40.1, --platform=local --dry-run=lookup) reports depName docker.io/guacamole/guacd against registryUrl https://index.docker.io with lookupName guacamole/guacd, currentVersion 1.6.0 and its real release timestamp, with no warnings. The other four prefixed references live in templates, which Renovate never reads - they are tracked by the customManagers via appVersion in Chart.yaml with a depName hardcoded in renovate.json5, so they are unaffected. Major bump for all eight: runtime behavior changes. Refs #84	2026-08-24 13:17:14 +02:00
jklein	a76accf7ad	minecraft-router: strict values.schema.json and null-safe hardening ... No ingress gate: this chart has no Ingress at all (clients reach it via a NodePort), and ingress.domain appears neither in its templates nor in its values. 1. values.schema.json (#68): additionalProperties: false on every chart-owned object level, including the entries of the mappings list, where domain and internalUrl are required. 2. Null-safety for hardening, probes and resources (#99). Two things a rebuilt default probe must not lose, both verified: - the API port is addressed by NAME ("api-port"), so the probe keeps working when server.apiPort is overridden. - mc-router still has no /health endpoint in 1.46.4, so GET /routes is the health signal, and the "Accept: application/json" header belongs to that request. The pod context keeps pinning uid/gid 10000 even though the image declares USER 65532 since 1.46.0, so the runtime identity does not silently change with the base image. mappings stays deliberately not null-safe: the chart fails loudly on a missing or empty routing table, which is the loud class #99 excludes - a router without routes is not operable and has no sensible default. Rendering with normal values is byte-identical to 2.0.0.	2026-08-23 21:49:18 +02:00
jklein	e4b3c06674	Restart the router when its routing config changes (2.0.0+up1.46.4) ... The deployment now carries a checksum/config annotation over the rendered ConfigMap, so a changed routing table produces a new pod template and a controlled rollout. Without it a mapping change was inert but looked successful: the file is mounted with subPath (kubelet never refreshes those in a running container) and mc-router reads ROUTES_CONFIG only at startup. That combination caused the minecraft-server stage-3 outage - the ConfigMap pointed at the renamed services, the running router kept proxying to the old ones, and the pod stayed Ready throughout. Major bump: runtime behaviour changes. A mapping change now costs a router restart (~4.5 s in k3d, so roughly 17-19 s in the real cluster) during which clients cannot connect. That restart is what makes the change take effect at all. Refs #82.	2026-08-23 18:52:19 +02:00
jklein	a7a966de0e	Update minecraft-router to mc-router 1.46.4 ... Chart 1.0.0+up1.25.1 -> 1.0.1+up1.46.4 (patch: plain app-version update, no values-schema and no chart-side behavior change). appVersion is the image tag; itzg/mc-router publishes Docker tags without the "v" prefix that the git tags carry since 1.35.0, so "1.46.4" is correct. Verified against the upstream sources at v1.46.4 rather than the release titles alone: - --api-binding and --port are unchanged, so the chart's args still apply. - The ROUTES_CONFIG env var and the routes config schema ({"default-server": ..., "mappings": {addr: "host:port"}}) are byte-for-byte identical to 1.25.1. Confirmed in a cluster: both mappings, including a per-mapping port override, are loaded. - There is still no /health endpoint, so the probes keep using GET /routes. The "Accept: application/json" matcher that made the header mandatory in 1.25.1 was dropped in 1.32.2; the header is kept because it is harmless and correct. - The image moved from scratch to cgr.dev/chainguard/static in 1.46.0 and now declares USER 65532. The chart keeps pinning uid/gid 10000, so the runtime identity does not change. Only the values comments that the update made inaccurate are touched; no value, default or template changes. The comments now also record that every unmodelled mc-router flag is reachable through server.env, which is why the new 1.26-1.46 options need no new chart values.	2026-08-23 15:51:48 +02:00
jklein	c20ad389f2	Minecraft-router chart: naming scheme, hardening, probes, values interface ... Stage 2 of the Fleet migration for minecraft-router: bring the chart up to the repo style guidelines. Chart 0.1.1+up1.25.1 -> 1.0.0+up1.25.1 (major: resource renames, mappings becomes required, probes and security hardening change the runtime behavior; appVersion unchanged). - Resources renamed to {{ .Release.Name }}-{{ .Chart.Name }}-<kind>, templates to <chart>.<kind>.yaml; the deployment label now matches its own selector. - mappings is required and must not be empty (the old default rendered "<nil>": "<nil>:25565"); every entry needs domain and internalUrl. - Ports come from values: server.port (router listen port, also passed as --port), server.backendPort (default backend port, overridable per mapping), server.apiPort (--api-binding, used by the probes). Defaults stay 25565 / 25565 / 8080, server.outwardPort keeps its 25565 default and comment. - _helpers.tpl added (resources/limitFactor and replicas/scaleDown helpers), resources come from values, no CPU limit. - replicas value plus the chart-global scaleDown flag. - Additive env block rendered through tpl (value / secretKeyRef / configMapKeyRef). - Values-configurable securityContext.pod / .container with hardened defaults: non-root uid/gid 10000, readOnlyRootFilesystem, no privilege escalation, all capabilities dropped. - Liveness, readiness and startup probes on the mc-router API: GET /routes with an "Accept: application/json" header (the API router matches on that header and answers 404 without it). - icon added to Chart.yaml. - CI fixture supplies mappings; README chart table entry updated.	2026-08-23 15:14:49 +02:00
jklein	3be5111630	Import minecraft-router chart unchanged (Fleet migration stage 1) ... Takes the existing mc-router chart over from cluster-config as-is so the deployment can move to Fleet without any change to the rolled-out state. Convention alignment follows in stage 2, the app update in stage 3. The only deviation from "unchanged": Chart.yaml carried name: minecraft-server (copy-paste from the sister chart). The publish job pushes by the glob <directory>-*.tgz while helm package names the archive after the Chart.yaml name, so without this correction the push finds no file. Version 0.1.1+up1.25.1 - chart semver stays at 0.1.1, the +up suffix is repo policy and does not affect rendering. Also wires up CI: publish workflow, change-app-version choice list, install-test values (CI-only node-port override, since 25565 is outside the k3d default range) and the README chart table.	2026-08-23 12:58:21 +02:00