Concurrent re-approvals of the EKS rendered-surface fingerprint silently invalidate each other #3740

🤖 Generated by the Agentic Engineer

Evidence

scripts/validate-eks-ci-role-policy/main.go pins expectedRenderedSurfaceSHA, the aggregate
fingerprint of the rendered EKS authorization surface. Any change that moves a selected auth
document must re-approve it, with a conservation proof.

Three branches currently in flight each re-approved it, and all three declare the same base:

Read directly from the three trees. Identical base, three different results — so each aggregate
describes a tree containing its own delta and none of the others.

Why this is a security problem and not just a merge annoyance

The fingerprint exists to make an unreviewed change to the EKS authorization surface fail loudly.
Its guarantee is "this exact rendered surface was reviewed and approved". Concurrent re-approval
breaks that guarantee in a way that is invisible at exactly the moment someone is most likely to get
it wrong:

1. Whichever branch merges first invalidates the other two, because their aggregates no longer
   describe a tree that includes the merged delta.
2. The result surfaces as an ordinary merge conflict in a constant, and the natural resolutions —
   take ours, take theirs, or splice the two comment blocks together — all yield a fingerprint that
   does not describe the merged tree. The conflict markers give the resolver no signal that both
   values are stale; the only evidence is the Previous aggregate lines, which sit outside the
   conflicted hunk and read as prose.
3. The failure mode is fail-open in appearance: a wrong-but-plausible constant looks exactly like
   a correct one. It is caught today only because CI re-renders and compares — so the control's real
   integrity currently rests on CI, not on the approval, while the approval is what carries the
   human-reviewed conservation narrative.

This nearly happened on #3735 today. It is DIRTY, GitHub cannot auto-update it, and the sole
conflicted file is this one.

Expected behaviour

A re-approval that was computed against a base which is no longer the merge base should be
detectable mechanically, rather than depending on a resolver noticing two hex strings in a
comment.

Acceptance criteria

• The approval carries its base in a machine-readable form rather than only in prose — the
  aggregate it supersedes, next to the aggregate it asserts.
• The validator fails when the recorded base is not the current base — i.e. when an approval was
  computed against a tree that has since moved — with a message that says re-derive the
  aggregate against the current base, not merely that the digests differ. A guardrail that
  blocks without naming the fix is a friction tax and gets routed around.
• Proven RED/GREEN: a re-approval carrying a stale base is rejected, and the same approval
  with a current base passes. The RED case is the one that matters — assert it fails for the
  right reason, not merely that it is non-zero.
• A negative control: an unrelated change that legitimately moves nothing must not start failing.

Note on where the digest can be derived

Worth recording for whoever picks this up, because it shapes the fix: the aggregate cannot be
computed on the agent host. The file's own comments record that this host renders with kubectl
v1.36.1 / kustomize v5.8.1, which the validator rejects as unapproved, so approvals here are taken
from CI's failure output. Any proposed fix that assumes local re-derivation will not work in the
environment that actually has to run it.

Related: #3735, #3736 are both blocked behind exactly this.

Rough size: small-to-medium — the detection is a few lines; the care is all in the RED/GREEN proof.