[EKS]: allow EKS Pod Identity association to accept a glob for the service account name (my-sa-*)

[jcooklin]

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 What do you want us to build?

Enhance the EKS create-pod-identity-association API to accept a glob for the service account. There are cases where the service account is dynamically provided and will have the form my-sa-. I would like the ability to define the serviceAccount name in this case as "my-sa-*" in the create-pod-identity-association call.

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? This will enable EKS pod identity to be used in cases where the service account name is being managed by another controller on the cluster.

Are you currently working around this issue? We can continue to use IRSA with a trust policy that includes a condition and StringLike operator and statement like "${ISSUER_HOSTPATH}:sub": "system:serviceaccount:default:my-sa-*"

[ssup2]

Please allow wildcards to be applied to namespaces as well.

[joshuabaird]

The ability to use a glob for the namespace would allow us to fully migrate from IRSA to Pod Identities.

[evandam]

Agreed with everything here, it would be super useful for us as well. We have more or less ephemeral namespaces that don't have predictable names where pod identity associations can be created in advance, so we're not able to leverage this unfortunately.

[danielloader]

It might be out of scope but since the controller is in cluster to do the evaluations...

Maybe an additional solution is optionally targeting all namespaces that have a label defined matching a value.

I don't know about the internals of the project to the viability of this model but a mixture of namespace by name, namespace with globbing, and namespace matching label(s) would be quite powerful for more on demand use.

[rafilkmp3]

We need this too

[dims]

fyi code is here now - https://github.com/aws/eks-pod-identity-agent 🙏🏾