When module eks uses only self managed group, it means that no aws-auth exists (only managed-group can generate automatically) .

Nodes can't connect to EKS, when no aws-auth exists in cluster, finally job can't execute becuase no nodes connected to cluster (jobs can't connect becuase aws-auth not exists )

Solution would be to add new option to create config-map with aws-auth before job execution .

Describe the Bug

Getting Error: The config map "aws-auth" does not exist

with module.eks.module.eks_auth.kubernetes_config_map_v1_data.aws_auth[0]
on .terraform/modules/eks.eks_auth/main.tf line 42, in resource "kubernetes_config_map_v1_data" "aws_auth":
resource "kubernetes_config_map_v1_data" "aws_auth" {

Note: ConfigMap is present in my cluster

Expected Behavior

It would update the config map.

Steps to Reproduce the Problem

1. Apply the module with the following code

module "eks_auth" {
  source    = "aidanmelen/eks-auth/aws"
  eks       = module.eks
  map_roles = var.map_roles
}

How to get around this issue?

Downgrade to 0.9.0

I am trying to create a new EKS using terraform-eks official module, and to ease the pain of creating new aws-auth configmap I was trying to use this module. But since I have multiple clusters in my kube-config, this module updates the configmap of my current-context and not the newly created EKS. Is this the expected behavior?

While version 'v18.20.0' of the terraform eks module brings back the management of the aws-auth configmap, it makes use of a local-exec to retrieve the auth token for the internal kubernetes provider and this addition prevents its use on Terraform Cloud. I was wondering if you'd be willing to keep this project alive as it definitely helps folks who can't use the new EKS module feature. Thanks

Describe the Bug

When applying with what I think is the correct configuration:

module "sandbox_cluster" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "18.11.0"
  cluster_name    = "sandbox"
  cluster_version = "1.21"

  vpc_id = module.development_vpc.vpc_id

  eks_managed_node_groups = {
    sandbox = {
      min_size     = 1
      max_size     = 5
      desired_size = 1

      security_group_name = "sandbox_worker_sg"

      instance_types = ["t3.large"]
      capacity_type  = "SPOT"
      labels = {
        Environment = "development"
      }
      taints = {
      }
    }
  }
}

data "aws_eks_cluster" "sandbox_cluster" {
  name = module.sandbox_cluster.cluster_id
}

data "aws_eks_cluster_auth" "sandbox_cluster_auth" {
  name = module.sandbox_cluster.cluster_id
}

provider "kubernetes" {
  alias                  = "sandbox_kubernetes"
  host                   = data.aws_eks_cluster.sandbox_cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.sandbox_cluster.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.sandbox_cluster_auth.token
}

module "eks_auth" {
  source = "aidanmelen/eks-auth/aws"
  eks    = module.sandbox_cluster

  map_roles = [
    {
      rolearn  = var.kubectl_access_role_arn
      username = "kubernetes_master"
      groups   = ["system:masters"]
    }
  ]
}

Returns the following error:

│ Error: Post "http://localhost/api/v1/namespaces/kube-system/serviceaccounts": dial tcp [::1]:80: connect: connection refused
│ 
│   with module.development.module.eks_auth.kubernetes_service_account_v1.aws_auth_init,
│   on .terraform/modules/development.eks_auth/main.tf line 47, in resource "kubernetes_service_account_v1" "aws_auth_init":
│   47: resource "kubernetes_service_account_v1" "aws_auth_init" {
│ 

Expected Behavior

For the aws_auth configmap to change

Actual Behavior

Fails at this point. Tried adding configuration for the kubernetes provider. I did add that in in an attempt to get this working so it's possible there's something in state that's preventing this from working or something to do with networking as it's not giving an actual IP that it's trying to connect to.

Steps to Reproduce the Problem

1. Setup a .tf file with the above tf code
2. run terraform init and terraform apply.

You'll need to create a variable for the arn that you're trying to add into the configmap.

Describe the Bug

The data.aws_eks_cluster_auth.cluster.token can expire causing the kubernetes provider to timeout and fail.

Expected Behavior

The kubenetes job always runs to completion before the data.aws_eks_cluster_auth.cluster.token expires.

Actual Behavior

sometimes the token expires and the terraform apply fails.

Steps to Reproduce the Problem

1. run the complete example.
2. most of the time it runs to completion before the token timeout.
3. but sometimes it doesn't and the apply will fail.

Fixes

https://github.com/aidanmelen/terraform-aws-eks-auth/issues/17

Proposed Changes

• Allow the user to specify a custom ca certificate, but fallback to the default if not provided

Describe the Bug

Thanks so much for this project! I've been following your git comments on the EKS terraform module repo and really appreciate you pulling this out.

Currently, I am unable to perform this operation in the same terraform execution where the EKS cluster is created. Are you expecting this module to only perform updates to already existing clusters, or do I just have a bug? Hashicorp notes here that interpolation can cause issues: https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#stacking-with-managed-kubernetes-cluster-resources

Expected Behavior

1. create an EKS cluster
2. Use this module to modify config map
3. cluster works with config map changes

Actual Behavior

1. EKS cluster is created
2. this module begins to execute
3. Receive "Unauthorized!" error
4. Run again, and execution succeeds

Steps to Reproduce the Problem I'm using a setup that is identical to the examples here.

You suggest that users should migrate to version 18.20 of the official EKS module which supports handling the configmap directly in the cluster creation.

However, I ran into a problem. I use your other module, terraform-kubernetes-rbac, to set up all of the RBAC cluster roles and permissions, and then I use the terraform-aws-eks-auth module to map the AWS users to those roles. This is all after initial cluster creation.

The EKS module does not have the ability to create RBAC groups, so would I use the new aws_auth_roles feature to map to groups that do not exist? Then apply the RBAC module?

https://github.com/aidanmelen/terraform-aws-eks-auth/blob/9b2468d731e6b580a42c892ac9942b996b3b7499/main.tf#L18

It would be useful to be able to provide a custom ca, for those of us in a corporate network which uses a man in the middle, which provides a different cert to the client

Fixes

Proposed Changes

• replace kubernetes_job with kubectl_manifest. This simplifies the module quite a bit. The provider handles create or patch functionality in a single resource. What's more, since the provider uses the k8s golang libraries, this solution also run remote operations in Terraform Cloud or in CI/CD.
• overhauled documentation/examples with .terraform-docs templates.
• added terraform-aws-modules/http to ensure the cluster is ACTIVE before the kubectl_manifest runs.
• created test/mock for hacky rapid testing.

Upgrade Notes

You will see the kubernetes_job get replaced with the kubectl_manifest when upgrading from v0.8.3. The apply will automatically recreate the aws-auth configmap.