Containers-roadmap: [EKS] [request]: MapGroups in ConfigMap

Created on 4 Feb 2019  路  13Comments  路  Source: aws/containers-roadmap

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.

EKS Proposed

Most helpful comment

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.

All 13 comments

+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.

+1

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.

+1

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

+1

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.

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

+1

  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/"
]
}
]
}
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"
}
]
}

  1. 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.

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

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

@pmatv I'm getting a 404

@iamsudip I'm corrected the URL, thanks

Was this page helpful?
0 / 5 - 0 ratings