Image-verifier liveness check asserts the wrong mechanism (containerd bin_dir, not Talos-native verification) #3347

🤖 Generated by the Agentic Engineer

Evidence

scripts/validate-image-verifier-liveness.sh asserts that containerd's image-verifier bin_dir is
configured and non-empty, and that the io.containerd.image-verifier.v1.bindir plugin is enabled.

Measured live on 2026-08-23 ~23:00Z against Talos v1.13.8, and recorded in detail on
#3101: that is not
how Talos v1.13 verifies images. machined exposes an ImageService, containerd's CRI calls
/machine.ImageService/Verify on every pull with role os:image:verifier, and a native
security.ImageVerificationConfigController materialises the rules as ImageVerificationRule
resources. No bin_dir exists in either containerd config, and none is wanted.

So the check's central assertion is false on a correctly-enforcing node: it reports the fleet
broken precisely when verification is working. It ships dormant today, so nothing is currently red —
but it cannot be activated as written.

Affected audience and impact

Anyone relying on this check to answer "can our nodes actually enforce image verification". As written
it can only ever answer a question about a mechanism this cluster does not use, in either direction:
green if someone configured an unused bin_dir, red on a healthy fleet.

Expected behaviour

The check asserts the property that actually determines enforcement:

• every node carries the expected ImageVerificationRule resources (talosctl get ivr) — correct
  patterns, phase: running, skip: false, deny: false, and the expected keylessVerifier
  issuer/subjectRegex;
• the rules match what talos/cluster/verify-first-party-images.yaml declares, so config drift is caught;
• ideally, that machined's ImageService/Verify is actually being exercised, rather than inferring it.

Two findings from #3320 that survive and must be carried over

These were real defects in the check's node handling, independent of which property it asserts.
#3320 is closed because its assertion is wrong,
but these two must not be lost with it:

1. The fleet list is read once, before a walk that visits nodes one at a time. A worker the
   autoscaler adds partway through is never looked at, and the run still reports every node in the
   older list as healthy. Re-read the fleet after the checks and re-run if it changed, bounded so a
   continuously-scaling cluster neither flaps nor loops forever.
2. Nodes are identified by address alone. When the autoscaler retires a machine and the replacement
   takes over its address, those read as the same node — so a machine nobody inspected is reported as
   one that passed. Identify by unique ID together with address, and refuse a node without one rather
   than guessing.

Both are live concerns here, not hypotheticals: the fleet currently includes an autoscaled worker
(autoscale-cx43-…), and it did correctly receive all 3 rules.

Acceptance criteria

• The check asserts the Talos-native property above; every trace of bin_dir / bindir-plugin
  parsing is removed rather than left dormant.
• Finding 1 is fixed, with a test that fails when the fix is removed.
• Finding 2 is fixed, with a test that fails when the fix is removed.
• Run against the real fleet and observed green — all 7 nodes currently satisfy the native property,
  so a correct check should pass today.
• Activation (restoring the daily schedule trigger) is sequenced per Establish that first-party image signature verification actually enforces on the fleet #3101, not done here.

Rough size: M — the assertion is far simpler than the ~2000 lines of TOML parsing it replaces.