Allow for wildcard of the namespace in the IAM condition for namespaces with a pattern

[RaJiska]

What would you like to be added:
Reference to this issue: #58

We'd like to have wildcard implemented for incomplete namespaces, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::xxx:oidc-provider/oidc.eks.ap-southeast-1.amazonaws.com/id/xxx"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ap-southeast-1.amazonaws.com/id/xxx:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "oidc.eks.ap-southeast-1.amazonaws.com/id/xxx:sub": [
                        "system:serviceaccount:some-namespace-*:my-sa"
                    ]
                }
            }
        }
    ]
}

In the current state of things, implementing it the way shown above will result in a failure to assume the role, with an error message "An unknown error occurred" reported via Cloudtrails.

Why is this needed:
Our namespace model follows a pattern with which such a feature would allow us to specifically grant permissions on SAs in namespaces following this pattern.

[mglaserna]

Up for this functionality also

[federicopires]

+1 We have a similar scenario where we launch ephemeral envs with unique namespaces.

[federicopires]

Just want to add that we also tried system:serviceaccount:*:my-sa and it's not working for us it seems either. We are using KOPS to create the role, which looks correct (Fixed in kubernetes/kops#16027).

[krisdock]

we also have a use case for this +1

[sethfduke]

I could also really use this functionality. Not being able to use wildcard patterns in the namespace has completely prevented my organization from moving forward with transition to this feature from the standard IRSA method. With multiple teams deploying to the cluster, often to feature branches that live in their own namespaces, expecting them to first update their EKS Pod Identities with the new namespace first is a massive inconvenience.

[rafilkmp3]

Would be nice have this to support ephemeral envs

[riannselegar]

We need that either. +1!

[aswindevs]

Needs this feature for ephemeral environments

[crodriguezcondec]

+1 need this feature for ephemeral environments

[project0]

I have the same problem, namespaces are generated randomly for ephemeral environments and cannot be defined and associated before.