konairius/homelab
10
0
Fork 0
Code Issues 8 Pull Requests Packages Projects Releases 1 Wiki Activity

Infrastructure update audit #69

New Issue
Closed
opened 2026-06-27 07:45:31 +00:00 by gitea_admin · 1 comment
gitea_admin commented 2026-06-27 07:45:31 +00:00
Copy Link
Copy Source

Infrastructure update audit — 2026-07-21

Summary

Component Current Latest Behind Priority
Talos Linux v1.12.6 v1.13.7 1 minor Medium
Kubernetes (kubectl/tooling pin) v1.36.2 v1.36.2 (stable.txt) current —
Flux (installed components) v2.8.6 v2.9.2 1 minor Medium
Helm: reloader >=1.0.0 <2.0.0 (app v1.4.19) chart 2.2.14 (app still v1.4.19) cap excludes chart v2.x Low
Helm: traefik >=37.0.0,<41.0.0 41.0.2 cap excludes chart v41.x Medium
Helm: authentik exact 2026.5.3 2026.5.5 2 patches, always-manual Low
gitea/gitea 1.21.4-rootless v1.27.0 6 minors High
woodpecker-{server,agent} v3.13.0 v3.16.0 3 minors Medium
code-server (HA sidecar) 4.118.0 v4.129.0 11 minors Low-Medium
evcc/evcc 0.310.1 0.312.1 2 minors Low
syncthing/syncthing 2.0.16 v2.1.2 1 minor Low
ghcr.io/esphome/esphome 2026.6.2 2026.7.1 1 (calver month) Low
multus-cni v4.2.4-thick v4.3.0 1 minor Low
ubiquiti-community/unifi (tofu provider) 0.49.0 (pinned) v0.55.0 6 minors, deliberate Low (needs migration first)

Nothing is critically far behind. The two things worth actually scheduling work for are Gitea (6 minor releases behind the self-hosted git server everything else in this pipeline depends on) and the Flux/reloader/traefik constraint ceilings that are now blocking versions Flux would otherwise take automatically. Talos and Flux are each one minor version behind but current patches are fresh (Talos v1.13.7 was published the same day as this audit). Everything else is either already auto-tracked within its constraint or a low-risk sidecar/CLI image.

Core platform (Talos / Kubernetes / Flux)

Talos Linux — pinned in opentofu/talos_image.tf:2 (v1.12.6) and mirrored in ci/images/k8s/Containerfile:3 (TALOS_VERSION=v1.12.6, used to download talosctl). No kubernetes/talos/controlplane.yaml exists in this repo — control-plane config is generated at bootstrap time by kubernetes/bootstrap.sh via talosctl gen config (no --kubernetes-version flag) and patched with kubernetes/talos/patches/cluster.yaml, cilium-cni.yaml, registry-mirror.yaml, and per-node k8s-{1,2,3}.yaml. Latest upstream: v1.13.7, source https://api.github.com/repos/siderolabs/talos/releases/latest (published 2026-07-21, i.e. today). One minor version behind. Release notes for both v1.12.x and v1.13.x don't publish an explicit Kubernetes-compatibility table, so the two Talos releases' respective supported-k8s-version ceilings could not be confirmed from the GitHub release bodies alone — treat as "could not determine precisely — talos.dev support-matrix page returned 404 on the paths tried; confirm via talosctl support-matrix or the current docs before upgrading." Risk: routine minor upgrade, no breaking changes called out in the v1.13.0 or v1.13.7 notes.

Kubernetes — there is no explicit kubernetesVersion pin file in kubernetes/talos/; the cluster's Kubernetes version is whatever talosctl gen config defaults to at bootstrap time (implicitly tied to the talosctl binary version, i.e. Talos v1.12.6) and is upgraded independently via talosctl upgrade-k8s. The closest concrete pin is the kubectl client baked into the CI image: ci/images/k8s/Containerfile:5 (KUBECTL_VERSION=v1.36.2). Latest upstream stable: v1.36.2, source https://dl.k8s.io/release/stable.txt. These match exactly — no drift on the tooling side. Whether the cluster's actual running kubelet/apiserver version matches v1.36.2 can't be verified from the repo (no live cluster access from this audit); recommend a quick kubectl version sanity check.

