feat: Add support for managing aws-auth configmap using new kubernetes_config_map_v1_data resource

[bryantbiggs]

Description

• Add support for managing aws-auth configmap using new kubernetes_config_map_v1_data resource
  • New variables have been added to support enabling/disabling the configmap management by the module, to add additional IAM role ARNs, roles, users, and accounts to the configmap
  • A kubernetes_config_map is added with a variable var.create_aws_auth_configmap for scenarios where the configmap does not exist and will need to be created (i.e. - using self managed node groups only)

Motivation and Context

• Closes Would you mind clarifying how to add additional Roles/Users to the AWS AUTH during EKS provisioning #1901 and solves a lot of heartache for many 😅
• This new resource properly handles patching an existing configmap resource without any additional hacks. This brings back comparable functionality that was available in v17.x which unfortunately had various issues for supporting (including the use of the forked http provider). I have validated all examples and this is working beautifully thanks to Add kubernetes_config_map_v1_data resource hashicorp/terraform-provider-kubernetes#1671

Breaking Changes

• No

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[bryantbiggs]

eh, need to take a deeper look at this again

[bryantbiggs]

ok good to go - had to add in a kubernetes_config_map to create a configmap when one doesn't exist

[antonbabenko]

This PR is included in version 18.20.0 🎉

[james-callahan]

What was the reason to rely on the aws cli instead of the aws_eks_cluster_auth data source?

e.g.

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_id
}

provider "kubernetes" {
  host                   = module.eks.cluster_endpoint
  cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)  
  token                  = data.aws_eks_cluster_auth.cluster.token
  load_config_file       = false
}

[bryantbiggs]

its up to users to choose when they are using the module, but in the examples we are using exec because that is what is recommended https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#exec-plugins

[FernandoMiguel]

if you have a fargate only cluster, you will also have to create the map , just like the self managed groups

[bryantbiggs]

if you have a fargate only cluster, you will also have to create the map , just like the self managed groups

No, when using Fargate profiles and EKS managed node groups, the EKS service will automatically update the configmap to ensure the roles are added. Self-managed node groups are the only ones who do not update the configmap automatically

[FernandoMiguel]

thanks for clarifying that. was about to spin up a cluster to test this.

[tanvp112]

if you have a fargate only cluster, you will also have to create the map , just like the self managed groups

No, when using Fargate profiles and EKS self managed node groups, the EKS service will automatically update the configmap to ensure the roles are added. Self-managed node groups are the only ones who do not update the configmap automatically

@bryantbiggs , you meant to say "when using Fargate profiles and EKS managed node groups..."?

[FernandoMiguel]

Ehe, nice catch.
Anyway, I tested this yesterday with a fargate only cluster and worked as expected.
Was only hit with another annoying issue about the kubernets provider not being able to use data sources, so I had to change it to exec aws instead. Very annoying.

[bryantbiggs]

@tanvp112 thanks for the catch - yes EKS managed node groups. updated the comment above so as to not confuse anyone who lands here

[jallen-frb]

How does this new method work for multiple EKS clusters?

[FernandoMiguel]

How does this new method work for multiple EKS clusters?

Each cluster has its own configmap

[stevo-f3]

Would it make sense to update https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/UPGRADE-18.0.md? It currently has:

Support for managing aws-auth configmap has been removed.

[tomer-ds]

@stevo-f3 your comment is spot on!! Super confusing having the central documentation for the upgrade give essentially false misleading information. Wasted a large portion of my day attempting to figure out what the variables I see do and why they are supposedly unsupported even though they're not really

[stevo-f3]

@bryantbiggs thanks for reintroducing management of aws-auth ConfigMap. Would it make sense to also re-introduce same labels as before in v17 https://github.com/terraform-aws-modules/terraform-aws-eks/blob/v17.24.0/aws_auth.tf#L69-L75 ?

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.