3 Commits

Include renames

Author	SHA1	Message	Date
jklein	e1adcef71f	feat!: NetworkPolicy in nine more charts, on by default ... bulwark, calibre-web-automated, patchmon, rallly, urlaubsverwaltung, voucher-vault, zipline, sure, homeassistant. One major each. These are the charts with real outbound dependencies, and they all share one limitation that is now written into every one of them: THE EGRESS PORTS ARE THE STANDARD ONES, NOT THE CONFIGURED ONES. Databases, caches and OIDC issuers arrive as connection URLs or as fields inside 1Password items that the charts never parse, so a chart cannot know where its dependency listens and cannot validate a guess. A dependency somewhere else is blocked, and networkPolicy.egress.extraPorts is the escape hatch. That is the upgrade risk of this rollout, stated per chart instead of discovered per release. Four of them differ in ways that mattered: HOMEASSISTANT gets policyTypes: [Ingress] and NO egress section at all, and that is the decision in the file rather than an omission. Its outbound traffic is the union of every integration an operator enables - mDNS and SSDP discovery, MQTT, a Zigbee or Z-Wave bridge on whatever port its firmware chose, ESPHome, printers, speakers, inverters, cloud APIs, NTP - which no chart can know. A cap would protect little, since the devices sit on the node's own LAN, and would break integrations one at a time, months apart, each looking like a flaky device rather than like a policy. So valkey's rule applies in the other direction: policyTypes names only what there is something to restrict. URLAUBSVERWALTUNG allows BOTH 5432 and 3306, deliberately. It is handed a full JDBC URL inside a 1Password item and never parses it, so it cannot tell PostgreSQL from MariaDB - and this cluster runs both. Allowing one would break half the possible deployments on upgrade, with the symptom buried in a Java stack trace. A small widening against a large and silent failure. RALLLY derives its SMTP rule from rallly.smtp.enabled rather than always rendering it: with mail switched off there is nothing to permit, and a rule that permits nothing makes the object look stricter than it is. BULWARK is the chart where the cap can fail most quietly. Its probes test its own port and say nothing about the JMAP server, so a jmapServerUrl on a port the policy does not allow yields a Ready pod serving an empty webmail. 443 is allowed, Stalwart's in-cluster 8080 is not, and both halves of that are in values.yaml and NOTES.txt. PATCHMON and HOMEASSISTANT select their pods by the BARE release-and-chart label, with no -deployment or -sfs suffix. Copying a selector from a neighbouring chart would have matched nothing and left a policy that filters nothing - which is precisely the first assertion of the render test. Five CI fixtures gain networkPolicy.egress.extraPorts, and they are the only place in the repository where the cap's cost is actually exercised: the CI dex runs on 5556 rather than 443 (patchmon, rallly, urlaubsverwaltung, voucher-vault) and the CI JMAP server on plain 8080 (bulwark). Part of #5	2026-10-14 14:26:25 +00:00
jklein	b10800da2a	feat(homeassistant): Gateway-API as an alternative to the Ingress ... Group 3 of the #114 sweep, and the one chart where the convention had to bend rather than the chart. homeassistant is the DOCUMENTED INGRESS EXCEPTION (README): upstream's flexible values, a list of hosts each with its own list of paths, instead of the repo's required domain/clusterIssuer pair. The exception stays - nothing here unifies it. NO httpRoute.hostnames KEY, which is the freesailarr shape from group 2 and for the same reason: there is no ingress.domain to fall back to, and a chart-global hostname list could not say which host entry - and therefore which set of paths - it belonged to. So httpRoute carries only enabled and parentRefs, the hostnames come from ingress.hosts, and the chart renders ONE HTTPRoute PER ENTRY with one rule per path of that entry. One object with several hostnames would be wrong, not merely different: an HTTPRoute's rules apply to every hostname of the object, and per-host paths are this chart's whole point. The schema rejects httpRoute.hostnames outright, so the absence is enforced rather than merely intended. ingress.hosts is therefore read in BOTH modes and is not an Ingress-only value. ingress.className, ingress.tls and ingress.annotations are not read in Gateway mode: class and certificate belong to the Gateway's listener, and there is no annotation channel. pathType IS THE SHARP EDGE, AND THE CHART'S DEFAULT IS THE AWKWARD VALUE. Ingress has Exact/Prefix/ImplementationSpecific; the Gateway API has Exact/PathPrefix/RegularExpression. Exact and Prefix map cleanly. ImplementationSpecific - the default in values.yaml - means "ask the controller" and has NO counterpart, so: - on "/" it renders as PathPrefix. Every controller treats a root ImplementationSpecific path as a prefix match, so the chart's own default works in this mode unchanged (verified: the untouched default renders a valid route). - on ANY OTHER path the render ABORTS, naming the value and asking for Prefix or Exact. In ingress-nginx - this chart's default class - an ImplementationSpecific sub-path is a REGEX, and PathPrefix is not one. Mapping it silently would change how the path matches while the render stayed green, which is exactly the class of defect #118 was. RegularExpression is deliberately not offered as an escape hatch: its support level is Implementation-specific, which decision 1 of #114 forbids. NOTHING WAS MEASURED ON THE LIVE CLUSTER FOR THIS CHART, because there is nothing to measure: homeassistant is NOT DEPLOYED in jk-cluster (checked 2026-10-12 - 23 Ingress objects cluster-wide, none this chart's, and no workload of it in any namespace). So it is the one chart of the six with no operator-supplied annotation to lose. values.yaml and NOTES.txt say that as an absence of evidence about this installation rather than as a property of the chart. Route NAMES carry the entry's INDEX, not its hostname - a hostname is not a dependable object-name fragment. Consequence named in values.yaml and in the template: reordering ingress.hosts renames routes and therefore recreates rather than edits them. Harmless, since a route holds no state and no certificate. ci/httproute/homeassistant.yaml has to SUPPLY HOSTS, which no other overlay in the sweep does, and it adds coverage the install-test never had: this chart's ingress.enabled defaults to FALSE and the fixture does not switch it on, so no routing object was exercised at all before. Two entries on purpose - a plain one, and one with two paths including an Exact - because that second entry is what proves the chart renders one object per host rather than one object with several hostnames. 5 assertions over 2 routes and 3 rules. NOTES.txt asks $published where it asked ingress.enabled, and the trusted_proxies section now warns that moving from an Ingress to a Gateway CHANGES the proxy's pod network: a list carried over unchanged turns every request into a 400 if the CIDR differs, or silently keeps attributing every client to one address if it does not. Minor: additive, defaults unchanged. Empty helm template diff against origin/main, both with the fixture as it stands and with ingress.enabled=true. Part of #114	2026-10-13 08:59:09 +00:00
jklein	2cb1a05d6f	homeassistant: strict values.schema.json and null-safe hardening ... No ingress gate change: this chart already honours ingress.enabled, and its ingress block keeps the upstream-style host/tls lists that the README documents as an exception. The schema models that shape as it is instead of pushing the repo's domain/clusterIssuer pair onto it, and the list entries stay open because they go verbatim into the Ingress spec. The domain checkpoint ran over values.yaml and templates and came back empty: ingress.domain does not exist in this chart at all. 1. values.schema.json (#68): additionalProperties: false on every chart-owned object level. Pod-spec passthrough (volumes, volumeMounts, nodeSelector, tolerations, affinity, ingress hosts/tls) stays open. 2. Null-safety for hardening, probes and resources (#99). This chart's hardening is a documented deviation and the fallbacks reproduce it exactly: the pod context is deliberately EMPTY, because the official image must start as root (s6-overlay does its setup as uid 0 and the image has no non-root user), and capabilities.add keeps NET_RAW, without which device discovery (DHCP watcher, ping/arp integrations) logs "Operation not permitted". core.storage stays deliberately not null-safe: an erased block yields an invalid PVC, which is the loud class #99 excludes. The #82 limitation around the 1Password-backed config Secret is untouched: Helm never sees the content, so it cannot be hashed, and the values.yaml note about the manual rollout restart stays as it is. Rendering with normal values is byte-identical to 5.0.0.	2026-08-23 21:44:49 +02:00