Terraform-aws-eks: Allow adding new users, roles, and accounts to the configmap/aws-auth

Created on 30 Jun 2018  路  11Comments  路  Source: terraform-aws-modules/terraform-aws-eks

I have issues

Amazon's EKS access control is managed via the aws-auth configmap which allows multiple IAM users and roles (cross-account capable) to be granted group membership. The current implementation only allows worker node access, this should be configurable to allow more access control rules to be specified per the documentation: https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html

I'm submitting a

  • [ ] bug report
  • [x] feature request
  • [ ] support request

What is the current behavior

The current implementation only allows worker node access.

If this is a bug, how to reproduce? Please include a code sample

What's the expected behavior

Ability to specify role/user/account mappings for group membership.

Environment

  • Affected module version: 1.1.0
  • OS: Linux
  • Terraform version: 0.11.7

Other relevant info

Most helpful comment

Yes 100%! We need this ASAP. I was going to make a PR but haven't had time yet.

The problem is that also by default, the cluster writes config_map_aws_auth and then applies it immediately with `null_resource.configure_kubectl" and this overwrites any users or roles that have been added post cluster creation and would thus lock out those users.

Here's how I think it should look:

module "cluster_1" {
  source             = "[email protected]:terraform-aws-modules/terraform-aws-eks.git?ref=v1.2.0"
  cluster_name       = "cluster_1"
  subnets            = ["${aws_subnet.public.*.id}"]
  vpc_id             = "${aws_vpc.eks.id}"
  config_output_path = "kubeconfig"

  worker_groups = [
    {
      instance_type = "t2.medium"
      key_name      = "default"
    },
  ]

  map_roles             = [
    {
      role_arn = "${aws_iam_role.developers.arn}"
      username = "developers"
      groups = [
        "cluster-admin"
      ]
    }
  ]

  map_users             = [
    {
      user_arn = "${aws_iam_user.dave.arn}"
      username = "${aws_iam_user.dave.name}"
      groups  = [
        "system:masters"
      ]
    },
    {
      user_arn = "${aws_iam_user.steve.arn}"
      username = "${aws_iam_user.steve.name}"
      groups = [
        "system:basic-user"
      ]
    }
  ]

  map_accounts = [
    "666666666666",
    "999999999999"
  ]
}

All 11 comments

Yes 100%! We need this ASAP. I was going to make a PR but haven't had time yet.

The problem is that also by default, the cluster writes config_map_aws_auth and then applies it immediately with `null_resource.configure_kubectl" and this overwrites any users or roles that have been added post cluster creation and would thus lock out those users.

Here's how I think it should look:

module "cluster_1" {
  source             = "[email protected]:terraform-aws-modules/terraform-aws-eks.git?ref=v1.2.0"
  cluster_name       = "cluster_1"
  subnets            = ["${aws_subnet.public.*.id}"]
  vpc_id             = "${aws_vpc.eks.id}"
  config_output_path = "kubeconfig"

  worker_groups = [
    {
      instance_type = "t2.medium"
      key_name      = "default"
    },
  ]

  map_roles             = [
    {
      role_arn = "${aws_iam_role.developers.arn}"
      username = "developers"
      groups = [
        "cluster-admin"
      ]
    }
  ]

  map_users             = [
    {
      user_arn = "${aws_iam_user.dave.arn}"
      username = "${aws_iam_user.dave.name}"
      groups  = [
        "system:masters"
      ]
    },
    {
      user_arn = "${aws_iam_user.steve.arn}"
      username = "${aws_iam_user.steve.name}"
      groups = [
        "system:basic-user"
      ]
    }
  ]

  map_accounts = [
    "666666666666",
    "999999999999"
  ]
}

Hey All -

Sorry for the delay addressing this issue. I think this is a valid problem to address and I 100% appreciate the spec up front, @max-rocket-internet . I'd be happy with a PR of what you've got here but also curious if that'd work for @sdavids13 .

OK I'll make a PR next week.

In TF this is really messy though, here's an example 馃樀

This looks great to me, the only suggestion is that since the authentication is all or nothing it may make sense to group the parameters together into a map such as:

variable "aws_authentication" {
  description = "Provides the ability to set additional AWS IAM user and role permissions to access the EKS cluster."
  type        = "map"
  default     = {
    map_roles = []
    map_users = []
    map_accounts = []
  }
} 

@sdavids13 That would be tidier but I don't think it's possible:

Error: module.cluster_1.data.template_file.map_users: lookup: lookup() may only be used with flat maps, this map contains elements of type list in:

${length(lookup(var. aws_authentication, "map_users"))}

The error speaks to the right problem but just in case, is the extra space in your example relevant to the issue? :

${length(lookup(var. aws_authentication, "map_users"))}
# should be
${length(lookup(var.aws_authentication, "map_users"))}

The lookup method only works for "flat maps" i.e. nothing with nested lists or maps. But, that method is primarily used for dynamic lookups where the key is a variable. Since we have a static lookup in this can you can access the content via: var.aws_authentication["map_users"] which works for all maps. You can see an alternative example here: https://www.terraform.io/docs/configuration/interpolation.html#user-map-variables

is the extra space in your example relevant to the issue? :

I don't think so:

variable "aws_authentication" {
  type        = "map"
  default     = {
    map_users = []
  }
}

locals {
  my_var = "${length(lookup(var.aws_authentication, "map_users"))}"
}

output "test" {
  value = "${local.my_var}"
}

Produces:

Error: Error asking for user input: 1 error(s) occurred:

* local.my_var: local.my_var: lookup: lookup() may only be used with flat maps, this map contains elements of type list in:

${length(lookup(var.aws_authentication, "map_users"))}

Since we have a static lookup in this can you can access the content via: var.aws_authentication["map_users"] which works for all maps

Correct! I'll update my PR. Thanks.

Ah OK, no worries

Merged in #56

Was this page helpful?
0 / 5 - 0 ratings