Flux — installed component manifest is kubernetes/clusters/homelab/flux-system/gotk-components.yaml, header states # Flux Version: v2.8.6 (also visible in every component's app.kubernetes.io/version: v2.8.6 label). Latest upstream: v2.9.2, source https://api.github.com/repos/fluxcd/flux2/releases/latest (published 2026-07-13; patch release fixing a Kustomization.openapi.path-with-URL regression plus CRD description fixes). One minor version behind. Notably, ci/images/k8s/Containerfile:6 already pins FLUX_VERSION=2.9.2 — the CI image's flux CLI is already at latest, but the in-cluster controllers it talks to are still on v2.8.6. Re-run flux bootstrap (or flux install) against kubernetes/clusters/homelab/flux-system/ to bring the installed components up to v2.9.2 and keep the CLI/controller versions in lockstep.

Helm charts

Only charts whose constraint has an upper bound (or is an exact pin) can actually fall behind — everything with an open-ended >=X.Y.0 range is auto-upgraded by Flux on each reconcile and was not deep-dived here (external-dns, alloy, prometheus-blackbox-exporter, loki, kube-prometheus-stack, cilium, cloudnative-pg, crowdsec, k8s-gateway, metrics-server, snapshot-controller, spegel, influxdb2, velero all use unbounded ranges and are current by construction).

  • reloader (kube-system, kubernetes/infrastructure/reloader/helmrelease.yaml:31) — constraint >=1.0.0 <2.0.0. Latest chart is 2.2.14 (Artifact Hub, stakater/reloader), which exceeds the <2.0.0 ceiling. Confirmed via the upstream GitHub releases page that Reloader's application version is still v1.4.19 — the stakater chart repo bumped its own chart major-version numbering independently of the app, so this is a chart-packaging-scheme jump, not an app breaking change. Risk: low, but the constraint should be widened (e.g. >=1.0.0 <3.0.0) so Flux keeps taking chart improvements.
  • traefik (ingress, kubernetes/infrastructure/traefik/helmrelease.yaml:31) — constraint >=37.0.0,<41.0.0. Latest chart is 41.0.2 (Artifact Hub traefik/traefik), which exceeds the <41.0.0 ceiling. Per the chart's own GitHub releases, v41.0.0 introduced breaking changes to the Helm chart itself (log-configuration syntax realignment, file-provider content changed from string to object format) — Traefik Proxy itself stays on the v3.x line (v3.7.6 bundled in 41.0.2), so this is not a Traefik major bump, just a chart-values-shape change. Risk: medium — read the chart's v41.0.0 upgrade notes and adjust values: before widening the constraint (the Rook v1.19→v1.20 precedent is exactly why this shouldn't be a floating-range bump).
  • authentik (authentik, kubernetes/apps/authentik/helmrelease.yaml:23) — exact-pinned to 2026.5.3 (not a range), deliberately, per the in-file comment: it must track the authentik-samba-bridge-ldap-outpost fork's app image in lockstep. Latest chart+app version: 2026.5.5 (Artifact Hub goauthentik/authentik). Two patch versions behind. Since this is exact-pinned, Flux will never auto-take any update here regardless of size — bump is always a manual, deliberate action tied to rebuilding the samba-bridge fork. Risk: low (patch-level delta).
  • rook-ceph-operator (rook-ceph, kubernetes/infrastructure/rook-ceph/helmrelease-operator.yaml:27) — constraint ~1.20.0 (the house rule from the v1.19→v1.20 incident). Latest chart in the 1.20.x line is 1.20.2 (Artifact Hub rook/rook-ceph); no 1.21.x exists yet. Current — nothing beyond the cap.
  • openbao (openbao, kubernetes/infrastructure/openbao/helmrelease.yaml:22) — constraint >=0.28.4 <0.29.0. Latest in range is 0.28.5 (Artifact Hub openbao/openbao). Current — nothing beyond the cap.
  • external-secrets (external-secrets, kubernetes/infrastructure/external-secrets/helmrelease.yaml:23) — constraint >=2.7.0 <3.0.0. Latest in range is 2.8.0 (Artifact Hub external-secrets-operator/external-secrets). Current — no 3.x exists yet.

One cross-cutting observation, not a version gap: kubernetes/talos/cilium.yaml and kubernetes/talos/patches/cilium-cni.yaml are static, manually-pinned Cilium v1.19.2 manifests applied by Talos as bootstrap inline manifests (CNI has to exist before Flux can run). The real Cilium HelmRelease (kubernetes/infrastructure/cilium/helmrelease.yaml, >=1.19.0, uncapped) takes over and upgrades in place once Flux reconciles infrastructure (confirmed via kubernetes/RUNBOOK-cold-rebuild.md:108). That means the static manifest's pinned version only matters for the few minutes of a cold bootstrap before Flux converges it — not a live drift, but worth knowing it exists as a second, non-floating Cilium pin.

Non-automated images

  • gitea/gitea:1.21.4-rootless (kubernetes/apps/gitea/statefulset.yaml:40) — latest upstream v1.27.0 (https://api.github.com/repos/go-gitea/gitea/releases/latest, published 2026-07-13). 6 minor versions behind. No $imagepolicy marker; not enrolled in image-automation. This is the self-hosted git server Flux itself pulls from — highest-impact item in this audit. Gitea's own docs recommend sequential/staged upgrades across large minor gaps; read the intervening release notes (schema migrations in particular) before jumping straight to 1.27.
  • woodpeckerci/woodpecker-{server,agent}:v3.13.0 (kubernetes/apps/woodpecker/server.yaml:36, agent.yaml:36) — latest v3.16.0 (https://api.github.com/repos/woodpecker-ci/woodpecker/releases/latest). 3 minors behind.
  • codercom/code-server:4.118.0 (sidecar in kubernetes/apps/home-assistant/deployment.yaml:139) — latest v4.129.0 (https://api.github.com/repos/coder/code-server/releases/latest). 11 minors behind, but it's a dev-shell sidecar for HA config editing, not a production dependency — lower operational risk despite the large gap.
  • evcc/evcc:0.310.1 (kubernetes/apps/evcc/deployment.yaml:26) — latest 0.312.1 (https://api.github.com/repos/evcc-io/evcc/releases/latest). 2 minors behind.
  • syncthing/syncthing:2.0.16 (kubernetes/apps/paperless/syncthing.yaml:53) — latest v2.1.2 (https://api.github.com/repos/syncthing/syncthing/releases/latest). 1 minor behind.
  • ghcr.io/esphome/esphome:2026.6.2 (kubernetes/apps/home-assistant/esphome-deployment.yaml:39) — latest 2026.7.1 (https://api.github.com/repos/esphome/esphome/releases/latest, calver). 1 month behind.
  • ghcr.io/k8snetworkplumbingwg/multus-cni:v4.2.4-thick (kubernetes/infrastructure/multus/multus-daemonset.yaml:167,225) — latest v4.3.0 (https://api.github.com/repos/k8snetworkplumbingwg/multus-cni/releases/latest). Verify the -thick variant is published for v4.3.0 before bumping (couldn't confirm tag-suffix availability from the releases API alone).
  • docker.io/rmcrackan/libation:latest (kubernetes/apps/libation/cronjob.yaml:88) — not "no version stream" like the README's excluded trio; Docker Hub actually lists 152 semver-ish tags, latest 13.5.1. This one is pinned to a floating :latest tag rather than a version, which is a reproducibility gap distinct from being "behind" — recommend pinning to 13.5.1 explicitly, and it's a reasonable candidate for image-automation enrollment (13.x range) rather than staying manual.
  • openthread/otbr:latest (kubernetes/apps/otbr/deployment.yaml:69) — confirmed via Docker Hub tags API that only latest is published; matches the image-automation README's documented exclusion. No newer usable tag exists.
  • ghcr.io/konairius/ical-proxy:latest (kubernetes/apps/ical-proxy/deployment.yaml:20) — per the image-automation README's documented exclusion (only main/latest/main-<sha>). GHCR's anonymous tag-list API required auth and couldn't be independently re-queried this run; taking the README at face value rather than asserting a fresh check.
  • quay.io/openbao/openbao:2.5.5 (kubernetes/infrastructure/openbao/snapshot-cronjob.yaml:48) — a manual duplicate of the Helm-managed OpenBao server image ("same image as the server — bao CLI included", per the file's own comment). The OpenBao HelmRelease's floating range (>=0.28.4 <0.29.0) can already resolve to chart 0.28.5, whose upstream appVersion is v2.6.0 — one minor ahead of this cronjob's hardcoded 2.5.5. A comment in helmrelease.yaml:55 ("OpenBao 2.5 only supports declarative audit config") suggests the config was written against the 2.5.x behavior and may not have been revisited since. Worth checking these two pins stay in lockstep rather than assuming it from the comment alone.
  • Lower-priority sidecars pinned manually but not deep-dived given scope/effort: nginxinc/nginx-unprivileged:1.27-alpine, alpine/git:2.54.0, curlimages/curl:8.10.1 (used in several apps), alpine/socat:1.8.0.3, docker.io/alpine/kubectl:1.35.2 and alpine/k8s:1.35.2 (both roughly 1 minor behind the cluster's own kubectl v1.36.2 pin — cheap to align opportunistically), registry.k8s.io/pause:3.10 (multus installer init image).

Ansible roles & OpenTofu providers

Ansible — no ansible/requirements.yml (or any Galaxy requirements file) exists anywhere in the repo; every role under ansible/roles/ is a local, hand-written role with no external Galaxy collection/role dependency. Nothing to check here — all current by definition.

OpenTofu providers (opentofu/providers.tf, resolved versions in opentofu/.terraform.lock.hcl):

  • bpg/proxmox — constraint ~> 0.95, resolved 0.111.0. Current (auto-taken within the cap).
  • aminueza/minio — constraint ~> 3.33, resolved 3.38.1. Current (auto-taken within the cap).
  • ubiquiti-community/unifi — constraint ~> 0.49.0, resolved 0.49.0. Latest upstream is v0.55.0 (https://api.github.com/repos/ubiquiti-community/terraform-provider-unifi/releases). 6 minors behind, but this is a deliberate, documented pin (providers.tf:22-26): v0.50.0 switched the dns_record ttl argument from an integer to a Go duration string, which would break every existing plan against the current integer TTLs (300, 60) unless those are rewritten to "300s"/"60s" first. Not a "needs updating" finding so much as a known, deferred migration.

Recommended actions

  1. Bump Flux installed components to v2.9.2 by re-running flux bootstrap/flux install against kubernetes/clusters/homelab/flux-system/ — the CI image's flux CLI (ci/images/k8s/Containerfile:6) is already there, only the in-cluster controllers lag. Low risk, patch-level plus one minor.
  2. Bump Talos to v1.13.7 (opentofu/talos_image.tf:2, ci/images/k8s/Containerfile:3) — one minor version, no breaking changes surfaced in release notes, but read the v1.13.0 notes in full before rolling since a Talos upgrade touches every node.
  3. Plan a staged Gitea upgrade from 1.21.4 to v1.27.0 (kubernetes/apps/gitea/statefulset.yaml:40) — highest-impact non-automated image in this audit; read Gitea's own upgrade/migration notes across the intervening minors before jumping straight there, since it's a stateful DB-backed service Flux itself depends on.
  4. Widen the reloader constraint past <2.0.0 (kubernetes/infrastructure/reloader/helmrelease.yaml:31) — confirmed low-risk (chart-numbering-only bump, app unchanged).
  5. Read traefik's v41.0.0 chart upgrade notes (log-config syntax, file-provider format) before widening kubernetes/infrastructure/traefik/helmrelease.yaml:31 past <41.0.0 — medium risk, needs a values review first.
  6. Bump authentik to 2026.5.5 in lockstep with a samba-bridge fork rebuild (kubernetes/apps/authentik/helmrelease.yaml:23, kubernetes/apps/authentik/blueprints-configmap.yaml:1171) — low risk, small patch delta, but always a manual step by design.
  7. Pin libation to an explicit version tag (13.5.1) instead of floating :latest (kubernetes/apps/libation/cronjob.yaml:88), and consider enrolling it in image-automation (13.x range) — a reproducibility fix, not urgent.
  8. Verify the OpenBao snapshot-cronjob image (kubernetes/infrastructure/openbao/snapshot-cronjob.yaml:48, pinned 2.5.5) is still the same version the HelmRelease-managed server is actually running before assuming they're in lockstep.
  9. Lower priority, batch when convenient: woodpecker (3 minors), evcc (2 minors), syncthing (1 minor), esphome (1 calver month), multus-cni (1 minor, confirm -thick tag exists at v4.3.0), code-server sidecar (11 minors, low risk given it's a dev-shell container).
  10. The ubiquiti-community/unifi provider pin (0.49.0 vs upstream 0.55.0) is a known, deliberate deferral — no action unless someone is ready to migrate the DNS record TTL values from integers to duration strings first.
# Infrastructure update audit — 2026-07-21 ## Summary | Component | Current | Latest | Behind | Priority | |-----------|---------|--------|--------|----------| | Talos Linux | v1.12.6 | v1.13.7 | 1 minor | Medium | | Kubernetes (kubectl/tooling pin) | v1.36.2 | v1.36.2 (`stable.txt`) | current | — | | Flux (installed components) | v2.8.6 | v2.9.2 | 1 minor | Medium | | Helm: reloader | `>=1.0.0 <2.0.0` (app v1.4.19) | chart 2.2.14 (app still v1.4.19) | cap excludes chart v2.x | Low | | Helm: traefik | `>=37.0.0,<41.0.0` | 41.0.2 | cap excludes chart v41.x | Medium | | Helm: authentik | exact `2026.5.3` | 2026.5.5 | 2 patches, always-manual | Low | | gitea/gitea | 1.21.4-rootless | v1.27.0 | 6 minors | High | | woodpecker-{server,agent} | v3.13.0 | v3.16.0 | 3 minors | Medium | | code-server (HA sidecar) | 4.118.0 | v4.129.0 | 11 minors | Low-Medium | | evcc/evcc | 0.310.1 | 0.312.1 | 2 minors | Low | | syncthing/syncthing | 2.0.16 | v2.1.2 | 1 minor | Low | | ghcr.io/esphome/esphome | 2026.6.2 | 2026.7.1 | 1 (calver month) | Low | | multus-cni | v4.2.4-thick | v4.3.0 | 1 minor | Low | | ubiquiti-community/unifi (tofu provider) | 0.49.0 (pinned) | v0.55.0 | 6 minors, deliberate | Low (needs migration first) | Nothing is critically far behind. The two things worth actually scheduling work for are **Gitea** (6 minor releases behind the self-hosted git server everything else in this pipeline depends on) and the **Flux/reloader/traefik constraint ceilings** that are now blocking versions Flux would otherwise take automatically. Talos and Flux are each one minor version behind but current patches are fresh (Talos v1.13.7 was published the same day as this audit). Everything else is either already auto-tracked within its constraint or a low-risk sidecar/CLI image. ## Core platform (Talos / Kubernetes / Flux) **Talos Linux** — pinned in `opentofu/talos_image.tf:2` (`v1.12.6`) and mirrored in `ci/images/k8s/Containerfile:3` (`TALOS_VERSION=v1.12.6`, used to download `talosctl`). No `kubernetes/talos/controlplane.yaml` exists in this repo — control-plane config is generated at bootstrap time by `kubernetes/bootstrap.sh` via `talosctl gen config` (no `--kubernetes-version` flag) and patched with `kubernetes/talos/patches/cluster.yaml`, `cilium-cni.yaml`, `registry-mirror.yaml`, and per-node `k8s-{1,2,3}.yaml`. Latest upstream: **v1.13.7**, source `https://api.github.com/repos/siderolabs/talos/releases/latest` (published 2026-07-21, i.e. today). One minor version behind. Release notes for both v1.12.x and v1.13.x don't publish an explicit Kubernetes-compatibility table, so the two Talos releases' respective supported-k8s-version ceilings could not be confirmed from the GitHub release bodies alone — treat as "could not determine precisely — talos.dev support-matrix page returned 404 on the paths tried; confirm via `talosctl support-matrix` or the current docs before upgrading." Risk: routine minor upgrade, no breaking changes called out in the v1.13.0 or v1.13.7 notes. **Kubernetes** — there is no explicit `kubernetesVersion` pin file in `kubernetes/talos/`; the cluster's Kubernetes version is whatever `talosctl gen config` defaults to at bootstrap time (implicitly tied to the `talosctl` binary version, i.e. Talos v1.12.6) and is upgraded independently via `talosctl upgrade-k8s`. The closest concrete pin is the `kubectl` client baked into the CI image: `ci/images/k8s/Containerfile:5` (`KUBECTL_VERSION=v1.36.2`). Latest upstream stable: **v1.36.2**, source `https://dl.k8s.io/release/stable.txt`. These match exactly — no drift on the tooling side. Whether the *cluster's* actual running kubelet/apiserver version matches v1.36.2 can't be verified from the repo (no live cluster access from this audit); recommend a quick `kubectl version` sanity check. **Flux** — installed component manifest is `kubernetes/clusters/homelab/flux-system/gotk-components.yaml`, header states `# Flux Version: v2.8.6` (also visible in every component's `app.kubernetes.io/version: v2.8.6` label). Latest upstream: **v2.9.2**, source `https://api.github.com/repos/fluxcd/flux2/releases/latest` (published 2026-07-13; patch release fixing a `Kustomization.openapi.path`-with-URL regression plus CRD description fixes). One minor version behind. Notably, `ci/images/k8s/Containerfile:6` already pins `FLUX_VERSION=2.9.2` — the CI image's `flux` CLI is already at latest, but the in-cluster controllers it talks to are still on v2.8.6. Re-run `flux bootstrap` (or `flux install`) against `kubernetes/clusters/homelab/flux-system/` to bring the installed components up to v2.9.2 and keep the CLI/controller versions in lockstep. ## Helm charts Only charts whose constraint has an upper bound (or is an exact pin) can actually fall behind — everything with an open-ended `>=X.Y.0` range is auto-upgraded by Flux on each reconcile and was not deep-dived here (external-dns, alloy, prometheus-blackbox-exporter, loki, kube-prometheus-stack, cilium, cloudnative-pg, crowdsec, k8s-gateway, metrics-server, snapshot-controller, spegel, influxdb2, velero all use unbounded ranges and are current by construction). - **reloader** (`kube-system`, `kubernetes/infrastructure/reloader/helmrelease.yaml:31`) — constraint `>=1.0.0 <2.0.0`. Latest chart is `2.2.14` (Artifact Hub, `stakater/reloader`), which exceeds the `<2.0.0` ceiling. Confirmed via the upstream GitHub releases page that Reloader's **application** version is still v1.4.19 — the stakater chart repo bumped its own chart major-version numbering independently of the app, so this is a chart-packaging-scheme jump, not an app breaking change. Risk: **low**, but the constraint should be widened (e.g. `>=1.0.0 <3.0.0`) so Flux keeps taking chart improvements. - **traefik** (`ingress`, `kubernetes/infrastructure/traefik/helmrelease.yaml:31`) — constraint `>=37.0.0,<41.0.0`. Latest chart is `41.0.2` (Artifact Hub `traefik/traefik`), which exceeds the `<41.0.0` ceiling. Per the chart's own GitHub releases, v41.0.0 introduced **breaking changes to the Helm chart itself** (log-configuration syntax realignment, file-provider content changed from string to object format) — Traefik Proxy itself stays on the v3.x line (v3.7.6 bundled in 41.0.2), so this is not a Traefik major bump, just a chart-values-shape change. Risk: **medium** — read the chart's v41.0.0 upgrade notes and adjust `values:` before widening the constraint (the Rook v1.19→v1.20 precedent is exactly why this shouldn't be a floating-range bump). - **authentik** (`authentik`, `kubernetes/apps/authentik/helmrelease.yaml:23`) — exact-pinned to `2026.5.3` (not a range), deliberately, per the in-file comment: it must track the `authentik-samba-bridge-ldap-outpost` fork's app image in lockstep. Latest chart+app version: `2026.5.5` (Artifact Hub `goauthentik/authentik`). Two patch versions behind. Since this is exact-pinned, Flux will never auto-take *any* update here regardless of size — bump is always a manual, deliberate action tied to rebuilding the samba-bridge fork. Risk: **low** (patch-level delta). - **rook-ceph-operator** (`rook-ceph`, `kubernetes/infrastructure/rook-ceph/helmrelease-operator.yaml:27`) — constraint `~1.20.0` (the house rule from the v1.19→v1.20 incident). Latest chart in the 1.20.x line is `1.20.2` (Artifact Hub `rook/rook-ceph`); no `1.21.x` exists yet. Current — nothing beyond the cap. - **openbao** (`openbao`, `kubernetes/infrastructure/openbao/helmrelease.yaml:22`) — constraint `>=0.28.4 <0.29.0`. Latest in range is `0.28.5` (Artifact Hub `openbao/openbao`). Current — nothing beyond the cap. - **external-secrets** (`external-secrets`, `kubernetes/infrastructure/external-secrets/helmrelease.yaml:23`) — constraint `>=2.7.0 <3.0.0`. Latest in range is `2.8.0` (Artifact Hub `external-secrets-operator/external-secrets`). Current — no 3.x exists yet. One cross-cutting observation, not a version gap: `kubernetes/talos/cilium.yaml` and `kubernetes/talos/patches/cilium-cni.yaml` are static, manually-pinned Cilium v1.19.2 manifests applied by Talos as bootstrap inline manifests (CNI has to exist before Flux can run). The real Cilium HelmRelease (`kubernetes/infrastructure/cilium/helmrelease.yaml`, `>=1.19.0`, uncapped) takes over and upgrades in place once Flux reconciles `infrastructure` (confirmed via `kubernetes/RUNBOOK-cold-rebuild.md:108`). That means the static manifest's pinned version only matters for the few minutes of a cold bootstrap before Flux converges it — not a live drift, but worth knowing it exists as a second, non-floating Cilium pin. ## Non-automated images - **gitea/gitea:1.21.4-rootless** (`kubernetes/apps/gitea/statefulset.yaml:40`) — latest upstream `v1.27.0` (`https://api.github.com/repos/go-gitea/gitea/releases/latest`, published 2026-07-13). **6 minor versions behind.** No `$imagepolicy` marker; not enrolled in image-automation. This is the self-hosted git server Flux itself pulls from — highest-impact item in this audit. Gitea's own docs recommend sequential/staged upgrades across large minor gaps; read the intervening release notes (schema migrations in particular) before jumping straight to 1.27. - **woodpeckerci/woodpecker-{server,agent}:v3.13.0** (`kubernetes/apps/woodpecker/server.yaml:36`, `agent.yaml:36`) — latest `v3.16.0` (`https://api.github.com/repos/woodpecker-ci/woodpecker/releases/latest`). 3 minors behind. - **codercom/code-server:4.118.0** (sidecar in `kubernetes/apps/home-assistant/deployment.yaml:139`) — latest `v4.129.0` (`https://api.github.com/repos/coder/code-server/releases/latest`). 11 minors behind, but it's a dev-shell sidecar for HA config editing, not a production dependency — lower operational risk despite the large gap. - **evcc/evcc:0.310.1** (`kubernetes/apps/evcc/deployment.yaml:26`) — latest `0.312.1` (`https://api.github.com/repos/evcc-io/evcc/releases/latest`). 2 minors behind. - **syncthing/syncthing:2.0.16** (`kubernetes/apps/paperless/syncthing.yaml:53`) — latest `v2.1.2` (`https://api.github.com/repos/syncthing/syncthing/releases/latest`). 1 minor behind. - **ghcr.io/esphome/esphome:2026.6.2** (`kubernetes/apps/home-assistant/esphome-deployment.yaml:39`) — latest `2026.7.1` (`https://api.github.com/repos/esphome/esphome/releases/latest`, calver). 1 month behind. - **ghcr.io/k8snetworkplumbingwg/multus-cni:v4.2.4-thick** (`kubernetes/infrastructure/multus/multus-daemonset.yaml:167,225`) — latest `v4.3.0` (`https://api.github.com/repos/k8snetworkplumbingwg/multus-cni/releases/latest`). Verify the `-thick` variant is published for v4.3.0 before bumping (couldn't confirm tag-suffix availability from the releases API alone). - **docker.io/rmcrackan/libation:latest** (`kubernetes/apps/libation/cronjob.yaml:88`) — not "no version stream" like the README's excluded trio; Docker Hub actually lists 152 semver-ish tags, latest `13.5.1`. **This one is pinned to a floating `:latest` tag rather than a version**, which is a reproducibility gap distinct from being "behind" — recommend pinning to `13.5.1` explicitly, and it's a reasonable candidate for image-automation enrollment (`13.x` range) rather than staying manual. - **openthread/otbr:latest** (`kubernetes/apps/otbr/deployment.yaml:69`) — confirmed via Docker Hub tags API that only `latest` is published; matches the image-automation README's documented exclusion. No newer usable tag exists. - **ghcr.io/konairius/ical-proxy:latest** (`kubernetes/apps/ical-proxy/deployment.yaml:20`) — per the image-automation README's documented exclusion (only `main`/`latest`/`main-<sha>`). GHCR's anonymous tag-list API required auth and couldn't be independently re-queried this run; taking the README at face value rather than asserting a fresh check. - **quay.io/openbao/openbao:2.5.5** (`kubernetes/infrastructure/openbao/snapshot-cronjob.yaml:48`) — a manual duplicate of the Helm-managed OpenBao server image ("same image as the server — bao CLI included", per the file's own comment). The OpenBao HelmRelease's floating range (`>=0.28.4 <0.29.0`) can already resolve to chart `0.28.5`, whose upstream appVersion is `v2.6.0` — one minor ahead of this cronjob's hardcoded `2.5.5`. A comment in `helmrelease.yaml:55` ("OpenBao 2.5 only supports declarative audit config") suggests the config was written against the 2.5.x behavior and may not have been revisited since. Worth checking these two pins stay in lockstep rather than assuming it from the comment alone. - Lower-priority sidecars pinned manually but not deep-dived given scope/effort: `nginxinc/nginx-unprivileged:1.27-alpine`, `alpine/git:2.54.0`, `curlimages/curl:8.10.1` (used in several apps), `alpine/socat:1.8.0.3`, `docker.io/alpine/kubectl:1.35.2` and `alpine/k8s:1.35.2` (both roughly 1 minor behind the cluster's own `kubectl` v1.36.2 pin — cheap to align opportunistically), `registry.k8s.io/pause:3.10` (multus installer init image). ## Ansible roles & OpenTofu providers **Ansible** — no `ansible/requirements.yml` (or any Galaxy requirements file) exists anywhere in the repo; every role under `ansible/roles/` is a local, hand-written role with no external Galaxy collection/role dependency. Nothing to check here — all current by definition. **OpenTofu providers** (`opentofu/providers.tf`, resolved versions in `opentofu/.terraform.lock.hcl`): - `bpg/proxmox` — constraint `~> 0.95`, resolved `0.111.0`. Current (auto-taken within the cap). - `aminueza/minio` — constraint `~> 3.33`, resolved `3.38.1`. Current (auto-taken within the cap). - `ubiquiti-community/unifi` — constraint `~> 0.49.0`, resolved `0.49.0`. Latest upstream is **v0.55.0** (`https://api.github.com/repos/ubiquiti-community/terraform-provider-unifi/releases`). 6 minors behind, but this is a deliberate, documented pin (`providers.tf:22-26`): v0.50.0 switched the `dns_record` `ttl` argument from an integer to a Go duration string, which would break every existing plan against the current integer TTLs (`300`, `60`) unless those are rewritten to `"300s"`/`"60s"` first. Not a "needs updating" finding so much as a known, deferred migration. ## Recommended actions 1. **Bump Flux installed components to v2.9.2** by re-running `flux bootstrap`/`flux install` against `kubernetes/clusters/homelab/flux-system/` — the CI image's `flux` CLI (`ci/images/k8s/Containerfile:6`) is already there, only the in-cluster controllers lag. Low risk, patch-level plus one minor. 2. **Bump Talos to v1.13.7** (`opentofu/talos_image.tf:2`, `ci/images/k8s/Containerfile:3`) — one minor version, no breaking changes surfaced in release notes, but read the v1.13.0 notes in full before rolling since a Talos upgrade touches every node. 3. **Plan a staged Gitea upgrade** from 1.21.4 to v1.27.0 (`kubernetes/apps/gitea/statefulset.yaml:40`) — highest-impact non-automated image in this audit; read Gitea's own upgrade/migration notes across the intervening minors before jumping straight there, since it's a stateful DB-backed service Flux itself depends on. 4. **Widen the `reloader` constraint** past `<2.0.0` (`kubernetes/infrastructure/reloader/helmrelease.yaml:31`) — confirmed low-risk (chart-numbering-only bump, app unchanged). 5. **Read traefik's v41.0.0 chart upgrade notes** (log-config syntax, file-provider format) before widening `kubernetes/infrastructure/traefik/helmrelease.yaml:31` past `<41.0.0` — medium risk, needs a values review first. 6. **Bump authentik to 2026.5.5** in lockstep with a samba-bridge fork rebuild (`kubernetes/apps/authentik/helmrelease.yaml:23`, `kubernetes/apps/authentik/blueprints-configmap.yaml:1171`) — low risk, small patch delta, but always a manual step by design. 7. **Pin `libation` to an explicit version tag** (`13.5.1`) instead of floating `:latest` (`kubernetes/apps/libation/cronjob.yaml:88`), and consider enrolling it in image-automation (`13.x` range) — a reproducibility fix, not urgent. 8. **Verify the OpenBao snapshot-cronjob image** (`kubernetes/infrastructure/openbao/snapshot-cronjob.yaml:48`, pinned `2.5.5`) is still the same version the HelmRelease-managed server is actually running before assuming they're in lockstep. 9. Lower priority, batch when convenient: woodpecker (3 minors), evcc (2 minors), syncthing (1 minor), esphome (1 calver month), multus-cni (1 minor, confirm `-thick` tag exists at v4.3.0), code-server sidecar (11 minors, low risk given it's a dev-shell container). 10. The `ubiquiti-community/unifi` provider pin (0.49.0 vs upstream 0.55.0) is a known, deliberate deferral — no action unless someone is ready to migrate the DNS record TTL values from integers to duration strings first.
k.renner self-assigned this 2026-07-21 07:19:16 +00:00
update-audit-bot commented 2026-07-21 15:36:56 +00:00
Member
Copy Link
Copy Source

🔄 Re-ran 2026-07-21T15:36:56Z — report above refreshed.

🔄 Re-ran 2026-07-21T15:36:56Z — report above refreshed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
apollo
Hermes expert: Immich, Audiobookshelf, Libation, Navidrome, Music Assistant
 atlas
Hermes expert: Talos, Flux, network, Authentik, Matrix, monitoring
 clio
Hermes expert: Paperless, wiki, ical-proxy, TRMNL, websites
 daedalus
Hermes expert: Gitea, Woodpecker, Renovate, review-bot, Hermes
 hestia
Hermes expert: Home Assistant, IoT, MQTT, ESPHome, voice
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
alert-monitor-bot claude-bot (Claude Bot) flux hermes-bot issue-fix-bot k.renner renovate-bot review-bot (Review Bot) security-bot update-audit-bot
No Assignees k.renner
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: konairius/homelab#69