[Feature Request] EKS Access not supported with TEAM for AWS IAM Identity Center

[amanone]

Hello 👋

We've been evaluating the AWS TEAMs (Temporary Elevated Access Management) for integration into our AWS IAM Identity Center environment. However, it seems impossible to use it for EKS access, as every time when Temporary Elevated Access is granted there is a AWS role with unique ID created in the target AWS account. It's not possible to use any kind of regex for AWS role trust relationship or inside EKS aws-auth ConfigMap.

Is there a workaround to predict the AWS role with the unique ID or another way to configure the temporary access for EKS?

Thanks!

[tawoyinfa]

Hi @amanone. The AWS role is created by AWS IAM Identity Center in the account once TEAM is used to approve and grant the access. TEAM doesnt have any control on the ID of the AWS role created in the account by IAM Identity Center.

[trickyearlobe]

I also have this issue

There was a PR by @logandavies181 which would have addressed this which which was merged and then reverted.
It worked by allowing wildcards in the role name.

kubernetes-sigs/aws-iam-authenticator#416

Maybe @jaypipes @nckturner could chat with the AWS TEAM team and figure out a way forward for the randomish (but regexable) just-in-time SSO role names that AWS TEAM produces

[logandavies181]

The code is still there's it's just behind a feature flag and AWS said they wouldn't enable it. When I raised it initially it had full wildcard support (actually arnLike) but I was asked to scale it back to just SSO roles.

According to this comment they're cooking something up, so maybe @jku8 can ensure that it has interop with this feature.

Or use some of the code that would have solved this two years ago ¯\_(ツ)_/¯

[trickyearlobe]

Thanks @logandavies181 I was seriously considering using your original wildcard PR but I found a simple workaround for this specific issue, so I can afford to wait till AWS decide what they are going to do to make all the parts fit together.

The fix is basically to create an empty dummy "SSO" group which never gets any users assigned and use that to attach the permission set(s) to the target account(s).

One that's done, there is a permanent IAM role which can be used in the AWS-AUTH config map. When users elevate their permissions, they get the same IAM role, and it's perfectly repeatable.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 7 days it will automatically be closed.