Containers-roadmap: [EKS] [request]: aws-auth configmap rolearn wildcard support

[atheiman]

Tell us about your request
Support basic glob wildcard rolearn matching for aws-auth configmap that controls iam role eks auth.

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?
Trying to avoid hardcoding _lots_ of IAM role arns into the aws-auth configmap. It would be useful if basic glob wildcard matching worked in the rolearn field of each role mapping:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - groups: [AcmeCorp]
      rolearn: arn:aws:iam::111122223333:role/teams/*
      username: AcmeCorp

Are you currently working around this issue?
Individually specifying each rolearn and updating the configmap everytime these roles change:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - groups: [AcmeCorp]
      rolearn: arn:aws:iam::111122223333:role/teams/SomeTeam
      username: SomeTeam
    - groups: [AcmeCorp]
      rolearn: arn:aws:iam::111122223333:role/teams/AnotherTeam
      username: AnotherTeam

Additional context
I tried using a * on a working rolearn field and the role became unable to authenticate with the api server. EKS version (Im not sure what component handles this auth delegation, so I dont know of another relevant version to check for that):

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T14:25:20Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.10-eks-5ac0f1", GitCommit:"5ac0f1d9ab2c254ea2b0ce3534fd72932094c6e1", GitTreeState:"clean", BuildDate:"2019-08-20T22:39:46Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}

[atheiman]

I'd be happy to try implementing this, but im not sure if the code for this is open sourced. If it is, maybe I could be pointed to it?

[riosje]

Ey guys, i need too this one feature.

[sidewinder12s]

I think with AWS SSO Roles this is sorta more required, as the AWS SSO roles appear to have randomly generated characters at the end of the role ARN which makes granting access to AWS SSO Roles painful.

[nxtof]

Anyone found a workaround for this with AWS SSO?

[underrun]

This would be really helpful - any way the community can contribute?

[underrun]

to clarify - path support would be really helpful for user defined roles...

there is a workaround for SSO @nxtof and @sidewinder12s -

    {
      rolearn  = "arn:aws:iam::<account_id>:role/AWSReservedSSO_AdministratorAccess_<some_random_string>"
      username = "aws-sso-admin"
      groups   = ["system:masters"]
    }

The issue is that paths aren't supported in the arn for roles - so really you get internal wildcards for free kinda? it's the leaf role name that you list after role/ - also that random string isn't randomized all the time - its created by SSO in the an account with permission set provisioned roles. it won't change after it's provisioned... but i'm not sure about what happens if role are edited and reprovisioned - haven't tried it.

there's also a side note in the docs that's kind of a little about this: https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting_iam.html#security-iam-troubleshoot-ConfigMap

doesn't really mention SSO but i've verified it working as specified above.

[nxtof]

After a few tests, I can confirm that <some_random_string> does _not_ change every time the SSO permission set is re-provisioned in an account (e.g. permission change). I would guess it is randomly generated if you remove and then re-add it to the account, which should be rare but is still subject to happen.

Nevertheless, wildcard support would definitely be useful