What happened:
The issue occurred because we lost the SSH key that was originally used for cluster provisioning.
What you expected to happen:
I updated the SSH keys on the CAPI side, and the swap was successful. However, when I try to initiate a cluster upgrade with EKS-A, it treats the SSH key as immutable and continues to enforce the old key. During the upgrade, EKS-A still uses the old SSH key. I expected the cluster to use the new key, but EKS-A appears to block this change.
How to reproduce it (as minimally and precisely as possible):
- Provision the cluster with SSH key A
- Override the cluster to use SSH key B through CAPI
- Attempt to upgrade the cluster with EKS-A using SSH key B → this is rejected, and if we use SSH key A, the upgrade proceeds but continues to use SSH key A
Anything else we need to know?:
Environment:
- EKS Anywhere Release: v0.20.11
- EKS Distro Release:
What happened:
The issue occurred because we lost the SSH key that was originally used for cluster provisioning.
What you expected to happen:
I updated the SSH keys on the CAPI side, and the swap was successful. However, when I try to initiate a cluster upgrade with EKS-A, it treats the SSH key as immutable and continues to enforce the old key. During the upgrade, EKS-A still uses the old SSH key. I expected the cluster to use the new key, but EKS-A appears to block this change.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment: