netbird-ingress.yaml's ImagePolicy had range: ">=0.73.0" — unbounded
above. Every other one of the 23 enrolled image-automation policies pins
to a major (or major.minor), per the README's stated mitigation:
image-automation pushes bumps direct to master with no PR gate, so
ranges must be tight enough that a breaking bump requires manual policy
widening.
Bounded it to "0.x", matching the existing cnpg-barman-plugin (0.x)
precedent for pre-1.0 images. Verified the currently deployed tag
(v0.74.4-rootless, in kubernetes/infrastructure/netbird-ingress/daemonset.yaml)
stays in range — no rollback. Also added the missing netbird-ingress row
to the README's enrolled-policies table (it was wired into the
kustomization but absent from the table).
Not in this PR — needs an owner decision
The issue also flagged two items I can't act on unilaterally and have
posted about on #204 for a decision:
Dedicated scoped push token for image-automation (currently reuses the
full-scope gitea_admin bootstrap PAT that Flux itself uses to pull —
creating/rotating a new scoped token is an operator action).
Whether to PR-gate image-automation bumps instead of direct-push (a
behavior change, not a bugfix).
The home-assistant.yaml policy (>=2026.0.0) was also flagged as
unbounded in the original finding, but its comment documents a
deliberate rationale (calver year-rollover guard, tag pattern already
restricts to bare numeric triplets) — left as-is; noted on the issue.
Fixes #204 (partial).
## What
`netbird-ingress.yaml`'s ImagePolicy had `range: ">=0.73.0"` — unbounded
above. Every other one of the 23 enrolled image-automation policies pins
to a major (or major.minor), per the README's stated mitigation:
image-automation pushes bumps direct to master with no PR gate, so
ranges must be tight enough that a breaking bump requires manual policy
widening.
Bounded it to `"0.x"`, matching the existing `cnpg-barman-plugin` (`0.x`)
precedent for pre-1.0 images. Verified the currently deployed tag
(`v0.74.4-rootless`, in `kubernetes/infrastructure/netbird-ingress/daemonset.yaml`)
stays in range — no rollback. Also added the missing `netbird-ingress` row
to the README's enrolled-policies table (it was wired into the
kustomization but absent from the table).
## Not in this PR — needs an owner decision
The issue also flagged two items I can't act on unilaterally and have
posted about on #204 for a decision:
- Dedicated scoped push token for image-automation (currently reuses the
full-scope `gitea_admin` bootstrap PAT that Flux itself uses to pull —
creating/rotating a new scoped token is an operator action).
- Whether to PR-gate image-automation bumps instead of direct-push (a
behavior change, not a bugfix).
The `home-assistant.yaml` policy (`>=2026.0.0`) was also flagged as
unbounded in the original finding, but its comment documents a
deliberate rationale (calver year-rollover guard, tag pattern already
restricts to bare numeric triplets) — left as-is; noted on the issue.
netbird-ingress.yaml's ImagePolicy used ">=0.73.0" — unbounded above,
unlike every other of the 23 enrolled policies which pin to a major
(or major.minor). Since image-automation pushes bumps straight to
master with no PR gate, an unbounded range lets any future upstream
release (including a breaking 1.x) land automatically.
Bound it to "0.x", consistent with cnpg-barman-plugin's precedent for
pre-1.0 images: the currently deployed v0.74.4-rootless stays in
range, and a 1.x jump now requires a manual policy widen. Also adds
netbird-ingress to the README's enrolled-policies table, where it was
missing despite being wired into the kustomization.
Fixes#204 (partial — see issue comment for the scoped-token and
PR-gating items, which need an owner decision).
Co-Authored-By: Claude Bot <claude-bot@renner.uno>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #204 (partial).
What
netbird-ingress.yaml's ImagePolicy hadrange: ">=0.73.0"— unboundedabove. Every other one of the 23 enrolled image-automation policies pins
to a major (or major.minor), per the README's stated mitigation:
image-automation pushes bumps direct to master with no PR gate, so
ranges must be tight enough that a breaking bump requires manual policy
widening.
Bounded it to
"0.x", matching the existingcnpg-barman-plugin(0.x)precedent for pre-1.0 images. Verified the currently deployed tag
(
v0.74.4-rootless, inkubernetes/infrastructure/netbird-ingress/daemonset.yaml)stays in range — no rollback. Also added the missing
netbird-ingressrowto the README's enrolled-policies table (it was wired into the
kustomization but absent from the table).
Not in this PR — needs an owner decision
The issue also flagged two items I can't act on unilaterally and have
posted about on #204 for a decision:
full-scope
gitea_adminbootstrap PAT that Flux itself uses to pull —creating/rotating a new scoped token is an operator action).
behavior change, not a bugfix).
The
home-assistant.yamlpolicy (>=2026.0.0) was also flagged asunbounded in the original finding, but its comment documents a
deliberate rationale (calver year-rollover guard, tag pattern already
restricts to bare numeric triplets) — left as-is; noted on the issue.