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
The current implementation only allows worker node access.
Ability to specify role/user/account mappings for group membership.
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
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_authand 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: