chore(ci): bump the woodpecker lint CLI to v3.17.0-alpine

From the update audit (#426), which flags this as the one item warranting
prompt action. Confirmed live: woodpecker-server runs v3.17.0 while the lint
step still pinned the v3.16.0 CLI.

That gap is the whole point of the step. The CLI compiles pipeline configs
against its own schema, so one behind the server can pass a config the server
then rejects — the gate stops predicting what the server will do, which is the
only thing it exists to do.

Verified the bump does not trade one problem for another: pulled
v3.17.0-alpine and ran the step's own lint loop over all 18 files in
.woodpecker/. Every one passes, so v3.17's schema does not reject anything
currently committed.

The drift is structural, not an oversight, and the comment now says so instead
of implying the two versions track each other. The server is a Kubernetes
manifest and image-automation bumps it; this pipeline file is plain YAML with
no apiVersion/kind, which Flux cannot patch (fluxcd/flux2#2826, recorded in
infrastructure/image-automation/README.md). So the server always moves first
and this always trails until someone bumps it by hand. Caught here by the
audit rather than by CI, which is the arrangement working as designed.

Also drops two stale "v3.16.0" references in the surrounding commentary that
would have aged into the same confusion.

Co-Authored-By: Claude Bot <claude-bot@renner.uno>

.woodpecker/alert-monitor.yml

@@ -42,7 +42,7 @@ when:
 
 steps:
   - name: fetch-alerts
-    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-05-01
+    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-08-10
     environment:
       SOPS_AGE_KEY:
         from_secret: sops_age_key

.woodpecker/ci-manifests-test.yml

@@ -60,7 +60,7 @@ steps:
   # run that never touched them. Tracked in #461.
   - name: kustomize-build
     depends_on: [] # see note above `steps:`
-    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-07-30
+    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-08-10
     commands:
       - |
         set -eu
@@ -115,7 +115,7 @@ steps:
   # An earlier revision of this comment also asserted that several deploy-*.yml
   # files emit "Additional property timeout is not allowed" warnings. That was
   # observed under the v3.9.0 CLI this step used to pin, and it is NOT known to
-  # still hold on v3.16.0 — review raised the likelihood that the warning was
+  # still hold on current CLIs — review raised the likelihood that the warning was
   # schema drift in a 7-minor-old CLI rather than real debt in those files, which
   # is one of the reasons this pin moved to latest stable. It cannot be confirmed
   # from a green run either, because the loop below sends lint output to /tmp/out
@@ -123,9 +123,15 @@ steps:
   # The claim is dropped rather than restated: what this step guarantees is the
   # exit-code contract above, which is what the gate actually rests on.
   # Latest stable, per the standing rule that any software uses the latest
-  # stable version. Matching the deployed woodpecker-server (v3.16.0) is a
-  # CONSEQUENCE of that, not a separate requirement — the server is bumped by
-  # image-automation within the 3.x range, so both land on the same release.
+  # stable version. Matching the deployed woodpecker-server is a CONSEQUENCE of
+  # that, not a separate requirement — the server is bumped by image-automation
+  # within the 3.x range, so both should land on the same release.
+  #
+  # They do not land together, though: the server is a Kubernetes manifest and
+  # is bumped automatically, this pipeline file is not and cannot be (see
+  # infrastructure/image-automation/README.md). So the server moves first and
+  # this trails until someone bumps it by hand — which is what happened at
+  # v3.16.0 -> v3.17.0, caught by the update audit (#426) rather than by CI.
   #
   # It matters here because the CLI compiles the config against its own schema:
   # one behind the server can pass a config the server then rejects, or reject
@@ -152,7 +158,7 @@ steps:
   # whenever it trails the deployed server. If you bump the server, bump here.
   - name: woodpecker-lint
     depends_on: [] # see note above `steps:`
-    image: woodpeckerci/woodpecker-cli:v3.16.0-alpine
+    image: woodpeckerci/woodpecker-cli:v3.17.0-alpine
     commands:
       - |
         set -eu
@@ -240,7 +246,7 @@ steps:
   # this step fails permanently on its own documentation.
   - name: no-digest-pins
     depends_on: [] # see note above `steps:`
-    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-07-30
+    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-08-10
     commands:
       - |
         set -eu

.woodpecker/e2e-test.yml

@@ -4,7 +4,7 @@ when:
 
 steps:
   - name: e2e
-    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-05-01
+    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-08-10
     environment:
       SOPS_AGE_KEY:
         from_secret: sops_age_key

.woodpecker/e2e.yml

@@ -30,7 +30,7 @@ steps:
       - sh scripts/ci/test-model-selection.sh
 
   - name: e2e-test
-    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-05-01
+    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-08-10
     environment:
       SOPS_AGE_KEY:
         from_secret: sops_age_key

.woodpecker/issue-fix.yml

@@ -49,7 +49,7 @@ steps:
     # (the issue-pick logic needs jq, which only the ci-claude image has);
     # minting a 1h read-only token per run is cheap. Degrades to
     # snapshot-only if the ci-diagnostics ServiceAccount isn't reconciled.
-    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-05-01
+    image: gitea.renner.uno/gitea_admin/ci-k8s:2026-08-10
     environment:
       SOPS_AGE_KEY:
         from_secret: sops_age_key

kubernetes/apps/monitoring-rules/cnpg-podmonitors.yaml

@@ -73,3 +73,29 @@ spec:
       interval: 30s
   podTargetLabels:
     - role
+---
+# wp-pg, restored into the `woodpecker` namespace (issue #433). It has never
+# been scraped: `apps` had no PodMonitor for it AND its baseline network policy
+# never allowed the monitoring namespace, so `cnpg_collector_up` has series for
+# the four clusters above but not this one. The namespace move fixes the policy
+# half; without this PodMonitor there is still no scrape target at all.
+#
+# Deliberately not adding one for the cluster still in `apps`: it is retired in
+# stage 3, and a PodMonitor there would only be reconciled to be deleted again.
+apiVersion: monitoring.coreos.com/v1
+kind: PodMonitor
+metadata:
+  name: cnpg-wp-pg
+  namespace: woodpecker
+  labels:
+    app.kubernetes.io/name: cloudnative-pg
+    release: kube-prometheus-stack
+spec:
+  selector:
+    matchLabels:
+      cnpg.io/cluster: wp-pg
+  podMetricsEndpoints:
+    - port: metrics
+      interval: 30s
+  podTargetLabels:
+    - role

kubernetes/apps/monitoring-rules/kustomization.yaml

@@ -4,6 +4,8 @@ kind: Kustomization
 # come from the kube-prometheus-stack chart. Flux applies this Kustomization
 # only after `monitoring` is Ready (chart installed → CRDs present).
 resources:
+  - prometheusrule-ceph.yaml
+  - prometheusrule-cilium.yaml
   - prometheusrule-hetzner-backup.yaml
   - prometheusrule-loki.yaml
   - prometheusrule-netbird-availability.yaml

kubernetes/apps/monitoring-rules/prometheusrule-ceph.yaml

@@ -0,0 +1,56 @@
+apiVersion: monitoring.coreos.com/v1
+kind: PrometheusRule
+metadata:
+  name: ceph
+  namespace: monitoring
+  labels:
+    # kube-prometheus-stack's Prometheus resource selects on this label;
+    # without it the rule is created but never loaded into Prometheus.
+    release: kube-prometheus-stack
+spec:
+  groups:
+    - name: ceph.rules
+      rules:
+        - alert: CephHealthWarn
+          # ceph_health_status: 0 = HEALTH_OK, 1 = HEALTH_WARN, 2 = HEALTH_ERR.
+          # 6h is deliberately long. Ceph warns for self-clearing conditions —
+          # a slow BlueStore op during the Sunday restore sweep, a mon briefly
+          # below its disk threshold — and paging on those trains people to
+          # ignore the alert. What matters is a warning that does not clear.
+          expr: ceph_health_status == 1
+          for: 6h
+          labels:
+            severity: warning
+          annotations:
+            summary: "Ceph has been HEALTH_WARN for 6h"
+            description: "The Ceph cluster has held HEALTH_WARN for six hours, so it is not a self-clearing blip. Get the detail with `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph health detail`."
+
+        - alert: CephHealthError
+          # HEALTH_ERR means data availability or redundancy is at risk.
+          expr: ceph_health_status == 2
+          for: 5m
+          labels:
+            severity: critical
+          annotations:
+            summary: "Ceph is HEALTH_ERR"
+            description: "The Ceph cluster is in HEALTH_ERR — availability or redundancy is at risk. Inspect immediately with `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph health detail` and `ceph osd df tree`."
+
+        - alert: CephMonDiskLow
+          # Named explicitly rather than left to CephHealthWarn, because the
+          # mons sit on the node's /var alongside container storage: this
+          # fires for a full node, not for Ceph growth. The mon's own data is
+          # ~106 MB, so 30% of a 60 GB shared filesystem says nothing about
+          # Ceph.
+          # Image GC does not clear this — measured on k8s-2, the reclaimable
+          # content store is a small fraction of /var/lib/containerd next to
+          # ~20 GB of overlayfs snapshots held by running containers. Look at
+          # what actually grew before reaching for a threshold.
+          expr: |
+            100 * node_filesystem_avail_bytes{mountpoint="/var"}
+              / node_filesystem_size_bytes{mountpoint="/var"} < 30
+          for: 30m
+          labels:
+            severity: warning
+          annotations:
+            summary: "{{ $labels.instance }} /var below 30% free — Ceph mon will warn"
+            description: "/var on {{ $labels.instance }} is under 30% free, which is Ceph's mon_data_avail_warn threshold, so the mon on this node will report MON_DISK_LOW. Find the actual consumer with `talosctl -n <node> usage /var/lib --depth 1` and then `/var/lib/containerd --depth 1` — note that overlayfs snapshots belong to running containers and are not reclaimable by image GC."

kubernetes/apps/monitoring-rules/prometheusrule-cilium.yaml

@@ -0,0 +1,44 @@
+apiVersion: monitoring.coreos.com/v1
+kind: PrometheusRule
+metadata:
+  name: cilium
+  namespace: monitoring
+  labels:
+    # kube-prometheus-stack's Prometheus resource selects on this label;
+    # without it the rule is created but never loaded into Prometheus.
+    release: kube-prometheus-stack
+spec:
+  groups:
+    - name: cilium.rules
+      # Both alerts are map-agnostic on purpose. cilium_bpf_map_pressure is
+      # emitted per map type — policy, conntrack, NAT, LB — distinguished by
+      # the map_name label, and running out of any of them degrades the
+      # datapath. The policy map is merely the one that has bitten us.
+      # Cilium only exports the metric for maps above
+      # policyMapPressureMetricsThreshold (chart default 0.1), so quiet maps
+      # produce no series rather than a flood of near-zero ones.
+      rules:
+        - alert: CiliumBPFMapPressureHigh
+          # cilium_bpf_map_pressure is used/capacity for the fullest map of
+          # that name on the agent. A full map is not a slow path — it is a
+          # hard failure: the agent cannot program the datapath, so endpoint
+          # regeneration fails and every new pod on the node hangs in sandbox
+          # creation until something frees space.
+          expr: cilium_bpf_map_pressure > 0.8
+          for: 15m
+          labels:
+            severity: warning
+          annotations:
+            summary: "Cilium BPF map {{ $labels.map_name }} is {{ $value | humanizePercentage }} full on {{ $labels.node }}"
+            description: "The BPF map {{ $labels.map_name }} on node {{ $labels.node }} has been over 80% full for 15 minutes. At 100% the Cilium agent can no longer program the datapath and new pods on this node fail sandbox creation. Raise the corresponding size in kubernetes/infrastructure/cilium/helmrelease.yaml (values.bpf) — the map is sized at creation, so the change needs an agent restart."
+
+        - alert: CiliumBPFMapFull
+          # Pressure reaches (and can exceed) 1.0 when the agent wants more
+          # entries than the map holds. Pods are already failing to start.
+          expr: cilium_bpf_map_pressure >= 1
+          for: 0m
+          labels:
+            severity: critical
+          annotations:
+            summary: "Cilium BPF map {{ $labels.map_name }} is full on {{ $labels.node }}"
+            description: "The BPF map {{ $labels.map_name }} on node {{ $labels.node }} is at or over capacity. Endpoint regeneration is failing with 'no space left on device' and pods scheduled to this node will hang in ContainerCreating. Check `{namespace=\"kube-system\",pod=~\"cilium-.+\"} |= \"no space left on device\"` in Loki for the affected endpoints."

kubernetes/apps/woodpecker/MIGRATION-namespace.md

@@ -0,0 +1,388 @@
+# Woodpecker: `apps` → `woodpecker` namespace migration
+
+Moves the Woodpecker service — server, agent and the `wp-pg` CNPG backend — out
+of the shared `apps` namespace into one of its own. Distinct from
+`MIGRATION.md`, which covers the earlier SQLite → CNPG move.
+
+## Why
+
+`apps` holds gitea, gatus, external-dns, ical-proxy and woodpecker together,
+and its `default-deny-ingress` uses `endpointSelector: {}`. Every allow rule it
+carries therefore applies to *every* workload in the namespace.
+
+That is not academic. Issue #433 — `wp-pg` stuck at `Ready=False` with
+`Instance Status Extraction Error` for three weeks — is caused by the CNPG
+operator in `database` being unable to reach `https://<pod-ip>:8000/pg/status`.
+The only namespace-level fix is `fromEndpoints: namespace=database`, which
+would expose gitea, gatus, external-dns and ical-proxy to the whole `database`
+namespace to solve a problem affecting one pod on one port.
+
+`cnpg_collector_up` has series for authentik, immich, monitoring and paperless
+but not for `wp-pg`, for the same reason: `apps` never allowed the monitoring
+namespace either.
+
+A namespace per service keeps each grant on the workload that needs it.
+
+**`woodpecker-ci` is not the target.** It enforces `pod-security: privileged`
+and exists solely for ephemeral pipeline step pods running repo-supplied code.
+Putting the database there would let any build step reach it through the
+intra-namespace allow.
+
+## Staging
+
+Rollback is trivial through stage 2. The `apps` cluster is untouched until
+stage 3, so reverting means pointing the DSN back and scaling up.
+
+| Stage | Contents | CI impact |
+|---|---|---|
+| **1** (this PR) | `woodpecker` namespace, its network policies, ExternalSecret, ObjectStores, and `wp-pg` restored from barman | none — parallel, nothing points at it |
+| **runbook** | verify the restore holds real data | none |
+| **2** | move server + agent, flip DSN, RBAC subject, rotator policies, docs | **downtime** |
+| **3** | delete the `apps` originals, add the prune guard to the survivor | none |
+
+## Stage 1 design notes
+
+**Two ObjectStores, deliberately.** `wp-pg-store-source` points at
+`s3://renner-uno-k8s-cnpg/wp-pg` — the prefix the live cluster archives to —
+and is read-only. `wp-pg-store` points at a **new** prefix,
+`s3://renner-uno-k8s-cnpg/wp-pg-woodpecker`, for ongoing archiving.
+
+Both clusters writing one `destinationPath` would interleave their WAL streams
+and corrupt both. Splitting them also leaves the pre-migration backup intact
+and independently restorable.
+
+**`serverName: wp-pg`** on the `externalCluster` names the cluster that
+*produced* the backup, not the one being created.
+
+**The namespace is declared in `infrastructure/namespaces/namespaces.yaml`,**
+not alongside these workloads. Its CiliumNetworkPolicies ship with the
+`infrastructure-crds` KS (`infrastructure/post-crds` includes
+`../network-policies/`), which `dependsOn` `infrastructure` — so the namespace
+exists before any policy targets it. Creating it in the `woodpecker` workload
+KS would invert that order, since that KS runs after both.
+
+**Ingress from `woodpecker-ci` is deliberately absent in stage 1.** Step pods do
+call the server back on `:8000`, but the CNPG instance manager serves its status
+API on `:8000` too, and the baseline policy uses `endpointSelector: {}`. A
+`toPorts` block narrows the port, not the destination workload — so putting that
+rule on the baseline would hand arbitrary repo-supplied build steps a route to
+wp-pg's instance manager. It lands in stage 2 as its own policy selecting the
+server pod.
+
+**No `prune: disabled` guard on the restored cluster.** The original carries one
+because it holds the only copy of the data. This one is reconstructable by
+re-running the restore, and a prune guard on a migration artifact is how orphans
+survive an abandoned migration. It gains the guard in stage 3.
+
+**Barman credentials still come from `seed/paperless/hetzner-creds`.** Issue
+#397 wants woodpecker to own `seed/woodpecker/hetzner-creds`, and this would
+have been the natural moment — but creating that path needs OpenBao write
+access that was not available (`bao kv list seed` → 403). Repointing at a path
+that may not exist would leave the restored cluster unable to archive WAL,
+which is the thing this stage exists to prove. #397 stays open; the swap is one
+line once the path exists.
+
+## Expect the `woodpecker` Kustomization to go not-Ready during the restore
+
+`kubernetes/clusters/homelab/woodpecker.yaml` sets `wait: true` and a
+`healthCheckExprs` entry matching `postgresql.cnpg.io/v1 Cluster` **with no
+name or namespace qualifier**. Flux evaluates it against every Cluster in that
+Kustomization's inventory — which, after this stage, is both the live
+`apps/wp-pg` and the restoring `woodpecker/wp-pg`.
+
+So while the restore runs, the whole `woodpecker` KS — the one that owns
+production Woodpecker — reports not-Ready, and a reconcile timeout in that
+window will trip the `flux-failures` Alert. **That is expected and is not
+Woodpecker breaking.** Nothing `dependsOn: woodpecker`, so it does not cascade.
+
+If the restore is going to sit for a long time, or the noise is unwelcome, the
+options are to suspend the KS while it completes, or to split the migration
+resources into their own `wait: false` Kustomization. For a ~660 MB database the
+window should be minutes.
+
+## Verifying stage 1
+
+Restore is asynchronous. Watch it reach a healthy state:
+
+```sh
+kubectl -n woodpecker get cluster wp-pg -w
+kubectl -n woodpecker get pods
+```
+
+Expect `Cluster in healthy state`. If it sticks in bootstrap, the recovery job's
+logs carry the reason:
+
+```sh
+kubectl -n woodpecker logs -l cnpg.io/jobRole=full-recovery --tail=100
+```
+
+**First check the generated app credentials target the right database.** CNPG
+defaults `bootstrap.recovery.database` to `app`; the restored data uses
+`woodpecker`. If this reads anything but `woodpecker`, the cluster has
+provisioned an empty `app` database and the real data is unreachable through
+the `-app` Secret and Service:
+
+```sh
+kubectl -n woodpecker get secret wp-pg-app -o jsonpath='{.data.dbname}' | base64 -d; echo
+kubectl -n woodpecker get secret wp-pg-app -o jsonpath='{.data.username}' | base64 -d; echo
+```
+
+**Then confirm the restore actually holds Woodpecker's data** — a cluster that
+comes up healthy but empty is the failure mode worth catching:
+
+```sh
+PGPASS=$(kubectl -n woodpecker get secret wp-pg-app -o jsonpath='{.data.password}' | base64 -d)
+kubectl -n woodpecker exec -it wp-pg-1 -- env PGPASSWORD="$PGPASS" \
+  psql -U woodpecker -d woodpecker -c '\dt'
+kubectl -n woodpecker exec -it wp-pg-1 -- env PGPASSWORD="$PGPASS" \
+  psql -U woodpecker -d woodpecker -c 'select count(*) from repos;'
+```
+
+Row counts should match the live cluster:
+
+```sh
+PGPASS_OLD=$(kubectl -n apps get secret wp-pg-app -o jsonpath='{.data.password}' | base64 -d)
+kubectl -n apps exec -it wp-pg-1 -- env PGPASSWORD="$PGPASS_OLD" \
+  psql -U woodpecker -d woodpecker -c 'select count(*) from repos;'
+```
+
+They will not match exactly if builds ran after the backup the restore used.
+
+**And stage 2 does not close that gap.** An earlier draft of this document
+claimed it quiesced the server first; it does not — Flux simply prunes the
+`apps` workloads and creates the `woodpecker` ones, so anything written to the
+old database between the restore and the cutover stays only in the old database.
+
+Measured on the live cutover: the restore captured through pipeline `9488`,
+four more (`9491`, `9492`, `9494`, `9496`) landed in `apps/wp-pg` before the
+swap, and the new cluster resumed at `9521`. Four pipeline records and their
+log entries exist only in the old cluster. No ID collision, no functional
+breakage — Woodpecker's own manifest calls this database "small and
+non-critical (state is largely reconstructable)" — but it is real history loss
+and should be a decision, not a surprise.
+
+If that gap matters for a future migration, quiesce before cutting over:
+
+```sh
+flux suspend kustomization woodpecker
+kubectl -n <old-ns> scale deploy/woodpecker-server deploy/woodpecker-agent --replicas=0
+# re-run the restore so it captures the final state, then resume
+```
+
+The old cluster keeps its `prune: disabled` guard until stage 3, so the missing
+rows remain recoverable until then.
+
+Confirm the two fixes this move exists for:
+
+```sh
+# #433: operator can now reach the instance
+kubectl -n woodpecker get cluster wp-pg -o jsonpath='{.status.conditions}'
+# metrics now scraped — needs BOTH the PodMonitor (cnpg-podmonitors.yaml) and
+# the monitoring ingress allow; wp-pg had neither in `apps`, which is why it is
+# absent from cnpg_collector_up while ak-pg/im-pg/gf-pg/pprl-pg are present
+kubectl get --raw '/api/v1/namespaces/monitoring/services/kube-prometheus-stack-prometheus:9090/proxy/api/v1/query?query=cnpg_collector_up{namespace="woodpecker"}'
+```
+
+Confirm the scrape target is actually registered, not just that the metric is
+missing for some other reason:
+
+```sh
+kubectl -n woodpecker get podmonitor cnpg-wp-pg
+```
+
+**Check the policy semantics by hand.** `kubectl --dry-run=server` validates
+manifest shape, not Cilium behaviour, so it cannot catch a rule that is
+syntactically fine but scoped wider than intended.
+
+`cilium-dbg policy trace` does **not** exist in Cilium 1.20 — it was removed,
+and `cilium-dbg policy` now offers only `get`, `selectors`, `subject-selectors`
+and `wait`. Read the realized BPF policy map instead, which is better evidence
+anyway: it is the datapath as programmed, not a simulation of it, and it
+carries live byte/packet counters.
+
+Find the agent on wp-pg's node and the endpoint id:
+
+```sh
+kubectl -n woodpecker get pod wp-pg-1 -o jsonpath='{.spec.nodeName}'
+kubectl -n kube-system get pod -l k8s-app=cilium \
+  --field-selector spec.nodeName=<node> --no-headers -o custom-columns=N:.metadata.name
+
+kubectl -n kube-system exec <cilium-pod> -c cilium-agent -- \
+  cilium-dbg endpoint list -o json \
+  | jq -r '.[] | select((.status.labels."security-relevant"[]?|tostring)
+      | test("cnpg.io/cluster=wp-pg")) | "\(.id) \(.status.networking.addressing[0].ipv4)"'
+```
+
+Then, on that endpoint id — who may reach `:8000`:
+
+```sh
+kubectl -n kube-system exec <cilium-pod> -c cilium-agent -- \
+  cilium-dbg bpf policy get <endpoint-id> | awk '$4 ~ /8000/ || NR<=1'
+```
+
+Expect exactly one row, the CNPG operator, with non-zero counters once it has
+polled:
+
+```
+Allow  Ingress  k8s:app.kubernetes.io/instance=cloudnative-pg  8000/TCP  11756  58
+```
+
+And confirm CI step pods reach **ICMP only** — never a TCP port:
+
+```sh
+kubectl -n kube-system exec <cilium-pod> -c cilium-agent -- \
+  cilium-dbg bpf policy get <endpoint-id> | grep woodpecker-ci | awk '{print $4}' | sort -u
+```
+
+Every line must be an ICMP/ICMPv6 type. A bare port number here means the
+namespace baseline has grown a rule it should not have.
+
+Note the operator's allow is also confirmed indirectly and more strongly by
+`Ready=True` on the Cluster: that condition only goes true once the operator has
+successfully polled this exact endpoint and port.
+
+And that archiving goes to the new prefix, leaving the old one alone:
+
+```sh
+kubectl -n woodpecker get cluster wp-pg -o jsonpath='{.status.conditions[?(@.type=="ContinuousArchiving")]}'
+```
+
+## Stage 2 — the cutover
+
+Moves server, agent, service, ingress, pdb, the agent ServiceAccount, the
+`woodpecker-secret` ExternalSecret and the rotator policy into `woodpecker`,
+points the server's DSN at `wp-pg-rw.woodpecker.svc`, repoints the agent's gRPC
+at `woodpecker.woodpecker.svc:9000`, moves the openbao rotators' egress, and
+adds the `woodpecker-ci` → server `:8000` policy that stage 1 deliberately
+deferred — scoped to the server pod, not the namespace baseline.
+
+**This is the downtime window.** Flux prunes the `apps` copies and creates the
+`woodpecker` ones; `ci.renner.uno` is down in between, and in-flight pipelines
+die with their agent.
+
+**The outage outlasts the pods becoming Ready, because of TLS.** Certificates
+are namespace-scoped, so moving the Ingress does not move `woodpecker-tls` —
+cert-manager issues a fresh one in the new namespace. Until it completes,
+Traefik serves a default certificate and clients fail before they get an HTTP
+status at all:
+
+```
+curl: (60) SSL: no alternative certificate subject name matches target hostname 'ci.renner.uno'
+```
+
+That is expected, not a routing or policy fault. Watch it clear with:
+
+```sh
+kubectl -n woodpecker get certificate woodpecker-tls -w
+```
+
+`letsencrypt-cluster` solves **DNS-01** via Cloudflare, so there is no in-cluster
+ACME solver pod and no HTTP challenge to admit through the network policies —
+worth knowing before scoping any ingress rule, since an HTTP-01 issuer would
+need the solver reachable too.
+
+The four CNPG files (`cluster.yaml`, `objectstore.yaml`, `scheduled-backup.yaml`,
+`hetzner-creds-externalsecret.yaml`) still describe the **original** apps-namespace
+cluster and are deliberately untouched — they are the rollback. Stage 3 retires
+them.
+
+### Verifying stage 2
+
+```sh
+kubectl -n woodpecker get pods
+kubectl -n apps get pods -l app.kubernetes.io/name=woodpecker   # expect none
+```
+
+The server must reach the restored database, not the old one:
+
+```sh
+kubectl -n woodpecker logs deploy/woodpecker-server --tail=40 | grep -i "database\|migrat\|error"
+kubectl -n woodpecker exec deploy/woodpecker-server -- env | grep DATASOURCE
+```
+
+Then confirm the UI and a real pipeline, which is the only check that exercises
+server → agent → step pod → server end to end:
+
+```sh
+curl -sS -o /dev/null -w '%{http_code}\n' https://ci.renner.uno/
+woodpecker pipeline create --branch master --var PIPELINE=e2e-test k.renner/homelab
+```
+
+Step pods must still reach the server on `:8000` while still being unable to
+reach wp-pg on any TCP port — re-run the `bpf policy get` checks above against
+both the server's and wp-pg's endpoint ids.
+
+Check the rotators can still reach the server, since their egress moved:
+
+```sh
+kubectl -n openbao get cronjob
+kubectl -n openbao logs -l app.kubernetes.io/component=secret-rotator --tail=20
+```
+
+### Rolling back stage 2
+
+Revert the PR. Flux recreates the `apps` workloads and the DSN points back at
+`wp-pg-rw.apps.svc`, which never stopped running. Data written to the new
+cluster during the window is lost, so roll back promptly or not at all — if
+pipelines have run against `woodpecker/wp-pg`, prefer fixing forward.
+
+## Stage 3 — retiring the old cluster
+
+Deletes the four `apps` manifests, promotes the `migration-*` set onto their
+names, and gives the surviving Cluster the `prune: disabled` data guard it was
+deliberately denied while a rollback still existed.
+
+**Merging stage 3 does not delete anything.** The old resources carry
+`kustomize.toolkit.fluxcd.io/prune: disabled`, so dropping them from git only
+stops Flux managing them — they keep running, and keep occupying their PVC.
+That is the point: the PR is reversible, the teardown is a separate, deliberate
+act.
+
+Before deleting anything, confirm the new cluster is genuinely standing on its
+own — that it has taken at least one base backup to its own prefix, so recovery
+no longer depends on the retired cluster's data:
+
+```sh
+kubectl -n woodpecker get backup.postgresql.cnpg.io
+kubectl -n woodpecker get cluster wp-pg -o jsonpath='{.status.conditions}'
+```
+
+`LastBackupSucceeded` must be `True`, not merely `BackupStarted`.
+
+Then retire the old set:
+
+```sh
+kubectl -n apps delete scheduledbackup.postgresql.cnpg.io wp-pg-daily
+kubectl -n apps delete cluster.postgresql.cnpg.io wp-pg          # deletes its PVCs
+kubectl -n apps delete objectstore.barmancloud.cnpg.io wp-pg-store
+kubectl -n apps delete externalsecret hetzner-s3-creds
+```
+
+Delete the ScheduledBackup first: leaving it while the Cluster goes away
+produces failing backup jobs against a cluster that no longer exists.
+
+**What this destroys and what it does not.** It destroys the old cluster's PVCs
+— including the four pipeline records that only ever existed there (see the
+stage-1 verification section). It does **not** touch
+`s3://renner-uno-k8s-cnpg/wp-pg`: that prefix keeps its backups until their own
+retention expires, and `wp-pg-store-source` is retained precisely so it stays
+restorable. That is the real safety net, not the running cluster.
+
+### After the teardown
+
+The `apps` namespace should have no woodpecker-related objects left:
+
+```sh
+kubectl -n apps get cluster,objectstore,scheduledbackup,externalsecret 2>/dev/null | grep -i "wp-pg\|hetzner" || echo "clean"
+```
+
+## Rolling back stage 1
+
+Delete the four resources and the namespace. Nothing references them, and the
+`apps` cluster is untouched:
+
+```sh
+kubectl delete ns woodpecker
+```
+
+Then revert this PR so Flux stops recreating them.

kubernetes/apps/woodpecker/agent.yaml

@@ -2,7 +2,7 @@ apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: woodpecker-agent
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
     app.kubernetes.io/component: agent
@@ -12,7 +12,7 @@ metadata:
     secret.reloader.stakater.com/reload: woodpecker-secret
 spec:
   # 1: the in-cluster server owns ci.renner.uno now, so this agent registers with
-  # it (woodpecker.apps.svc:9000) and runs pipelines on the kubernetes backend,
+  # it (woodpecker.woodpecker.svc:9000) and runs pipelines on the kubernetes backend,
   # replacing the retired docker agents (LXC 910/911).
   replicas: 1
   selector:
@@ -37,7 +37,7 @@ spec:
           image: woodpeckerci/woodpecker-agent:v3.17.0 # {"$imagepolicy": "flux-system:woodpecker-agent"}
           env:
             - name: WOODPECKER_SERVER
-              value: woodpecker.apps.svc.cluster.local:9000 # in-cluster gRPC, replaces LXC :9000
+              value: woodpecker.woodpecker.svc.cluster.local:9000 # in-cluster gRPC, replaces LXC :9000
             - name: WOODPECKER_MAX_WORKFLOWS
               value: "2"
             # --- kubernetes backend: pipeline steps run as native pods (retires

kubernetes/apps/woodpecker/cluster.yaml

@@ -1,19 +1,27 @@
+---
+# Woodpecker's Postgres backend. Serves the server at wp-pg-rw.woodpecker.svc.
+#
+# Originally created in `apps` with bootstrap.initdb; moved here by restoring
+# from barman into the new namespace rather than by editing a namespace field,
+# because PVCs are namespace-scoped and a Cluster cannot be relocated in place
+# (issue #433, MIGRATION-namespace.md).
+#
+# The bootstrap.recovery stanza and its externalCluster are retained rather than
+# reverted to initdb. CNPG honours `bootstrap` only when PGDATA is absent, so on
+# this live cluster it is inert — and keeping it means a cold rebuild of an
+# empty cluster restores from backup instead of coming up empty, which is the
+# gap kubernetes/RECOVERY.md exists to close for the other CNPG clusters.
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
   name: wp-pg
-  namespace: apps
+  namespace: woodpecker
   annotations:
-    # CRITICAL data-guard: prune-disabled so the seed-woodpecker -> dedicated
-    # woodpecker KS ownership handoff can never prune this Cluster (which would
-    # delete its data PVCs). Landed here first, via seed-woodpecker, so it's
-    # live before the move. Kept permanently as a standing guard.
+    # Data guard, earned at stage 3 now that this is the only copy: prevents a
+    # Flux prune from deleting the Cluster and with it the data PVCs. The
+    # migration deliberately withheld this while a rollback still existed.
     kustomize.toolkit.fluxcd.io/prune: disabled
 spec:
-  # Single instance: the Woodpecker CI DB is small and non-critical (state is
-  # largely reconstructable), so HA isn't warranted — but WAL archiving to
-  # object storage still gives point-in-time backups. Mirrors grafana-db's
-  # single-instance shape, with barman enabled like immich/paperless.
   instances: 1
   imageName: ghcr.io/cloudnative-pg/postgresql:16
   storage:
@@ -25,9 +33,25 @@ spec:
       parameters:
         barmanObjectName: wp-pg-store
   bootstrap:
-    initdb:
+    recovery:
+      source: wp-pg-apps
+      # Must mirror the initdb values of the cluster this restores from
+      # (apps/wp-pg: database woodpecker, owner woodpecker). CNPG defaults
+      # `database` to `app` and `owner` to whatever `database` is, and those
+      # names do not exist in the physically restored data — it would provision
+      # an empty `app` database, point the generated wp-pg-app Secret and the
+      # -app Service at it, and leave the real data unreachable through them.
+      # Same pattern as every recovery example in kubernetes/RECOVERY.md.
       database: woodpecker
       owner: woodpecker
+  externalClusters:
+    - name: wp-pg-apps
+      plugin:
+        name: barman-cloud.cloudnative-pg.io
+        parameters:
+          barmanObjectName: wp-pg-store-source
+          # The cluster that produced the backup, not this one.
+          serverName: wp-pg
   postgresql:
     parameters:
       shared_buffers: "128MB"

kubernetes/apps/woodpecker/externalsecret.yaml

@@ -2,7 +2,7 @@ apiVersion: external-secrets.io/v1
 kind: ExternalSecret
 metadata:
   name: woodpecker-secret
-  namespace: apps
+  namespace: woodpecker
 spec:
   # 10m (was 1h) so an automated rotation (rotate-agent-secret.yaml writes a new
   # value to OpenBao) propagates into the k8s Secret within ~10m without a manual

kubernetes/apps/woodpecker/hetzner-creds-externalsecret.yaml

@@ -1,11 +1,20 @@
+---
+# Barman S3 credentials for wp-pg.
+#
+# Sourced from seed/paperless/hetzner-creds, which is not where they belong.
+# Issue #397 wants woodpecker to own seed/woodpecker/hetzner-creds; creating
+# that path needs OpenBao write access (`bao kv list seed` → 403 for the
+# identities available here), so it stays open. The values are identical, so it
+# is a one-line swap of the `key:` below once the path exists.
+#
+# The namespace allowlist on the openbao ClusterSecretStore
+# (infrastructure/post-crds/openbao-clustersecretstore.yaml) must include this
+# namespace, or ESO silently never syncs — see #505.
 apiVersion: external-secrets.io/v1
 kind: ExternalSecret
 metadata:
   name: hetzner-s3-creds
-  namespace: apps
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->dedicated-KS handoff (barman S3 creds).
-    kustomize.toolkit.fluxcd.io/prune: disabled
+  namespace: woodpecker
 spec:
   refreshInterval: 1h
   secretStoreRef:
@@ -14,10 +23,5 @@ spec:
   target:
     name: hetzner-s3-creds
   dataFrom:
-    # Reuses the paperless copy of the shared Hetzner S3 credentials (identical
-    # ACCESS_KEY_ID / ACCESS_SECRET_KEY / REGION) to avoid seeding a new OpenBao
-    # path for this migration. FOLLOW-UP: give woodpecker its own
-    # seed/woodpecker/hetzner-creds path once OpenBao can be written, and repoint
-    # this here (the value is the same, so it's a drop-in swap).
     - extract:
         key: seed/paperless/hetzner-creds

kubernetes/apps/woodpecker/ingress.yaml

@@ -2,7 +2,7 @@ apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: woodpecker
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
   annotations:

kubernetes/apps/woodpecker/kustomization.yaml

@@ -21,11 +21,20 @@ resources:
   # (kubernetes/infrastructure/openbao/rotation/woodpecker.yaml) — intra-ns
   # OpenBao access, no NetworkPolicy needed. server.yaml/agent.yaml keep their
   # Reloader annotations; externalsecret.yaml keeps the 10m refreshInterval.
-  # wp-pg CNPG Postgres backend (moved here from the retired seed-woodpecker KS;
-  # each object carries prune: disabled so ownership transferred without a
-  # teardown). The dedicated `woodpecker` KS depends on infrastructure-cnpg-barman
-  # for the barman plugin behind the ObjectStore/ScheduledBackup.
-  - cluster.yaml
-  - objectstore.yaml
-  - scheduled-backup.yaml
+  # --- namespace migration, stages 1-2 (issue #433) ---
+  # Stage 2 has moved the workloads above (server, agent, service, ingress, pdb,
+  # rbac, secrets, policies) into the `woodpecker` namespace and pointed the
+  # server's DSN at wp-pg-rw.woodpecker.svc. Stage 3 retired the `apps`
+  # originals; these four now describe the surviving cluster. History and the
+  # reasoning behind the three stages: MIGRATION-namespace.md.
+  #
+  # The `woodpecker` Namespace itself is declared in infrastructure/namespaces,
+  # not here: it must exist before the `infrastructure-crds` KS applies the
+  # namespace's CiliumNetworkPolicies, and this KS runs after both of those.
+  #
+  # This KS depends on infrastructure-cnpg-barman for the barman plugin behind
+  # the ObjectStore and ScheduledBackup.
   - hetzner-creds-externalsecret.yaml
+  - objectstore.yaml
+  - cluster.yaml
+  - scheduled-backup.yaml

kubernetes/apps/woodpecker/networkpolicy.yaml

@@ -1,20 +1,23 @@
 # Secret rotation: the review-bot and claude-oauth rotators (openbao ns) reach
 # the Woodpecker SERVER to upsert org-level CI secrets (review_bot_token,
 # claude_code_oauth_token). They use the in-cluster Service
-# (woodpecker.apps.svc:8000) — the public ci.renner.uno name hairpins off the
-# ingress LB from a pod. The apps default-deny-ingress only allows same-ns /
-# host / a few named sources, so without this the rotator's connect to :8000 is
+# (woodpecker.woodpecker.svc:8000) — the public ci.renner.uno name hairpins off the
+# ingress LB from a pod. This namespace's baseline
+# (network-policies/woodpecker-ns.yaml) admits only same-namespace, monitoring,
+# host/remote-node and ICMP, so without this the rotator's connect to :8000 is
 # dropped. Scoped to the woodpecker SERVER pod :8000 and the two rotator labels;
 # the egress halves are rotator-review-bot-egress + rotator-claude-oauth-egress
 # in network-policies/openbao-ns.yaml.
 #
-# This is additive to the apps-ns baseline allows (allow-ingress.yaml selects all
-# apps pods), so the server's existing ingress — Traefik, agents — is unaffected.
+# Cilium unions allow rules, so this composes with the baseline and with the
+# sibling policies below (traefik, CI steps) rather than replacing them. Note
+# allow-ingress.yaml does NOT apply here — it is hard-scoped to `namespace:
+# apps`, which is why traefik needs its own rule in this file now.
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
 metadata:
   name: woodpecker-allow-rotators
-  namespace: apps
+  namespace: woodpecker
 spec:
   endpointSelector:
     matchLabels:
@@ -34,3 +37,25 @@ spec:
         - ports:
             - port: "8000"
               protocol: TCP
+---
+# Pipeline step pods call the server back on :8000 to stream logs and report
+# status. Deferred from stage 1 on purpose, and scoped to the SERVER pod rather
+# than granted on the namespace baseline.
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: woodpecker-allow-ci-steps
+  namespace: woodpecker
+spec:
+  endpointSelector:
+    matchLabels:
+      app.kubernetes.io/name: woodpecker
+      app.kubernetes.io/component: server
+  ingress:
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": woodpecker-ci
+      toPorts:
+        - ports:
+            - port: "8000"
+              protocol: TCP

kubernetes/apps/woodpecker/objectstore.yaml

@@ -1,18 +1,20 @@
 ---
+# RECOVERY SOURCE — read-only. The prefix the retired `apps/wp-pg` archived to.
+#
+# Kept after the migration on purpose. Nothing writes to it, and the backups
+# under it age out on their own retention, but while they last this is a second,
+# independent restore point that predates the move — worth having until the new
+# prefix has a meaningful backup history of its own.
+#
+# serverName on the consuming externalCluster must be `wp-pg`, the name of the
+# cluster that produced these backups.
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
-  name: wp-pg-store
-  namespace: apps
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->dedicated-KS handoff (backup target).
-    kustomize.toolkit.fluxcd.io/prune: disabled
+  name: wp-pg-store-source
+  namespace: woodpecker
 spec:
   configuration:
-    # Same offsite Hetzner Object Storage bucket as the other CNPG clusters,
-    # under a per-cluster prefix. See apps/paperless/objectstore.yaml for the
-    # SSE / addressing rationale (Hetzner is SSE-C only; transit is TLS,
-    # bucket private).
     destinationPath: s3://renner-uno-k8s-cnpg/wp-pg
     endpointURL: https://fsn1.your-objectstorage.com
     s3Credentials:
@@ -29,4 +31,36 @@ spec:
       compression: gzip
     data:
       compression: gzip
+  # No retentionPolicy: this store is a read source during the migration, and
+  # the old cluster in `apps` owns the lifecycle of the data underneath it.
+---
+# ARCHIVING TARGET — a DIFFERENT prefix from the source, deliberately.
+#
+# Two clusters archiving WAL to one destinationPath interleave their streams and
+# corrupt both. That mattered during the parallel-run window; it still matters
+# now, because the source prefix above is retained and must stay frozen for the
+# independent restore point it provides.
+apiVersion: barmancloud.cnpg.io/v1
+kind: ObjectStore
+metadata:
+  name: wp-pg-store
+  namespace: woodpecker
+spec:
+  configuration:
+    destinationPath: s3://renner-uno-k8s-cnpg/wp-pg-woodpecker
+    endpointURL: https://fsn1.your-objectstorage.com
+    s3Credentials:
+      accessKeyId:
+        name: hetzner-s3-creds
+        key: ACCESS_KEY_ID
+      secretAccessKey:
+        name: hetzner-s3-creds
+        key: ACCESS_SECRET_KEY
+      region:
+        name: hetzner-s3-creds
+        key: REGION
+    wal:
+      compression: gzip
+    data:
+      compression: gzip
   retentionPolicy: "30d"

kubernetes/apps/woodpecker/pdb.yaml

@@ -15,7 +15,7 @@ apiVersion: policy/v1
 kind: PodDisruptionBudget
 metadata:
   name: woodpecker-server
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
     app.kubernetes.io/component: server

kubernetes/apps/woodpecker/rbac.yaml

@@ -17,7 +17,7 @@ apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: woodpecker-agent
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
     app.kubernetes.io/component: agent
@@ -60,4 +60,7 @@ roleRef:
 subjects:
   - kind: ServiceAccount
     name: woodpecker-agent
-    namespace: apps
+    # The agent's SA lives in `woodpecker`; this Role/RoleBinding stays in
+    # `woodpecker-ci`, because that is the namespace it grants pod
+    # create/delete in. Cross-namespace subject, deliberately.
+    namespace: woodpecker

kubernetes/apps/woodpecker/scheduled-backup.yaml

@@ -1,18 +1,19 @@
 ---
-# Daily base backup at 02:35 UTC (offset from the other clusters' 02:30 to
-# avoid a thundering herd against the Hetzner bucket). WAL archiving runs
-# continuously (see cluster.yaml spec.plugins[].isWALArchiver). immediate:true
-# takes the first base backup as soon as this CR applies.
+# Daily base backups onto the wp-pg-woodpecker prefix. Continuous WAL archiving
+# runs separately (cluster.yaml spec.plugins[].isWALArchiver); without periodic
+# base backups the prefix would have no recovery point of its own and
+# wp-pg-store's retentionPolicy: 30d would have nothing to prune against, so the
+# WAL chain would grow without bound.
+#
+# 02:40 UTC, offset from the other CNPG clusters' 02:30 so they do not all hit
+# the Hetzner bucket together.
 apiVersion: postgresql.cnpg.io/v1
 kind: ScheduledBackup
 metadata:
   name: wp-pg-daily
-  namespace: apps
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->dedicated-KS handoff (backup schedule).
-    kustomize.toolkit.fluxcd.io/prune: disabled
+  namespace: woodpecker
 spec:
-  schedule: "0 35 2 * * *"
+  schedule: "0 40 2 * * *"
   immediate: true
   backupOwnerReference: self
   cluster:

kubernetes/apps/woodpecker/secret.example.yaml

@@ -14,7 +14,7 @@ apiVersion: v1
 kind: Secret
 metadata:
   name: woodpecker-secret
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
 type: Opaque

kubernetes/apps/woodpecker/server.yaml

@@ -2,7 +2,7 @@ apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: woodpecker-server
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
     app.kubernetes.io/component: server
@@ -84,7 +84,7 @@ spec:
             - name: WOODPECKER_DATABASE_DRIVER
               value: postgres
             - name: WOODPECKER_DATABASE_DATASOURCE
-              value: "host=wp-pg-rw.apps.svc.cluster.local port=5432 user=$(WP_DB_USER) password=$(WP_DB_PASS) dbname=woodpecker sslmode=require"
+              value: "host=wp-pg-rw.woodpecker.svc.cluster.local port=5432 user=$(WP_DB_USER) password=$(WP_DB_PASS) dbname=woodpecker sslmode=require"
           # AGENT_SECRET + GITEA_CLIENT + GITEA_SECRET come from the SOPS secret.
           envFrom:
             - secretRef:

kubernetes/apps/woodpecker/service.yaml

@@ -2,13 +2,13 @@ apiVersion: v1
 kind: Service
 metadata:
   name: woodpecker
-  namespace: apps
+  namespace: woodpecker
   labels:
     app.kubernetes.io/name: woodpecker
 spec:
   # Flipped ExternalName -> ClusterIP: ci.renner.uno (via the Ingress, by name)
   # and the in-cluster agent both target this Service now. http:8000 serves the
-  # UI/API; grpc:9000 is how the agent (woodpecker.apps.svc:9000) reaches the
+  # UI/API; grpc:9000 is how the agent (woodpecker.woodpecker.svc:9000) reaches the
   # server. Selects the server pod only (not the agent).
   type: ClusterIP
   selector:

kubernetes/apps/wordpress/ingress.yaml

@@ -57,6 +57,24 @@ spec:
     - host: www.renner.uno
       http:
         paths:
+          # The outpost's own OAuth leg. Without this the gate is a dead end,
+          # not a gate: hitting /wp-admin redirects to
+          # /outpost.goauthentik.io/start on THIS host, which otherwise falls
+          # through to the public `/` router and lands on WordPress's 404
+          # page — verified exactly that way on first deploy. paperless needs
+          # the same route and has it as a separate Ingress on auth.renner.uno
+          # (apps/authentik/paperless-gate-ingress.yaml); here the flow stays
+          # on www.renner.uno, so it belongs in this rule set.
+          #
+          # It is not an authentication hole: these endpoints ARE the login
+          # flow, and the outpost serves them itself.
+          - path: /outpost.goauthentik.io
+            pathType: Prefix
+            backend:
+              service:
+                name: ak-outpost-wordpress-gate
+                port:
+                  number: 9000
           # Covers admin-ajax.php too. That is only safe because the gift
           # registry plugin -- the sole thing on this site that ever emitted
           # an ajaxurl -- is being dropped in the migration. Verified against

kubernetes/infrastructure/cilium/helmrelease.yaml

@@ -17,7 +17,11 @@ spec:
   chart:
     spec:
       chart: cilium
-      version: ">=1.19.0"
+      # Patch-only range: Flux reconciles every 30m and would otherwise take a
+      # CNI minor or major unattended. Widening this is a deliberate, reviewed
+      # act — a minor bump changes datapath behaviour and rolls 2 of 3 agents
+      # at once.
+      version: ">=1.20.0 <1.21.0"
       sourceRef:
         kind: HelmRepository
         name: cilium
@@ -29,6 +33,16 @@ spec:
     remediation:
       retries: 3
   values:
+    # Which pod labels feed security-identity computation. Patterns are
+    # start-anchored regexes; a leading "!" excludes while keeping the default
+    # set. Woodpecker stamps every step pod with woodpecker-ci.org/task-uuid
+    # and step=<name>, so without this each build step is its own identity —
+    # and every identity costs one entry per allowed (direction, proto, port)
+    # in every endpoint's policy map, cluster-wide. Nothing selects on these
+    # labels in policy, so they buy identity churn and nothing else.
+    # Keep in lockstep with kubernetes/talos/patches/cilium-cni.yaml and
+    # kubernetes/talos/cilium.yaml.
+    labels: '!woodpecker-ci\.org/.* !step$'
     ipv6:
       enabled: true
     ipam:
@@ -46,6 +60,19 @@ spec:
       serviceMonitor:
         enabled: true
     bpf:
+      # Size of each endpoint's own cilium_policy_v3_<id> map, holding one
+      # entry per (identity, direction, protocol, port) the endpoint is
+      # allowed. When it fills, endpoint regeneration fails with "no space
+      # left on device", the CNI ADD call never returns, and the pod is stuck
+      # in sandbox creation — so this must stay comfortably above the busiest
+      # endpoint's entry count, tracked by cilium_bpf_map_pressure.
+      # Takes effect on agent restart; the map is sized at creation.
+      # Bootstrap installs Cilium from the inline manifest in
+      # kubernetes/talos/patches/cilium-cni.yaml, so bpf-policy-map-max there
+      # must move with this value or a cold rebuild starts with the old size.
+      # kubernetes/talos/cilium.yaml carries a third copy of the same key.
+      # Nothing enforces any of this; grep bpf-policy-map-max before changing it.
+      policyMapMax: 65536
       # Let pods reach the cluster's own LoadBalancer external IPs; Cilium
       # redirects the socket directly to the backend pod instead of sending
       # traffic out to the VIP and back (which fails with L2 announcements).

kubernetes/infrastructure/namespaces/namespaces.yaml

@@ -160,3 +160,26 @@ apiVersion: v1
 kind: Namespace
 metadata:
   name: wordpress
+---
+# The Woodpecker service itself — server, agent and its wp-pg Postgres backend,
+# moving out of the shared `apps` namespace (issue #433). Distinct from
+# `woodpecker-ci`, which enforces pod-security: privileged and holds only
+# ephemeral pipeline step pods.
+#
+# `apps` uses an endpointSelector:{} default-deny, so every allow it carries
+# applies to gitea, gatus, external-dns and ical-proxy alike — granting the
+# CNPG operator access to wp-pg there would have opened all of `apps` to all of
+# `database`. A namespace per service keeps that grant on the one workload.
+#
+# Declared here rather than alongside the workloads so it is created by the
+# `infrastructure` KS. The namespace's CiliumNetworkPolicies ship with the
+# `infrastructure-crds` KS (infrastructure/post-crds includes
+# ../network-policies/), which itself dependsOn `infrastructure` — so the
+# namespace exists before any policy targets it. Creating it in the `woodpecker`
+# workload KS would invert that order, since that KS runs after both.
+#
+# No pod-security labels: the cluster default applies.
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: woodpecker

kubernetes/infrastructure/network-policies/audiobookshelf-ns.yaml

@@ -31,43 +31,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     - toEndpoints:
         - matchLabels:
@@ -103,40 +80,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/authentik-ns.yaml

@@ -38,43 +38,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     - toEndpoints:
         - matchLabels:
@@ -103,40 +80,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/crowdsec-ns.yaml

@@ -36,40 +36,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/database-ns.yaml

@@ -32,40 +32,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/evcc-ns.yaml

@@ -27,43 +27,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     - toEndpoints:
         - matchLabels:
@@ -102,40 +79,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/external-secrets-ns.yaml

@@ -28,43 +28,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     - toEndpoints:
         - matchLabels:
@@ -103,40 +80,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/home-assistant-ns.yaml

@@ -157,44 +157,21 @@ spec:
       icmps:
         - fields:
             - { type: 0,   family: IPv4 }   # Echo Reply
-            - { type: 3,   family: IPv4 }   # Destination Unreachable
-            - { type: 4,   family: IPv4 }   # Source Quench
-            - { type: 5,   family: IPv4 }   # Redirect
+            - { type: 3,   family: IPv4 }   # Destination Unreachable — PMTUD
             - { type: 8,   family: IPv4 }   # Echo Request
-            - { type: 9,   family: IPv4 }   # Router Advertisement
-            - { type: 10,  family: IPv4 }   # Router Solicitation
             - { type: 11,  family: IPv4 }   # Time Exceeded
             - { type: 12,  family: IPv4 }   # Parameter Problem
-            - { type: 13,  family: IPv4 }   # Timestamp
-            - { type: 14,  family: IPv4 }   # Timestamp Reply
-            - { type: 15,  family: IPv4 }   # Information Request
-            - { type: 16,  family: IPv4 }   # Information Reply
-            - { type: 17,  family: IPv4 }   # Address Mask Request
-            - { type: 18,  family: IPv4 }   # Address Mask Reply
-            - { type: 30,  family: IPv4 }   # Traceroute
             - { type: 1,   family: IPv6 }   # Destination Unreachable
-            - { type: 2,   family: IPv6 }   # Packet Too Big
+            - { type: 2,   family: IPv6 }   # Packet Too Big — PMTUD, mandatory
             - { type: 3,   family: IPv6 }   # Time Exceeded
             - { type: 4,   family: IPv6 }   # Parameter Problem
             - { type: 128, family: IPv6 }   # Echo Request
             - { type: 129, family: IPv6 }   # Echo Reply
-            - { type: 130, family: IPv6 }   # Multicast Listener Query
-            - { type: 131, family: IPv6 }   # Multicast Listener Report
-            - { type: 132, family: IPv6 }   # Multicast Listener Done
             - { type: 133, family: IPv6 }   # Router Solicitation
             - { type: 134, family: IPv6 }   # Router Advertisement
             - { type: 135, family: IPv6 }   # Neighbor Solicitation
             - { type: 136, family: IPv6 }   # Neighbor Advertisement
-            - { type: 137, family: IPv6 }   # Redirect
-            - { type: 138, family: IPv6 }   # Router Renumbering
-            - { type: 141, family: IPv6 }   # Inverse ND Solicitation
-            - { type: 142, family: IPv6 }   # Inverse ND Advertisement
             - { type: 143, family: IPv6 }   # MLDv2 Listener Report
-            - { type: 148, family: IPv6 }   # Certification Path Solicitation
-            - { type: 149, family: IPv6 }   # Certification Path Advertisement
-            - { type: 151, family: IPv6 }   # Multicast Router Advertisement
-            - { type: 152, family: IPv6 }   # Multicast Router Solicitation
-            - { type: 153, family: IPv6 }   # Multicast Router Termination
   egress:
     # Cluster-internal callers HA initiates connections to: mosquitto,
     # whisper, matter-server, etc.
@@ -253,43 +230,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
 ---
 # Scoped world ingress — replaces the former namespace-wide `fromEntities:
 # world` allow (see the note in the default-deny-ingress policy above). IoT-VLAN

kubernetes/infrastructure/network-policies/immich-ns.yaml

@@ -42,40 +42,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/influxdb-ns.yaml

@@ -42,40 +42,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/kustomization.yaml

@@ -21,6 +21,7 @@ resources:
   - openbao-ns.yaml
   - external-secrets-ns.yaml
   - woodpecker-ci-ns.yaml
+  - woodpecker-ns.yaml
   - trmnl-ns.yaml
   - wordpress-ns.yaml
   - allow-cilium-health.yaml

kubernetes/infrastructure/network-policies/monitoring-ns.yaml

@@ -67,40 +67,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/openbao-ns.yaml

@@ -141,9 +141,9 @@ spec:
 ---
 # Egress for the review-bot rotator. Its CronJob has two steps: the init step
 # mints review-bot's PAT against gitea (apps :3000), the main step upserts the
-# Woodpecker org secret against the woodpecker server (apps :8000). Both run
+# Woodpecker org secret against the woodpecker server (woodpecker :8000). Both run
 # under the same pod labels, so one egress policy covers both hops. Complements
-# gitea-allow-review-bot-rotator + woodpecker-allow-rotators (apps side).
+# gitea-allow-review-bot-rotator (apps) + woodpecker-allow-rotators (woodpecker).
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
 metadata:
@@ -165,16 +165,16 @@ spec:
               protocol: TCP
     - toEndpoints:
         - matchLabels:
-            "k8s:io.kubernetes.pod.namespace": apps
+            "k8s:io.kubernetes.pod.namespace": woodpecker
             app.kubernetes.io/name: woodpecker
       toPorts:
         - ports:
             - port: "8000"
               protocol: TCP
 ---
-# Egress for the claude-oauth sync rotator: woodpecker server only (apps :8000).
+# Egress for the claude-oauth sync rotator: woodpecker server only (woodpecker :8000).
 # It never touches gitea (the OAuth value is seeded into OpenBao by hand, not
-# minted). Complements woodpecker-allow-rotators (apps side).
+# minted). Complements woodpecker-allow-rotators (woodpecker side).
 apiVersion: cilium.io/v2
 kind: CiliumNetworkPolicy
 metadata:
@@ -188,7 +188,7 @@ spec:
   egress:
     - toEndpoints:
         - matchLabels:
-            "k8s:io.kubernetes.pod.namespace": apps
+            "k8s:io.kubernetes.pod.namespace": woodpecker
             app.kubernetes.io/name: woodpecker
       toPorts:
         - ports:

kubernetes/infrastructure/network-policies/paperless-ns.yaml

@@ -37,43 +37,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     - toEndpoints:
         - matchLabels:
@@ -109,43 +86,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
 ---
 # Allow FTP access (from scanners on the LAN) to the ftp-scanner pod.
 apiVersion: cilium.io/v2

kubernetes/infrastructure/network-policies/rook-ceph-ns.yaml

@@ -41,40 +41,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/spegel-ns.yaml

@@ -26,43 +26,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     # Peer P2P
     - toEndpoints:
@@ -92,40 +69,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/trmnl-ns.yaml

@@ -42,43 +42,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
 ---
 # The TRMNL panel polls /api/display over cleartext HTTP on the
 # terminus-device LoadBalancer. The firmware cannot be handed the internal

kubernetes/infrastructure/network-policies/velero-ns.yaml

@@ -28,40 +28,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/woodpecker-ci-ns.yaml

@@ -45,40 +45,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/network-policies/woodpecker-ns.yaml

@@ -0,0 +1,156 @@
+---
+# Baseline ingress policy for the `woodpecker` namespace (wp-pg now; server and
+# agent arrive in stage 2).
+#
+# Unlike the `apps` baseline this replaces, every allow here lands on a
+# namespace holding one service, so a namespace-scoped grant is not a blanket
+# grant across unrelated workloads. That is the point of the move: in `apps`,
+# letting the CNPG operator reach wp-pg would also have opened gitea, gatus,
+# external-dns and ical-proxy to the whole database namespace (issue #433).
+#
+# CAUTION when adding rules here: this policy has `endpointSelector: {}`, so
+# every rule below applies to EVERY pod in the namespace. A `toPorts` block
+# narrows the port, NOT the destination workload — that is governed solely by
+# the enclosing policy's endpointSelector. Anything meant for one workload
+# belongs in its own policy with its own selector, as
+# `wp-pg-allow-cnpg-operator` below does.
+#
+# No egress section, so egress is unrestricted. Deliberate for now and revisited
+# in stage 2: wp-pg needs DNS plus `world` for WAL archiving to Hetzner S3, and
+# the server/agent add gitea, the Kubernetes API and outbound plugin pulls.
+# Writing that ruleset once, with the full workload set present, beats guessing
+# it here and silently breaking the WAL archiving this stage exists to verify.
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: default-deny-ingress
+  namespace: woodpecker
+spec:
+  endpointSelector: {}
+  ingress:
+    # Intra-namespace: server <-> agent, server -> wp-pg.
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": woodpecker
+    # NOT here: ingress from the `ingress` namespace. Traefik terminates
+    # ci.renner.uno and forwards to the server, but that namespace also holds
+    # netbird-ingress, and this policy's endpointSelector:{} would extend the
+    # grant to wp-pg and the agent as well. Scoped to traefik -> server in the
+    # companion policy at the bottom of this file.
+    # Prometheus scrape. Namespace-wide and port-unrestricted, matching the
+    # other *-ns baselines; this is what covers wp-pg's :9187 metrics.
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": monitoring
+    # Kubelet probes and hostNetwork siblings.
+    - fromEntities:
+        - host
+        - remote-node
+    # ICMP — from any cluster pod. See home-assistant-ns.yaml for the rationale.
+    # INGRESS ONLY: do NOT add an egress section to this CNP.
+    #
+    # Needed here specifically because wp-pg-allow-cnpg-operator below attaches
+    # an L4 rule (toPorts :8000) to the wp-pg pods, and Cilium blocks ICMP to an
+    # endpoint once any layer 4 policy selects it unless the traffic is
+    # CT-related. Without this, PMTUD Destination Unreachable and Packet Too Big
+    # toward wp-pg are dropped silently — the failure shows up as stalled
+    # transfers, not as a policy denial.
+    #
+    # Namespace-wide is right for this one, unlike the :8000 case noted below:
+    # these are diagnostic and path-MTU messages that expose no API surface, so
+    # granting them across the namespace concedes nothing a per-workload rule
+    # would withhold.
+    - fromEndpoints:
+        - matchExpressions:
+            - key: io.kubernetes.pod.namespace
+              operator: Exists
+      icmps:
+        - fields:
+            - { type: 0,   family: IPv4 }
+            - { type: 3,   family: IPv4 }
+            - { type: 8,   family: IPv4 }
+            - { type: 11,  family: IPv4 }
+            - { type: 12,  family: IPv4 }
+            - { type: 1,   family: IPv6 }
+            - { type: 2,   family: IPv6 }
+            - { type: 3,   family: IPv6 }
+            - { type: 4,   family: IPv6 }
+            - { type: 128, family: IPv6 }
+            - { type: 129, family: IPv6 }
+            - { type: 133, family: IPv6 }
+            - { type: 134, family: IPv6 }
+            - { type: 135, family: IPv6 }
+            - { type: 136, family: IPv6 }
+            - { type: 143, family: IPv6 }
+    #
+    # NOT here: ingress from `woodpecker-ci`. Pipeline step pods do call the
+    # server back on :8000 to stream logs, but the CNPG instance manager serves
+    # its status API on :8000 too — so granting that on this endpointSelector:{}
+    # policy would hand arbitrary repo-supplied build steps a route to wp-pg's
+    # instance manager. It lands in stage 2 as its own policy selecting the
+    # server pod, the way woodpecker-allow-rotators already scopes its :8000
+    # rule in apps/woodpecker/networkpolicy.yaml.
+---
+# The CNPG operator polls each instance's status endpoint over HTTPS
+# (https://<pod-ip>:8000/pg/status) to populate Cluster status. Without it the
+# Cluster reports "Instance Status Extraction Error: HTTP communication issue"
+# while Postgres serves normally, and the operator loses failover and
+# switchover decisions — issue #433, where the operator's dial timed out
+# because the apps baseline never allowed the database namespace.
+#
+# Scoped to the wp-pg endpoints and that one port: the operator has no reason to
+# reach the woodpecker server or agent, and the barman and mariadb operators
+# sharing its namespace have no reason to reach anything here at all.
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: wp-pg-allow-cnpg-operator
+  namespace: woodpecker
+spec:
+  endpointSelector:
+    matchLabels:
+      cnpg.io/cluster: wp-pg
+  ingress:
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": database
+            app.kubernetes.io/name: cloudnative-pg
+      toPorts:
+        - ports:
+            - port: "8000"
+              protocol: TCP
+---
+# Traefik terminates ci.renner.uno and forwards to the server on :8000.
+#
+# Lives here, beside the baseline, rather than with the workload policies in
+# apps/woodpecker/networkpolicy.yaml — deliberately. The baseline's `ingress`
+# admit was removed in the same commit, and these two ship in the same
+# Kustomization (infrastructure-crds), so the swap lands in one reconcile. Split
+# across Kustomizations it would not: infrastructure-crds reconciles before the
+# `woodpecker` KS, so the admit would be withdrawn minutes before its
+# replacement arrived, and ci.renner.uno would 503 in the gap.
+#
+# Scoped to traefik and to the server pod. The `ingress` namespace also holds
+# netbird-ingress, and the baseline's endpointSelector:{} would have extended a
+# namespace-level admit to wp-pg and the agent. The `apps` policy this replaces
+# (allow-ingress.yaml) matches traefik by label for the same reason, and does
+# NOT apply here — it is hard-scoped to `namespace: apps`.
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: woodpecker-allow-traefik
+  namespace: woodpecker
+spec:
+  endpointSelector:
+    matchLabels:
+      app.kubernetes.io/name: woodpecker
+      app.kubernetes.io/component: server
+  ingress:
+    - fromEndpoints:
+        - matchLabels:
+            "k8s:io.kubernetes.pod.namespace": ingress
+            app.kubernetes.io/name: traefik
+      toPorts:
+        - ports:
+            - port: "8000"
+              protocol: TCP

kubernetes/infrastructure/network-policies/wordpress-ns.yaml

@@ -53,43 +53,20 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }
   egress:
     - toEndpoints:
         - matchLabels:
