IAM controller leaves on orphaned role when patching .spec.name

[demikl]

Describe the bug

When I change the .spec.name field in an already synced roles.iam resource, a new role with the updated name is effectively created, but the old IAM role is not deleted.

Steps to reproduce

1. create a valid roles.iam resource with .spec.name = foo
2. wait for it to be successfully reconciled (the IAM role foo should now exist)
3. patch the resource by modifying .spec.name = bar
4. wait for it to be successfully reconciled (the IAM role bar should now exist)
5. the IAM role foo still exists but is not managed anymore by the ACK IAM controller

Expected outcome

The old IAM role should be deleted, as if the role.iam resource has been deleted.

Environment

• Kubernetes version

1.30

• Using EKS (yes/no), if so version?

yes : eks.24

• AWS service targeted (S3, RDS, etc.)

IAM controller, v1.3.13

[michaelhtm]

Hey @demikl, thanks for bringing this to our attention. Looks like it needs a custom code on update..we'll schedule this in our backlog!

[michaelhtm]

Hey @demikl, it looks like custom code would not be enough to solve this issue, as there wouldn't be a way to retrieve old the role name after it's changed. What do you think if we make the role name immutable at the API level instead?

Another solution could be storing the old role name in the annotation, so when there's a diff, we can delete the old one and create a new one..
cc @a-hilaly @gfrey

[demikl]

It makes sense to me for this field to be immutable. Combined with GitOps reconciliers like FluxCD, it would need to delete then recreate the K8S ack ressource, and that's absolutely acceptable. Thanks. Le lun. 10 févr. 2025, 21:18, Michael Tewoldemedhin < ***@***.***> a écrit :

…

Hey @demikl <https://github.com/demikl>, it looks like custom code would not be enough to solve this issue, as there wouldn't be a way to retrieve old the role name after it's changed. What do you think if we make the role name immutable at the API level instead? Another solution could be storing the old role name in the annotation, so when there's a diff, we can delete the old one and create a new one.. cc @a-hilaly <https://github.com/a-hilaly> @gfrey <https://github.com/gfrey> — Reply to this email directly, view it on GitHub <#2268 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL6WXTDIAZXRGSEWG64ZL32PECRHAVCNFSM6AAAAABWTZ3KFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBZGE2DEMRTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rushmash91]

Hey @demikl,

Thank you for the detailed description for the issue!

This is a known behavior in the ACK IAM controller because the Name field in a RoleName is Unique.

Since, the Name field serves as a unique identifier, any changes to these fields are treated by IAM as the creation of a new resource record set rather than an update to an existing one, leaving a orphaned role.

https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html

I agree Name should be made immutable.

We'll have a patch for all the controllers and move to CEL-Based Immutability this month. So, that immutable checks are handled at the admission layer.

As @michaelhtm mentioned, we'll schedule this in our backlog after the patch above is merged!