Specifying iam_path causes nodes to be unable to join cluster

[DWSR]

I have issues

I'm submitting a...

• bug report
• feature request
• support request - read the FAQ first!
• kudos, thank you, warm fuzzy

What is the current behavior?

When supplying iam_path to this module, worker nodes are unable to join the cluster.

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

module "cluster" {
  source  = "terraform-aws-modules/eks/aws"
  version = "12.0.0"

  # General
  cluster_name     = module.cluster_name.name_compat
  cluster_version  = var.cluster_version
  subnets          = var.subnet_ids
  vpc_id           = var.vpc_id
  write_kubeconfig = false

  # Logging
  cluster_enabled_log_types = [
    "api",
    "audit",
    "authenticator",
    "controllerManager",
    "scheduler"
  ]

  # API Endpoint
  cluster_endpoint_private_access = true
  cluster_endpoint_public_access  = true

  # IAM
  enable_irsa = true
  # iam_path = "/foo/"
  manage_aws_auth = true

  map_roles = [
    {
      rolearn  = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/administrator"
      username = "administrator"
      groups   = ["system:masters"]
    }
  ]

  node_groups_defaults = {
    disk_size        = 64
    instance_type    = "m5.large"
    min_capacity     = 1
    desired_capacity = length(var.subnet_ids)
    max_capacity     = 10
  }

  node_groups = var.node_groups
}

What's the expected behavior?

That the nodes are able to join the cluster.

Are you able to fix this problem and submit a PR? Link here if you have already.

#894

Environment details

• Affected module version: v12.0.0
• OS: MacOS 10.15.4
• Terraform version: v0.12.25

Any other relevant info

This appears to be a bug in aws-iam-authenticator. A potential workaround is to render ARNS in the aws-auth ConfigMap without the iam_path (could use something like replace()

[dpiddockcmp]

Thank you for your report.

Would impact worker roles passed in by users too.

I've filed a "community request" in the EKS roadmap repo about this issue too. Their service creates an entry in the aws-auth ConfigMap with the full ARN which then Terraform will want to remove on the next apply. aws/containers-roadmap#926

Does not impact the module's classic workers to bug/feature in aws-auth.tf.

[serialh0bbyist]

Unfortunately, #894 causes EKS to report that the node group is degraded stating that the worker nodes do not have access to the cluster (which doesn't seem to be the case), but it's blocking any updates to the node group, i.e. scaling settings, upgrades to the node group AMI, etc. The current workaround I have places two entries in the aws_auth configmap to include the role ARN with and without the IAM path in it.

  mapRoles: |
    - "groups":
      - "system:bootstrappers"
      - "system:nodes"
      "rolearn": "arn:aws:iam::<redacted>:role/<worker role name>"
      "username": "system:node:{{EC2PrivateDNSName}}"
    - "groups":
      - "system:bootstrappers"
      - "system:nodes"
      "rolearn": "arn:aws:iam::<redacted>:role/my/iam/path/<worker role name>"
      "username": "system:node:{{EC2PrivateDNSName}}"

I think this might be a decent workaround until aws/containers-roadmap#926 is resolved.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.