@@ -128,40 +105,17 @@ spec:
         - fields:
             - { type: 0,   family: IPv4 }
             - { type: 3,   family: IPv4 }
-            - { type: 4,   family: IPv4 }
-            - { type: 5,   family: IPv4 }
             - { type: 8,   family: IPv4 }
-            - { type: 9,   family: IPv4 }
-            - { type: 10,  family: IPv4 }
             - { type: 11,  family: IPv4 }
             - { type: 12,  family: IPv4 }
-            - { type: 13,  family: IPv4 }
-            - { type: 14,  family: IPv4 }
-            - { type: 15,  family: IPv4 }
-            - { type: 16,  family: IPv4 }
-            - { type: 17,  family: IPv4 }
-            - { type: 18,  family: IPv4 }
-            - { type: 30,  family: IPv4 }
             - { type: 1,   family: IPv6 }
             - { type: 2,   family: IPv6 }
             - { type: 3,   family: IPv6 }
             - { type: 4,   family: IPv6 }
             - { type: 128, family: IPv6 }
             - { type: 129, family: IPv6 }
-            - { type: 130, family: IPv6 }
-            - { type: 131, family: IPv6 }
-            - { type: 132, family: IPv6 }
             - { type: 133, family: IPv6 }
             - { type: 134, family: IPv6 }
             - { type: 135, family: IPv6 }
             - { type: 136, family: IPv6 }
