[EKS][Feature Request]: Automatically remove IAM Roles from “Access Entries”

[ctav4]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request We wish EKS to remove from “Access Entries” the IAM Role of Managed Node Group that do not exist anymore.

Which service(s) is this request for? EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? In the past we created one Managed Node Group in our EKS cluster. The worker nodes (EC2s) of that Managed Node Group, could join successfully the EKS cluster using the EKS API method. At some point in time, we decided to delete this Managed Node Group from our EKS cluster. The deletion of Managed Node Group from EKS was completed with success however, the IAM Role used by that Managed Node Group was never removed from the “Access Entries”. Later, when we re-provisioned the same Managed Node Group we could verify that couldn't be created successfully due to the fact that the worker nodes could not join the EKS cluster. After manual deletion of old IAM Role from “Access Entries” the worker nodes could successfully register. The IAM Roles are added automatically by AWS into “Access Entries”. We expected that removal should be also done automatically.

Are you currently working around this issue? How are you currently solving this problem? We delete manually the IAM Role from “Access Entries".

Additional context Anything else we should know? We opened an internal ticket to AWS Support with ID 172780501600814.

[mikestef9]

Did you delete the original IAM role and re-create it with the same name? EKS access entries validates against the principal ID of the role ARN (vs config map which string matched). That could be what happened here. If you did that, then yes you would need to manually delete the access entry.

[ctav4]

Hi @mikestef9. Yes, we deleted the original IAM Role and re-created it with the same name. We didn't have this behavior when we use CONFIG_MAP as authentication mode and due to that we were expecting that when using API as authentication mode it would do this deletion automatically.

[mikestef9]

See the docs callout here starting with "If you ever delete the IAM principal with this ARN..."