[EKS] [request]: EKS authentication rolearn wildcard support aka improved support for AWS Identity Center SSO

[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

[DMEvanCT]

Any update on this?

[Riyajkp]

Have a similar requirement to implement and wildcard support would make things easy. I wish this to be available soon.

[leofernandezg]

+1 we can't integrate with AWS SSO

[jlamande]

@leofernandezg

+1 we can't integrate with AWS SSO

In fact you can, but not smoothly, by declaring the IAM role (without the sso path) : https://github.com/aws/containers-roadmap/issues/474#issuecomment-721475031

[vypenguin]

The nClouds team suggested to map aws sso role directly and there is catch we need to remove /aws.sso/ like string from sso role arn that way it will work.

[geoL86]

+1 for wildcard support

[ns-mkusper]

+1 for wildcard support

[mjad-org]

+1 for wildcard support

[ghost]

+1 for wildcard support

[noaram]

+1 for wildcard support

[fboecker]

+1 for wildcard support

[brycesenz]

@underrun - To elaborate a bit on your point, if your SSO workflow is to allow access for a single AWS account, you are complete correct. And in fact, you can even programmatically access the SSO role through terraform with the following code:

data "aws_iam_roles" "admin_sso_role" {
  path_prefix = "/aws-reserved/sso.amazonaws.com/"
  name_regex = "AWSReservedSSO_AdministratorAccess_.+"
}

And in your Terraform output:

output "admin_sso_role_arn" {
  value = [
    for parts in [for arn in data.aws_iam_roles.admin_sso_role.arns : split("/", arn)] :
    format("%s/%s", parts[0], element(parts, length(parts) - 1))
  ][0]
}

That will give you an output value for admin_sso_role_arn of something like: arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:role/AWSReservedSSO_AdministratorAccess_<YOUR_SPECIFIC_RANDOM_STRING>

However, if you are using SSO from a central account, where the user then assumes a role in an associated account, then this breaks down. That is because the aws sts get-caller-identity of the user actually has a role ARN in the form of: arn:aws:sts::<YOUR_AWS_ACCOUNT_ID>:assumed-role/AWSReservedSSO_AdministratorAccess_<A_DIFFERENT_RANDOM_STRING>.

That last part is brutal for our workflow - we cannot figure out a way to programmatically figure out those assume role ARNs, which is why wildcard support would be incredible for us.

That's a very long-winded way of saying "+1 for this ticket", but I hope that the Terraform code is of value to someone.

[tachang]

However, if you are using SSO from a central account, where the user then assumes a role in an associated account, then this breaks down. That is because the aws sts get-caller-identity of the user actually has a role ARN in the form of: arn:aws:sts::<YOUR_AWS_ACCOUNT_ID>:assumed-role/AWSReservedSSO_AdministratorAccess_<A_DIFFERENT_RANDOM_STRING>.

That last part is brutal for our workflow - we cannot figure out a way to programmatically figure out those assume role ARNs, which is why wildcard support would be incredible for us.

Same here. The dynamically generated role names are annoying.

[brycesenz]

@tachang - I should actually amend my commentl; in my case my Terraform code was wrong, and I was using the SSO role from the parent organization account instead of for the account that the user was "assuming" into. So I was actually able to solve my particular use case dynamically.

I still think that the functionality described in this thread has utility though!

[sumanthkumarc]

+1 for this feature, which will make it useful for kubectl access with aws sso creds.

[willdadrummer]

+1 aws sso with kubectl would be so much easier

[neelakansha85]

This would be super useful feature especially where there are multiple EKS Clusters and AWS Accounts relying on AWS SSO for authenticating users into the Cluster.

[felipe-canopy]

Any development in this issue? The ability to some sort of a wildcard for allowing role access to EKS would be extremely useful for companies relying exclusively in AWS SSO for managing clusters (it has become a management nightmare to keep up with SSO and IAM).

[jku8]

We are currently in the design phase for a AWS native integration solution between EKS and AWS Identity Center (Formerly named AWS SSO). Any feedback or requests can be posted here.

[underrun]

We are currently in the design phase for a AWS native integration solution between EKS and AWS Identity Center (Formerly named AWS SSO). Any feedback or requests can be posted here.

this issue would still apply to workloads that need automated access to the kubernetes API and that don't use SSO. this is a common pattern and would also be made easier if we could use wildcards for mapping IAM roles to kubernetes groups.

or will the solution being designed for integrating EKS and AWS Identity Center take into account giving access to EKS clusters to automated services via IAM roles?

[nckturner]

take into account giving access to EKS clusters to automated services via IAM roles?

No, this would be Identity Center specific. Can you expand on your use case?

[underrun]

We automate deploying our software programmatically. Humans don't log into kubernetes (normally) to deploy workloads to kubernetes, instead remote processes use the kubernetes api to create and manage resources in eks.

We have multiple accounts and multiple services that could be used to manage workloads in kubernetes clusters. Currently the aws auth config map requires mapping each role that should have access by arn, but it would be nice to have more flexibility such that we could map a set of roles to a kubernetes user/group without having to enumerate each role.

There are workarounds, but they involve creating and managing assume role policies that essentially equate to kubernetes groups in iam rather than managing permissions closer to the resource via the config map.

[dm3ch]

@jku8 Is there any issue/PR or something else that would allow to track the progress of mentioned feature?

[jku8]

@dm3ch this is the correct issue to track

[Logankwb]

@jku8 Please don't rename this issue as it is not what the community has been asking for. It only solves half of the problem

[sidewinder12s]

@jku8 I'd rename this back, I think general Identity Center integration was already being tracked in a separate issue: #185

[werranik]

Any updates on this one? It's getting ridiculous that we still can't use wildard

[seungmun]

It's sad that there's been no update to this feature as it's really needed. 😥

[mikestef9]

Added some more context here https://github.com/aws/containers-roadmap/issues/185#issuecomment-1569048009

[werranik]

Thanks @mikestef9 !

[honarkhah]

+1

[justinas-b]

Hey! We have our EKS clusters spread across multiple AWS accounts and those random suffixes in AWS SSO roles are really painful for us. To overcome this, i have implemented https://github.com/justinas-b/aws-iam-authenticator-sso-wrapper utility until permissionSet names or wildcards will be supported natively.

If anyone would like to test and provide a feedback, i would really appreciate it. This tool basically monitors aws-auth configMap from it's own namespace where permissionset key is acceptable in addition to rolearn:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: aws-iam-authenticator-sso-wrapper
data:
  mapAccounts: |
    []
  mapRoles: |
    - "permissionset": "AdminRole"
      "username": "AdminRole:{{SessionName}}"
      "groups":
      - "system:masters"
    - "rolearn": "arn:aws:iam::123456789012:role/AWSReservedSSO_sre_0123456789abcdef
      "username": "SRE:{{SessionName}}"
      "groups":
      - "system:masters"
  mapUsers: |
    []

It translates that configMap to regular format and updates kube-system/aws-auth configMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapAccounts: |
    []
  mapRoles: |
    - "rolearn": "arn:aws:iam:: 123456789012:role/AWSReservedSSO_AdminRole_0123456789abcdef"
      "username": "AdminRole:{{SessionName}}"
      "groups":
      - "system:masters"
    - "rolearn": "arn:aws:iam::123456789012:role/AWSReservedSSO_sre_0123456789abcdef
      "username": "SRE:{{SessionName}}"
      "groups":
      - "system:masters"
  mapUsers: |
    []

[yebolenko]

any update on wildcard support?

[gunzy83]

It looks like this will get looked at next now that the IAM changes have been implemented in the EKS API. See the bottom of this comment: https://github.com/aws/containers-roadmap/issues/185#issuecomment-1863025784

[ayoh1]

quoting from #185 Being able to link permission sets to clusters will solve current big issue of role suffix random string in multi account

We plan to improve this UX in the future by allowing users to directly associate IAM Identity Center permission sets to EKS clusters. Follow this GitHub issue for details: EKS authentication rolearn wildcard support https://github.com/aws/containers-roadmap/issues/474.