-            - { type: 137, family: IPv6 }
-            - { type: 138, family: IPv6 }
-            - { type: 141, family: IPv6 }
-            - { type: 142, family: IPv6 }
             - { type: 143, family: IPv6 }
-            - { type: 148, family: IPv6 }
-            - { type: 149, family: IPv6 }
-            - { type: 151, family: IPv6 }
-            - { type: 152, family: IPv6 }
-            - { type: 153, family: IPv6 }

kubernetes/infrastructure/post-crds/openbao-clustersecretstore.yaml

@@ -30,6 +30,7 @@ spec:
         - paperless
         - trmnl
         - velero
+        - woodpecker # wp-pg barman creds; woodpecker moving out of `apps` (#433)
         - wordpress
   provider:
     vault: # ESO's provider name; speaks OpenBao fine

kubernetes/infrastructure/rook-ceph-cluster/cephcluster.yaml

@@ -24,6 +24,27 @@ spec:
   # gives headroom for parallel restores during cluster rebuild too
   # (paperless + audiobookshelf + immich + ... all clone at once).
   cephConfig:
+    mon:
+      # Ceph's 30% default assumes the mon has a filesystem to itself, where
+      # 30% free is a meaningful reserve. Here the mons live on
+      # dataDirHostPath /var/lib/rook — the node's /var, shared with ~29 GB
+      # of containerd image and snapshot storage — and the mon DB itself is
+      # ~106 MB. So the default measures container churn, not Ceph: k8s-2
+      # trips MON_DISK_LOW whenever the image cache fills, and image GC does
+      # not clear it (most of /var/lib/containerd is overlayfs snapshots held
+      # by running containers, which GC cannot reclaim — see #434).
+      # 20% of a 60 GB /var still leaves ~12 GB against a 106 MB database.
+      # mon_data_avail_crit stays at the 5% default, and CephMonDiskLow in
+      # monitoring-rules watches /var directly for the real risk, which is the
+      # node filling rather than the mon growing.
+      #
+      # BARE-METAL MIGRATION: revisit this. Give the mons their own volume and
+      # the default 30% becomes meaningful again, at which point this override
+      # should be dropped rather than carried over. It cannot be done on the
+      # current cluster — every StorageClass is Ceph-backed, so a mon PVC
+      # would be circular, and Rook only applies mon.volumeClaimTemplate to
+      # newly created mons, never migrating existing ones.
+      mon_data_avail_warn: "20"
     mgr:
       mgr/volumes/max_concurrent_clones: "16"
     # QLC tune for the Crucial P2 NVMe per host. Baseline 2026-05-05:

