[EKS] [request]: MapGroups in ConfigMap

[vitorgou]

Tell us about your request In order to grant access to a group of users to an EKS cluster, I'd like to map a whole IAM group in the ConfigMap. Similar to "mapRoles" and "mapUsers", I'd like to use something like "mapGroups" and inform a group arn.

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? In order to map a group of users to grant access to the EKS cluster, with current configMap specifications, the way to do it is to map each individual user by editing the configMap with "mapUsers".

Are you currently working around this issue? The current workaround for this is to create a IAM policy that allows the group to assume a role that has access to the cluster and is mapped in the configMap. Then, assume the role before accessing the cluster with a command like: aws sts assume-role --role-arn arn:aws:iam::123456789:role/EKS-test-role --role-session-name

Additional context Please let me know if this is a valid feature request. Maybe there's something here I'm missing, but I think it should be ok to map a IAM group arn to grant access to the EKS cluster.

[mjrmyke]

+1

I was looking up documentation online for this same scenario, and happened to find this issue. Our engineers are put into groups for organizational purposes, it would be great to be able to leverage that organization in EKS.

[rtkgjacobs]

+1

[christopherhein]

Cross linking the issue on the authenticator - https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/176

Thanks for filing this. Technically the difficulty with this is IAM groups don't support the get-caller-identity request with the AWS IAM Authenticator uses to validate users on the control plane. Would be good to explore other options to make this easier.

[avandijk42]

+1

This would be great way to organize our team's permissions.

[onkymykiss1]

+1

[wstewartii]

I'm currently using https://github.com/ygrene/iam-eks-user-mapper as a workaround to this problem. It would be great if we could get this feature implemented.

[omerh]

@wstewartii I was thinking to use this as well, but doesn't it kill the API call limit to aws?

[1juandiaz]

+1

[MKrupA5]

1. Attach a policy to the Group that grants permission to call sts:AssumeRole on the desired Role:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "123", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::123456789:role/<assigned_Eks_role>" ] } ] } 2) Also, attach a Trust Policy on the Role. The sample policy (below) trusts any user in the account, but they would also need sts:AssumeRole permissions (above) to assume the role.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789:root" }, "Action": "sts:AssumeRole" } ] } 3. Add the role arn to the configMap as below.

• rolearn: arn:aws:iam::123456789:role/ username: system:* groups: - system:masters

4. Save the file and apply the configMap.
5. Now test with another user which belongs to the group.

[anderson-dan-w]

nit: any chance someone can go in and format those json blobs?

[pmatv]

As a workaround, I've made a simple script for mapping IAM group members to RBAC group: https://gist.github.com/pmatv/f059d11fa431d7141f60455ae6243608

[iamsudip]

@pmatv I'm getting a 404

[pmatv]

@iamsudip I've corrected the URL, thanks

[vupv]

So can we use mapGroups in the new release?

[philomory]

I'd really love to see this. The workarounds with assumed roles are really not very satisfactory, for three reasons:

1. A person can be in more than one group and thus get the union of the permissions of those groups, but you can only assume one role at a time; so if you need permissions from multiple roles, you need to keep switching between them (or the administrator need to make a third role, just for you, that incorporates the permissions of both of your roles simultaneously).
2. Once someone has set up all of the kubeconfig contexts using aws eks update-kubeconfig, if they later get granted additional permissions, you can't just add them to a new group and go on your way, they'll have to redo all their kubeconfig setup with their new roles. If you've got a lot of clusters, this is a pain in the neck.
3. If you've got a lot of different roles, it makes it harder to document for your team members; instead of writing, for example, "to set up the context for this cluster, run aws eks update-kubeconfig --region us-west-2 --cluster-name example", you have to write, "to set up the context for this cluster, first figure out what role you're allowed to use by checking the following table; then, run aws eks update-kubeconfig --region us-west-2 --cluster-name example --role-arn ${ARN from the table}".

I recognize that the technical implementation of this might be more complicated than it is for users and roles, but I feel like this is something that needs to be addressed at some point by Amazon nonetheless. Workarounds and ad-hoc scripts just feel bad here.

[guygrip]

Hey! after a long research on this topic, we've decided to write a blog post covering this issue. In the blog post, we cover most of the possible solutions for this and share the solution that we find to work best.

Enabling AWS IAM Group Access to an EKS Cluster Using RBAC

[chrisipa]

+1

[leandronsp]

+1

[blowfishpro]

It seems like other AWS services are moving in the direction of using session tags for this purpose. But the IAM authenticator relies on the public STS API which does not expose session tags.