Terraform-provider-kubernetes: ConfigMap Documentation

[charles-d-burton]

I think the documentation for the configmap could be a bit better. The current example is highly simplistic and does not explain how the configmap works with the data. For instance do the map keys get passed as part of the data? When I run the following configmap it doesn't work whereas if I run it using kubectl it works fine. That's largely because it's not clear how to use the configmap and how to format the data that's passed into it. In the example it's mapping a single value where a configmap can have complex data.

Terraform Version

v0.11.10

Affected Resource(s)

kubernetes_config_map

Terraform Configuration Files

resource "kubernetes_config_map" "iam_nodes_config_map" {
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }

  data {
    mapRoles = <<ROLES
|
  - rolearn: ${var.instance_role}
    username: system:node:{{EC2PrivateDNSName}}
    groups:
     - system:bootstrappers
     - system:nodes
    ROLES
}

Expected Behavior

It to apply the configmap to the kubernetes cluster

Actual Behavior

It applied but didn't seem to work correctly

Steps to Reproduce

1. terraform apply

Important Factoids

I think this is just a documentation thing. The documentation has an example for a very simple configmap but I can't figure out how to apply a more complex configmap. It's also not apparent as to how the keys relate to the data.

[pdecat]

Have you checked with kubectl get configmap -n kube-system aws-auth the actual content of the config map?

It's probably a formatting issue.
Here's a more complex example that I use in some setups:

data "template_file" "ip-masq-agent" {
  # Note: the HEREDOC syntax adds a trailing newline that breaks YAML processing for ConfigMap
  template = <<EOF
nonMasqueradeCIDRs:
$${non_masquerade_cidrs}
masqLinkLocal: false
resyncInterval: 60s
EOF

  vars {
    # Do not masquerade for local traffic (local pods CIDR and local subnet CIDR)
    # This allows traffic to other private CIDRs to be accepted
    non_masquerade_cidrs = "${
      join("\n",
        formatlist("  - %s",
            list(var.cluster_cidr),
        )
      )
    }"
  }
}

resource "kubernetes_config_map" "ip-masq-agent" {
  metadata {
    name      = "ip-masq-agent"
    namespace = "${lookup(module.namespaces_system.names_map, "kube-system")}"
  }

  data {
    # Remove trailing newline that breaks YAML processing for ConfigMap
    config = "${chomp(data.template_file.ip-masq-agent.rendered)}"
  }
}

[pdecat]

Also, I believe you shouldn't need the | with that syntax.

[zakkg3]

I applied the same aws-auth with the file from the aws documentation, then used your code and imported the configmap. then when i run the plan using "landscape" i get this:

~ kubernetes_config_map.iam_nodes_config_map
    data.mapRoles:   -- rolearn: arn:aws:iam::034087141678:role/eks-node-dev
                     -  username: system:node:{{EC2PrivateDNSName}}
                     -  groups:
                     -    - system:bootstrappers
                     -    - system:nodes
                     +  - rolearn: arn:aws:iam::034087141678:role/eks-node-dev
                     +    username: system:node:{{EC2PrivateDNSName}}
                     +    groups:
                     +     - system:bootstrappers
                     +     - system:nodes

makes no sense for me, cant see any difference 🗡
/edit there is a few spaces more in the new yaml so I played a little bit with indentation and find the solution, at least now terraform see the config map the same as the one I created from the aws documentation file. here is the code:

resource "kubernetes_config_map" "iam_nodes_config_map" {
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }

  data {
    mapRoles = <<ROLES
- rolearn: ${aws_iam_role.node.arn}
  username: system:node:{{EC2PrivateDNSName}}
  groups:
    - system:bootstrappers
    - system:nodes
ROLES
}
}

[rastakajakwanna]

Just in case you end up here (like me) while

1. trying to resolve migration from terraform-aws-eks module version which is using local-exec kubectl to new version calling kubernetes module directly
2. tf apply complains about Error: configmaps "aws-auth" already exists
3. tf import fails with Error: Get http://localhost/api/v1/namespaces/kube-system/configmaps/aws-auth: dial tcp [::1]:80: connect: connection refused

Fix:

1. change temporarily your provider to use load_config_file = true and config_path ="your_kubeconf"
2. tf import kube-config/aws_auth
3. change your temporary provider configuration back to dynamic data
4. apply drift
5. aws eks update-kubeconfig # you know the drill
   Problem fixed.

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!