kubernetes/infrastructure/rook-ceph-cluster/kustomization.yaml

@@ -2,6 +2,7 @@ apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
 resources:
   - cephcluster.yaml
+  - toolbox.yaml
   - storageclass.yaml
   - volumesnapshotclass.yaml
   - objectstore.yaml

kubernetes/infrastructure/rook-ceph-cluster/toolbox.yaml

@@ -0,0 +1,172 @@
+# Upstream Rook toolbox, taken verbatim from
+# https://raw.githubusercontent.com/rook/rook/v1.20.4/deploy/examples/toolbox.yaml
+# (matching the operator image docker.io/rook/ceph:v1.20.4), with three
+# deliberate changes:
+#   - the image is pinned to the cluster's own Ceph version and carries the
+#     same imagepolicy marker as cephcluster.yaml, so the client never drifts
+#     ahead of the mons it talks to
+#   - resource requests/limits, since this is a long-lived idle pod
+#   - no other divergence; keep it that way so upstream diffs stay readable
+#
+# This is the only admin path to Ceph internals. Without it `ceph status`,
+# `ceph health detail`, `ceph osd df tree`, `ceph osd perf` and `ceph device
+# ls` are unreachable during an incident: the mons, OSDs and mgr mount no
+# admin keyring, and the operator's /etc/ceph is empty.
+#
+# It mounts the client.admin keyring from the rook-ceph-mon secret, so it is
+# a full-privilege credential holder, not a read-only one — Rook offers no
+# lesser-privileged toolbox. Ingress to it is gated by the namespace
+# default-deny-ingress CNP (network-policies/rook-ceph-ns.yaml).
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: rook-ceph-tools
+  namespace: rook-ceph
+  labels:
+    app: rook-ceph-tools
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: rook-ceph-tools
+  template:
+    metadata:
+      labels:
+        app: rook-ceph-tools
+    spec:
+      dnsPolicy: ClusterFirstWithHostNet
+      serviceAccountName: rook-ceph-default
+      containers:
+        - name: rook-ceph-tools
+          image: quay.io/ceph/ceph:v19.2.5 # {"$imagepolicy": "flux-system:ceph"}
+          command:
+            - /bin/bash
+            - -c
+            - |
+              # Replicate the script from toolbox.sh inline so the ceph image
+              # can be run directly, instead of requiring the rook toolbox
+              CEPH_CONFIG="/etc/ceph/ceph.conf"
+              MON_CONFIG="/etc/rook/mon-endpoints"
+              KEYRING_FILE="/etc/ceph/keyring"
+              CONFIG_OVERRIDE="/etc/rook-config-override/config"
+
+              # create a ceph config file in its default location so ceph/rados tools can be used
+              # without specifying any arguments
+              write_endpoints() {
+                endpoints=$(cat ${MON_CONFIG})
+
+                # filter out the mon names
+                # external cluster can have numbers or hyphens in mon names, handling them in regex
+                # shellcheck disable=SC2001
+                mon_endpoints=$(echo "${endpoints}"| sed 's/[a-z0-9_-]\+=//g')
+
+                DATE=$(date)
+                echo "$DATE writing mon endpoints to ${CEPH_CONFIG}: ${endpoints}"
+                  cat <<EOF > ${CEPH_CONFIG}
+              [global]
+              mon_host = ${mon_endpoints}
+
+              [client.admin]
+              keyring = ${KEYRING_FILE}
+              EOF
+
+                # Merge the config override if it exists and is not empty
+                if [ -f "${CONFIG_OVERRIDE}" ] && [ -s "${CONFIG_OVERRIDE}" ]; then
+                  echo "$DATE merging config override from ${CONFIG_OVERRIDE}"
+                  echo "" >> ${CEPH_CONFIG}
+                  cat ${CONFIG_OVERRIDE} >> ${CEPH_CONFIG}
+                  echo "" >> ${CEPH_CONFIG}
+                fi
+              }
+
+              # watch the endpoints config file and update if the mon endpoints ever change
+              watch_endpoints() {
+                # get the timestamp for the target of the soft link
+                real_path=$(realpath ${MON_CONFIG})
+                initial_time=$(stat -c %Z "${real_path}")
+                while true; do
+                  real_path=$(realpath ${MON_CONFIG})
+                  latest_time=$(stat -c %Z "${real_path}")
+
+                  if [[ "${latest_time}" != "${initial_time}" ]]; then
+                    write_endpoints
+                    initial_time=${latest_time}
+                  fi
+
+                  sleep 10
+                done
+              }
+
+              # read the secret from an env var (for backward compatibility), or from the secret file
+              ceph_secret=${ROOK_CEPH_SECRET}
+              if [[ "$ceph_secret" == "" ]]; then
+                ceph_secret=$(cat /var/lib/rook-ceph-mon/secret.keyring)
+              fi
+
+              # create the keyring file
+              cat <<EOF > ${KEYRING_FILE}
+              [${ROOK_CEPH_USERNAME}]
+              key = ${ceph_secret}
+              EOF
+
+              # write the initial config file
+              write_endpoints
+
+              # continuously update the mon endpoints if they fail over
+              watch_endpoints
+          imagePullPolicy: IfNotPresent
+          tty: true
+          securityContext:
+            runAsNonRoot: true
+            runAsUser: 2016
+            runAsGroup: 2016
+            capabilities:
+              drop: ["ALL"]
+          env:
+            - name: ROOK_CEPH_USERNAME
+              valueFrom:
+                secretKeyRef:
+                  name: rook-ceph-mon
+                  key: ceph-username
+          resources:
+            requests:
+              cpu: 10m
+              memory: 128Mi
+            limits:
+              memory: 512Mi
+          volumeMounts:
+            - mountPath: /etc/ceph
+              name: ceph-config
+            - name: mon-endpoint-volume
+              mountPath: /etc/rook
+            - name: ceph-admin-secret
+              mountPath: /var/lib/rook-ceph-mon
+              readOnly: true
+            - name: rook-config-override
+              mountPath: /etc/rook-config-override
+              readOnly: true
+      volumes:
+        - name: ceph-admin-secret
+          secret:
+            secretName: rook-ceph-mon
+            optional: false
+            items:
+              - key: ceph-secret
+                path: secret.keyring
+        - name: mon-endpoint-volume
+          configMap:
+            name: rook-ceph-mon-endpoints
+            items:
+              - key: data
+                path: mon-endpoints
+        - name: rook-config-override
+          configMap:
+            name: rook-config-override
+            optional: true
+        - name: ceph-config
+          emptyDir: {}
+      tolerations:
+        - key: "node.kubernetes.io/unreachable"
+          operator: "Exists"
+          effect: "NoExecute"
+          tolerationSeconds: 5

