EKS [request]: Allow better automation of creation of access entries for SSO users

[smarshie]

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
I'd like the access entry creation mechanism for EKS clusters to allow automation of entries for SSO-federated users where the applied permission set name is known but the resultant role in the account has an unpredictable ARN.

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?
The recent change to EKS to allow access entries via the console/API seems to be flawed in the sense that there is no clear mechanism to grant access to users who are authenticated with SSO via IAM Identity Center. In particular it seems that automation of access entry-creation has not been properly considered in the solution. Roles that are created when permission sets are applied to accounts are not predictably named, so it is not obvious what principal to grant access to when automating with tools such as Cloud Formation and Terraform. ARNs of SSO roles have to be looked up manually and added manually via the console or API.

When allowing such users to assume roles in general, one has to use trust policies with an ArnLike condition and a wildcard entry to account for the unpredictable naming of roles, but principal ARNs for access entries have to be single ARNs with no wildcards. The chosen approach seems intensely limiting and poorly thought-through.

Are you currently working around this issue?
Create additional roles which users who have already assumed federated roles need to assume in order to gain visibility to cluster resources via the console. This also means including inline policies added to permission sets allowing these users to assume roles in the first place.

[mikestef9]

Hi @smarshie see the end of my comment on the original access entry issue #185 (comment)

I'm going to close this as a duplicate given #474 is tracking the improvements for AWS Identity Center. I also renamed that issue to make it more clear.