fix(argo): let the tombstones read what they promise to protect

sean commented

2026-09-08 22:02:44 +00:00

Owner

Both retirement Jobs failed on their OWN reads. The RBAC is pinned by resourceNames so neither Job can touch the object that must survive -- right, and it also meant neither could SEE it. The API answered 403 and each read that as absence. Neither was true: all three ArgoCD CRDs are present and binjovi-deploy-argocd is ten days old with the agent running as it. argo-crd-retire had already deleted all eleven Argo CRDs (and the Workflow CRD took the 62 leftover objects with it) before failing its post-condition; binjovi-argo-rbac-retire refused before deleting anything, which is exactly what it was asked to do. The fix is a read grant, not a looser fence: verbs [get] on precisely the protected objects, still absent from every delete grant, and 403 now separate from 404 with its own message. https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean added 1 commit

2026-09-08 22:02:44 +00:00

fix(argo): let the tombstones read what they promise to protect

binjovi/ci Binjovi failed the frozen plan

Details

d17cdee62b

Both retirement Jobs ran and both failed on their own reads. The RBAC in each
is pinned by `resourceNames` so the Job cannot touch the object that must
survive -- which is right, and which also meant it could not SEE it. The API
answered 403 and each Job read that as absence:

  applications.argoproj.io is missing (HTTP 403) -- ArgoCD CRD lost
  binjovi-deploy-argocd is already missing; refusing

Neither was true. All three ArgoCD CustomResourceDefinitions are present and
`binjovi-deploy-argocd` is ten days old with the agent running as it.

WHAT ACTUALLY HAPPENED. `argo-crd-retire` deleted all eleven Argo CRDs
successfully -- and the Workflow CRD took the 62 leftover Workflow objects with
it -- then failed its post-condition. `binjovi-argo-rbac-retire` refused BEFORE
deleting anything, which is the behaviour that was asked of it: it would rather
stop than proceed unable to prove the ArgoCD agent's identity is intact.

THE FIX IS A READ GRANT, NOT A LOOSER FENCE. Each Job gains `verbs: [get]` on
exactly the objects it must protect -- the three ArgoCD CRDs, and
`binjovi-deploy-argocd` -- and they stay absent from every delete grant. A
check that cannot read what it protects proves nothing, and reading a refusal
as success is how such a check quietly stops checking.

403 and 404 are now separate outcomes with separate messages. Absence means the
thing was destroyed and is fatal; unreachable means the assertion could not run
and is also fatal, but says so.

The guards pin the asymmetry from both sides, each with its own negative
control: the surviving object must be readable AND must not be deletable, so
dropping the read grant and promoting it to a delete grant each turn a guard
red on their own.

Claude-Session: https://claude.ai/code/session_01KZoQin34jeyt6nDGqvJA76

sean force-pushed sean/tombstone-read-grants from d17cdee62b

binjovi/ci Binjovi failed the frozen plan

Details

to 59b34c368d

binjovi/ci Binjovi completed the frozen plan

Details

2026-09-09 07:49:51 +00:00

Compare

binjovi-bot merged commit 59b34c368d into trunk

2026-09-09 08:03:20 +00:00

Rows
Columns

fix(argo): let the tombstones read what they promise to protect #468