kubernetes/talos/cilium.yaml

@@ -249,6 +249,11 @@ data:
 
   identity-heartbeat-timeout: "30m0s"
   identity-gc-interval: "15m0s"
+  # Exclude Woodpecker's per-build labels from identity computation, so CI
+  # steps share one identity instead of minting one each. Keep in lockstep
+  # with patches/cilium-cni.yaml and values.labels in
+  # kubernetes/infrastructure/cilium/helmrelease.yaml.
+  labels: '!woodpecker-ci\.org/.* !step$'
   cilium-endpoint-gc-interval: "5m0s"
   nodes-gc-interval: "5m0s"
 
@@ -302,8 +307,9 @@ data:
   # sizing of the TCP CT, non-TCP CT, NAT and policy BPF maps.
   bpf-map-dynamic-size-ratio: "0.0025"
   # bpf-policy-map-max specifies the maximum number of entries in endpoint
-  # policy map (per endpoint)
-  bpf-policy-map-max: "16384"
+  # policy map (per endpoint). Keep in lockstep with patches/cilium-cni.yaml and
+  # values.bpf.policyMapMax in kubernetes/infrastructure/cilium/helmrelease.yaml.
+  bpf-policy-map-max: "65536"
   # bpf-policy-stats-map-max specifies the maximum number of entries in global
   # policy stats map
   bpf-policy-stats-map-max: "65536"

