fix(ci): EKS authorization check fails on every PR that touches a HelmRelease

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

🔐 Validate EKS Authorization fails on the pull_request event for any PR that modifies a
HelmRelease, reporting unresolved Flux substitution in authorization resource for ~26 HelmReleases
across the platform — regardless of which one the PR touched.

Measured across the 12 most recent ci.yaml runs (2026-08-16):

Branch	HelmRelease files changed	EKS-auth job
codex/fix-default-deny-schema (#3170)	0	✅ success (×3)
claude/homepage-groups (#3173)	0	✅ success
claude/crossview-config-reload (#3171)	1	❌ failure
renovate/docker.io-actualbudget-actual	image bump in a HelmRelease	❌ failure (×4)

The correlation is exact and has no counterexample in the window: zero HelmRelease changes → pass;
any HelmRelease change → fail. merge_group runs pass (pr-2723, pr-3170), and neither of those
carried a HelmRelease change either, so no run has yet shown this check passing over a changed
HelmRelease on any event.

On #3171 the diff is a single annotation added to one HelmRelease's postRenderer patch. Crossview
is not among the 26 resources reported unresolved — the failures are all unrelated HelmReleases
(dex, cilium, reloader, cert-manager, …), so the PR's own content is not what the validator is
objecting to.

Impact

This blocks a whole class of change from ever going green on a PR:

• every Renovate image/chart bump that lives in a HelmRelease (currently stuck, ×4 re-runs),
• any hand-authored HelmRelease edit — including the crossview login fix in fix(crossview): roll the app when its OIDC config changes #3171.

CI - Required Checks aggregates it, so affected PRs sit BLOCKED and cannot enqueue.

Suspected cause

The job runs the validator identically on pull_request and merge_group with no Flux substitution
variables available, so ${domain}-style references in HelmReleases cannot resolve. There is already
precedent in this repo for handling exactly that: validate-talos renders with placeholder values
standing in for env-expanded secrets so a PR event can validate without secrets.

Expected behaviour

A PR that changes a HelmRelease can pass this check, without weakening what it verifies on the
merge-group/deploy path.

Candidate fixes

1. Substitute placeholders for unresolvable Flux variables on the pull_request event, mirroring
   validate-talos.
2. Have the validator treat an unresolved substitution in an unchanged resource as out of scope,
   so a PR is judged on its own diff.
3. ❌ Do not simply drop the job from pull_request — that removes the pre-merge signal entirely.

Acceptance criteria

• A PR touching only a HelmRelease passes the check.
• A PR that genuinely breaks the authorization surface still fails it (negative control — without
  this, a fix could pass by disabling the check).
• The Renovate HelmRelease PRs above go green without manual intervention.

[coderabbitai]

🔗 Related PRs

#2704 - fix(aws): constrain eks-ci KMS grant creation [merged]
#2707 - fix(unifi): prevent pruning managed network resources [merged]
#2741 - fix(headlamp): disable unverified plugin downloads [merged]
#2985 - fix(k8s): gate deploy health on a serving CNPG cluster instead of a fully-ready one [merged]
#3096 - fix(observability): stop Flux substitution eating the CNPG alert's grace period [merged]
#3109 - fix(deploy): avoid redundant GHCR node reboots [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Agentic Engineer

Withdrawing this — I misdiagnosed it, and the proposed fixes would have weakened a working
security control. Closing as invalid.

What I got wrong

I read the ~26 unresolved Flux substitution lines as the failure. They are not. The validator's own
code says so explicitly:

substitutionProblems are DIAGNOSTIC, not a control, and that is deliberate. […] Emitting the
notes only alongside a mismatch is what keeps them useful: they explain a hash that moved.

They are appended to problems only when the surface fingerprint already mismatches. The actual
failure was one line further up, which I did not scroll to:

--- FAIL: TestValidateAuthorizationAcceptsCommittedPolicy
    validateAuthorization() error = unapproved rendered authorization surface fingerprint:
    133166992d16b83da48105656927c1b8cdeadbe37d041bef7a50284cec028fb7

The check is working exactly as designed. A HelmRelease is an authorization-capable resource, so
editing one moves the aggregate fingerprint and the approved value in
scripts/validate-eks-ci-role-policy/main.go must be re-approved with a documented measurement — the
protocol the constant's comment block already demonstrates for #2741 and #3168.

My observed correlation (HelmRelease changed → fails; not changed → passes) was real. The cause I
attributed to it was wrong: it is not that substitution cannot resolve on the pull_request event,
it is that changing an authorization-surface document requires re-approval.

Why this mattered more than an ordinary wrong issue

Both candidate fixes I proposed — substituting placeholders for unresolved variables, and treating
unresolved substitutions in unchanged resources as out of scope — would have suppressed the
diagnostics while leaving the real control either untouched or degraded. Neither addressed the actual
failure, and shipping either would have been friction-reduction by removing a control, which is a
silent regression rather than a fix.

The correlation evidence stands as recorded; only the diagnosis is retracted.

What actually applies

• fix(crossview): roll the app when its OIDC config changes #3171 is not blocked by a CI defect. It needs expectedRenderedSurfaceSHA updated to
  133166992d16…, with the same measured justification the constant's history requires: render both
  sides, prove surface membership identical in both directions, and prove every RBAC object
  byte-identical — i.e. demonstrate the annotation is authorization-neutral rather than asserting it.
• fix(crossview): tell the app the request arrived over https #3177 is unaffected and passed this check, because a ConfigMap is not in the authorization
  surface. That is consistent with the control, not a way around it.

Residual observation, recorded without a proposed change: every Renovate bump that edits a
HelmRelease will require the same re-approval. That is the control behaving as intended; whether the
re-approval should be easier to produce is a maintainer call, not something to route around.