🤖 Generated by the Agentic Engineer
Evidence
Found while fixing #6443 on #6434, and confirmed against the code.
Once #6434 lands, the ownership record carries the AWS variable names the create resolved through — credentials.AWSOptionsWithDefaults(identity.awsOptions), taken from spec.provider.aws. The verification path in the same package still resolves independently from the ambient resolver:
defaultEKSGuard → eksIdentityClient(ctx, region) → credentials.ResolveAWS(s.discoverer.Resolver) (pkg/cli/clusterapi/eks_ownership.go), which reads the canonical AWS_* names.
The standalone CLI path does honour the persisted names — restorePersistedAWSOptions merges ownership.AWSOptions back in before resolving (pkg/cli/cmd/cluster/unmanaged_guard.go:365-436). The local API backend has no equivalent step.
Affected audience and impact
Operators who set custom spec.provider.aws variable names and drive EKS lifecycle actions from the local web UI.
This fails closed, so it is not a second instance of #6443's fail-open. Verification queries whichever account the ambient credentials name: it either finds nothing (refused) or finds a different incarnation whose identity does not match the record (refused). The cost is availability, not safety — a cluster created under custom variable names cannot be deleted, started or stopped through the local API unless the canonical AWS_* environment happens to point at the same account.
That is the failure mode captureEKSOwnership's own doc comment calls out as the thing to avoid: "a guard that blocks the path it is meant to protect".
Expected behaviour
A guarded lifecycle action resolves AWS through the variable names recorded on the ownership state for that cluster, falling back to the ambient resolver only when the record carries none — mirroring restorePersistedAWSOptions.
Acceptance criteria
Size
Small. One resolution site plus tests; the CLI path already demonstrates the shape.
Evidence
Found while fixing #6443 on #6434, and confirmed against the code.
Once #6434 lands, the ownership record carries the AWS variable names the create resolved through —
credentials.AWSOptionsWithDefaults(identity.awsOptions), taken fromspec.provider.aws. The verification path in the same package still resolves independently from the ambient resolver:defaultEKSGuard→eksIdentityClient(ctx, region)→credentials.ResolveAWS(s.discoverer.Resolver)(pkg/cli/clusterapi/eks_ownership.go), which reads the canonicalAWS_*names.The standalone CLI path does honour the persisted names —
restorePersistedAWSOptionsmergesownership.AWSOptionsback in before resolving (pkg/cli/cmd/cluster/unmanaged_guard.go:365-436). The local API backend has no equivalent step.Affected audience and impact
Operators who set custom
spec.provider.awsvariable names and drive EKS lifecycle actions from the local web UI.This fails closed, so it is not a second instance of #6443's fail-open. Verification queries whichever account the ambient credentials name: it either finds nothing (refused) or finds a different incarnation whose identity does not match the record (refused). The cost is availability, not safety — a cluster created under custom variable names cannot be deleted, started or stopped through the local API unless the canonical
AWS_*environment happens to point at the same account.That is the failure mode
captureEKSOwnership's own doc comment calls out as the thing to avoid: "a guard that blocks the path it is meant to protect".Expected behaviour
A guarded lifecycle action resolves AWS through the variable names recorded on the ownership state for that cluster, falling back to the ambient resolver only when the record carries none — mirroring
restorePersistedAWSOptions.Acceptance criteria
defaultEKSGuardresolves credentials through the persistedownership.AWSOptionswhen present.AWS_*names unset or pointing elsewhere.Size
Small. One resolution site plus tests; the CLI path already demonstrates the shape.