kubernetes/talos/patches/cilium-cni.yaml

@@ -267,6 +267,11 @@ cluster:
         
           identity-heartbeat-timeout: "30m0s"
           identity-gc-interval: "15m0s"
+          # Exclude Woodpecker's per-build labels from identity computation, so
+          # CI steps share one identity instead of minting one each. Keep in
+          # lockstep with values.labels in
+          # kubernetes/infrastructure/cilium/helmrelease.yaml.
+          labels: '!woodpecker-ci\.org/.* !step$'
           cilium-endpoint-gc-interval: "5m0s"
           nodes-gc-interval: "5m0s"
         
@@ -320,8 +325,12 @@ cluster:
           # sizing of the TCP CT, non-TCP CT, NAT and policy BPF maps.
           bpf-map-dynamic-size-ratio: "0.0025"
           # bpf-policy-map-max specifies the maximum number of entries in endpoint
-          # policy map (per endpoint)
-          bpf-policy-map-max: "16384"
+          # policy map (per endpoint). Keep in lockstep with values.bpf.policyMapMax
+          # in kubernetes/infrastructure/cilium/helmrelease.yaml, and with the third
+          # copy in kubernetes/talos/cilium.yaml: bootstrap installs Cilium from this
+          # inline manifest, so a lower value here means a cold rebuild comes up with
+          # a map that overflows until Flux reconciles.
+          bpf-policy-map-max: "65536"
           # bpf-policy-stats-map-max specifies the maximum number of entries in global
           # policy stats map
           bpf-policy-stats-map-max: "65536"

