kubernetes_config_map_v1_data remove changes if already exists?

[HFR1994]

Terraform Version, Provider Version and Kubernetes Version

Terraform v1.6.3
on darwin_arm64
provider registry.terraform.io/gavinbunney/kubectl v1.14.0
provider registry.terraform.io/hashicorp/aws v5.23.1
provider registry.terraform.io/hashicorp/helm v2.11.0
provider registry.terraform.io/hashicorp/http v3.4.0
provider registry.terraform.io/hashicorp/kubernetes v2.23.0
provider registry.terraform.io/hashicorp/null v3.2.1
provider registry.terraform.io/hashicorp/random v3.5.1
provider registry.terraform.io/hashicorp/time v0.9.1
provider registry.terraform.io/hashicorp/tls v4.0.4

Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2", GitCommit:"7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647", GitTreeState:"clean", BuildDate:"2023-05-17T14:20:07Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"26+", GitVersion:"v1.26.10-eks-4f4795d", GitCommit:"164dfb62db432c0b28a1fced3956256af68533b6", GitTreeState:"clean", BuildDate:"2023-10-20T23:21:27Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}

Affected Resource(s)

• kubernetes_config_map_v1_data

Terraform Configuration Files

data "kubernetes_config_map_v1" "aws_auth_configmap" {
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
}

resource "kubernetes_config_map_v1_data" "aws_auth_configmap" {
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }
  data = {
    mapRoles = yamlencode(concat([
      {
        rolearn : aws_iam_role.gmsa_ec2.arn,
        username : "system:node:{{EC2PrivateDNSName}}",
        groups : [
          "system:masters"
        ]
      }
    ], yamldecode(data.kubernetes_config_map_v1.aws_auth_configmap.data.mapRoles)))
  }

  force = true

  depends_on = [
    aws_iam_role.gmsa_ec2
  ]
}

Steps to Reproduce

1. terraform plan -out=plan.cache
2. terraform apply plan.cache --> First run, the role map still doesn't exist
3. terraform plan -out=plan.cache
4. terraform apply plan.cache --> Second run, the role map does exist

Expected Behavior

Terraform detects that is in sync with the current config_map and does not attempt to remove it

Actual Behavior

Terraform is trying to remove the role mapping that was added on the previous iteration based on the execution plan:

# module.eks[0].kubernetes_config_map_v1.aws_auth_configmap will be updated in-place
resource "kubernetes_config_map_v1" "aws_auth_configmap" {
      ~ data        = {
          ~ "mapRoles" = <<-EOT
                - "groups":
                    -   - "system:masters"
                -  "rolearn": "arn:aws:iam::<<aws_account>>:role/<<role_added_on_previous_run>>"
                -  "username": "system:node:{{EC2PrivateDNSName}}"
              ...
              EOT
            # (1 unchanged element hidden)
        }
        id          = "kube-system/aws-auth"
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

# module.gmsa-enroll[0].kubernetes_config_map_v1_data.aws_auth_configmap will be updated in-place
  ~ resource "kubernetes_config_map_v1_data" "aws_auth_configmap" {
      ~ data          = {
          - "mapRoles" = <<-EOT
                - "groups":
                  - "system:masters"
                  "rolearn": "arn:aws:iam::<<aws_account>>:role/<<role_added_on_previous_run>>"
                  "username": "system:node:{{EC2PrivateDNSName}}"
                ...
            EOT
        } -> (known after apply)
        id            = "kube-system/aws-auth"
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Important Factoids

I'm working on a Add_On module so the original config_map is created when the EKS cluster originally creates using kubernetes_config_map_v1, this module is called conditionally (and also independtly) so if you decide to add it you won't need to reference the Terraform resource only the original EKS name. That is why makes sense that after the second execution tries to revert to the original state, but shouldn't the kubernetes_config_map_v1_data change it back?

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[arybolovlev]

Hi @HFR1994,

I am not able to reproduce this issue. Could you please provide a simplified version of the code that reproduces this issue?

Thanks.

[iBrandyJackson]

Without further feedback to proceed, we're closing this ticket to maintain clarity in our issue tracker. This closure is purely procedural; we're still interested in addressing your concerns.

Should this issue persist or if you have additional information to share, please feel free to open a new ticket. Your contributions are valuable to us, and we're keen to assist wherever possible.