EKS ownership binding discards the recorded AWS credential mapping

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

EKSOwnershipState deliberately records the complete AWS environment-variable-name mapping used when a cluster was bound:

// AWSOptions stores the complete environment-variable-name mapping used to resolve AWS
// credentials. Credential values are never persisted. Records without this mapping predate the
// schema extension and require explicit rebind before state-only lifecycle commands may use them.
AWSOptions v1alpha1.OptionsAWS `json:"awsOptions,omitzero"`

ListEKSOwnershipStates enforces that: a record without a complete mapping is rejected as unusable. So the mapping is treated as a precondition for acting on a record at all.

But the binding path then discards it. bindFromOwnershipRecord keeps only the region:

return &clusterprovisioner.EKSConfig{
    Name:       name,
    Region:     region,
    ConfigPath: configPath,
}, nil

clusterprovisioner.EKSConfig has no field for it — its fields are Name, NameFromConfig, Region, ConfigPath, KubeconfigPath — so the mapping cannot be carried through even in principle without a type change.

Problem / audience

Operators who resolve AWS credentials through non-default environment-variable names (a per-account or per-profile naming scheme). The lifecycle spec built from an ownership record carries no Spec.Provider.AWS options, so credential resolution falls back to the canonical AWS_* variables instead of the names captured at bind time.

Two outcomes, and the second is the dangerous one:

• the action fails despite valid credentials being present under the operator's own variable names; or
• the canonical variables select a different AWS account that happens to contain a cluster of the same name, and the action targets that one.

This is the same class of defect as the region redirect that motivated the ownership record in the first place — an action resolving its target from ambient environment rather than from what was recorded — one axis over. It affects delete, which makes it destructive.

Note the guard that still stands: confirmEKSOwnership runs regardless, so this is not an unauthenticated path. The risk is that it authenticates against the wrong account's cluster.

Why it is not fixed in the PR that found it

Found by review on #6385. Fixing it means adding the mapping to clusterprovisioner.EKSConfig and threading it through DefaultFactory into credential resolution — a cross-package change to a shared provisioner type, on a destructive path. #6385 already carries two behaviour changes through several review rounds, and folding a third in would make it materially harder to review.

Smallest useful change

1. Carry the recorded AWSOptions on the config the binding produces.
2. Resolve credentials from that frozen mapping for state-bound lifecycle actions, rather than from the ambient defaults.
3. Prove it with a test where the recorded variable names differ from the canonical ones, asserting which names are read — not merely that the action succeeds, since it succeeds either way when both point at the same account.

Acceptance criteria

• A lifecycle action bound from an ownership record resolves AWS credentials using the variable names in that record.
• A test fails if resolution falls back to the canonical AWS_* names when the record names others.
• Records predating the mapping keep their current behaviour (explicit rebind required), with no new failure mode for them.

Rough size: S–M.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• fix(eks): custom AWS credential mappings are lost when authorizing from persisted state #6227

🔗 Related PRs

#5826 - feat(operator): implement Connector for EKS (AWS SDK-built kubeconfig) [merged]
#6089 - fix(eks): honor custom AWS credential mappings [merged]
#6194 - ci(eks): enforce smoke-test role boundaries [merged]
#6267 - feat(eks): graduate in-place node scaling [merged]
#6333 - feat(eks): reconcile AWS load balancer controller opt-in [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

Closing: fixed on main through the credential snapshot, not through EKSConfig

Checked against current main. bindFromOwnershipRecord still returns an EKSConfig with only the name, region and config path, as described above. But credentials no longer travel through that type, so nothing is lost:

• Before a local API start, stop or delete, the ownership guard resolves credentials with eksOwnershipResolver. That layers the record's AWSOptions mapping over the injected resolver (NewRecordedAWSResolver) and freezes the result.
• The frozen resolution is handed to the provisioner factory with WithEKSMutationGuard, and it overrides whatever the spec would have produced. The same snapshot sets the eksctl child environment and the AWS SDK clients. The factory refuses to run when an ownership verifier is present without a frozen resolution.

Against the acceptance criteria:

1. Recorded names are used: yes, as traced above.
2. A test fails on fallback to canonical names: TestLifecycleCredentialsResolveThroughTheOwnershipRecord, plus the recorded-resolver precedence tests in svc/credentials.
3. Legacy records unchanged: TestALegacyRecordKeepsTheInjectedResolver. A record without the mapping falls back to the injected resolver and is still rejected by the verifier's migration error.

One coverage gap remains, and it is not a defect: no single test follows a recorded alias all the way into the eksctl child environment for a cluster bound from its record. The resolver tests stop at the resolver, and the factory tests use a hand-built frozen resolution. Both seams are pinned separately.