kubernetes/talos/patches/cluster.yaml

@@ -26,16 +26,20 @@ machine:
     nodeIP:
       validSubnets:
         - 10.2.40.0/24
-    # Lower the image GC thresholds from the kubelet defaults (85/80)
-    # so containerd's image cache is pruned before /var crosses Ceph's
-    # mon_data_avail_warn line (mon DB warns when its hostpath has
-    # <30% free). k8s-2 and k8s-3 sit at 77-79% used because of pod
-    # density (75 pods on k8s-2 vs 42 on k8s-1) — unused image layers
-    # accumulate untouched until the 85% high watermark, which the
-    # node never hits, so GC never fires. 70/60 keeps /var safely
-    # under 30%-free without raising the VM disk again. Spegel P2P
-    # pull-through softens the re-pull cost when GC'd images are
-    # needed back.
+    # Lower the image GC thresholds from the kubelet defaults (85/80) to
+    # bound containerd's image cache, which is the largest single consumer
+    # of /var. Spegel P2P pull-through softens the re-pull cost when GC'd
+    # images are needed back.
+    #
+    # These thresholds do NOT control whether Ceph's mon reports
+    # MON_DISK_LOW, and must not be tuned for that. Measured on k8s-2:
+    # image GC frees only the content store (~8.6 GB), while the bulk of
+    # /var/lib/containerd is ~20 GB of overlayfs snapshots — unpacked
+    # layers shared with running containers, which GC cannot reclaim.
+    # Dropping high to 60 deleted 28 images and moved free space by 0.02
+    # percentage points. The mon's own data is ~106 MB; its 30%-free
+    # warning is measuring a filesystem it merely shares, so the lever for
+    # it is elsewhere (mon volume, /var size, or mon_data_avail_warn).
     extraConfig:
       imageGCHighThresholdPercent: 70
       imageGCLowThresholdPercent: 60

opentofu/dns_renner_uno.tf

@@ -1,8 +1,20 @@
 locals {
   renner_uno_records = {
-    # A Records
-    "@"   = { type = "A", value = "159.69.42.237" }
-    "www" = { type = "A", value = "159.69.42.237" }
+    # No "@" / "www" entries. Both used to pin renner.uno and www.renner.uno
+    # to 159.69.42.237, the Hetzner VM that hosted the WordPress site until it
+    # moved into the cluster (kubernetes/apps/wordpress). Neither record is
+    # actually live on the UDM any more — verified 2026-08-16: a LAN query for
+    # www.renner.uno returns the public answer (proxy.renner.uno) — so this
+    # block was drift waiting to be re-applied.
+    #
+    # The correct end state is exactly this absence: www.renner.uno is labelled
+    # dns.renner.uno/public, so external-dns-unifi deliberately writes no UDM
+    # record and LAN clients follow the public path (wildcard -> proxy) and
+    # hairpin back in. Re-adding an A record here would point the house at a
+    # server that is being decommissioned.
+    #
+    # The apex stays with Cloudflare, where a redirect rule sends
+    # renner.uno/* to https://www.renner.uno/*.
 
     # CNAME Records (External Targets)
     "nut" = { type = "CNAME", value = "nut.srv.renner.uno" }