Namespace well-known label "kubernetes.io/metadata.name" always in plan

[sambonbonne]

Terraform Version, Provider Version and Kubernetes Version

Terraform version: 0.15.4
Kubernetes provider version: 2.3.0 (latest at the time of the bug)
Kubernetes version: 1.21.1

Affected Resource(s)

• kubernetes_namespace

Terraform Configuration Files

variable "app_name" {
  type = string
  description = "Application name"
}

variable "environment" {
  type = string
  description = "Application environment"
}

locals {
  kubernetes_default_labels = {
    "app.kubernetes.io/name" = var.app_name
    "app.kubernetes.io/instance" = "${var.app_name}-${var.environment}"
    "app.kubernetes.io/managed-by" = "terraform"
  }
}

resource "kubernetes_namespace" "application_namespace" {
  metadata {
    name = var.kubeconfig.namespace
    labels = local.kubernetes_default_labels
  }
}

Debug Output

The given configuration is part of a bigger module so the trace is long. I am trying to remove sensitive information of logs before publishing.

Panic Output

No panic

Steps to Reproduce

1. Create a Kubernetes namespace with Terraform
2. Run terraform plan after the namespace has been created, without modifying the Terraform configuration

Expected Behavior

The plan should not change anything.

Actual Behavior

The plan show a removing of the namespace's kubernetes.io/metadata.name label.

Important Factoids

The cluster is running on Scaleway Kapsule.

I have kubernetes_secret configured in the same file but it does not have this issue.

References

I searched but did not found other issues.

The provider documentation tells well-known labels are recognized by Terraform, but it seems it's not the case here.

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

[sambonbonne]

Maybe this is a stupid question but is there a way to produce TF_LOG=debug logs without sensitive informations (authorization tokens, state's bucket name, …)?

[dak1n1]

@sambonbonne I don't think it's possible to omit sensitive information in the debug logs. I just checked the bug tracker on Terraform Core to see what they recommend, and it looks like they recommend manually reviewing the logs to ensure there's no sensitive data. There is also the option to encrypt the data using the public hashicorp GPG key. But maybe we can just narrow the scope of the debug logs instead, to simplify things.

TF_LOG_PROVIDER=true will show just the provider related logs. Though this will still need some review to ensure nothing sensitive is displayed.

I'd be more interested in a reproducer though -- I wasn't able to reproduce using the example in the original post. Here's the config file I tried:

https://gist.githubusercontent.com/dak1n1/52b723cc777b84e9ef1da54c4809832c/raw/a5e7dc237c78d26f0ee4bce85e62fac0a68bdade/gistfile1.txt

I wonder if you can get it to reproduce the issue in a small config file like that one? That will make it easier to ensure there's no sensitive data being revealed.

[jrhouston]

Looks like this label was missing from the well known list – although I couldn't reproduce this either, I suspect the addition of this label might be cluster dependent. Have opened the PR above to fix.

[dak1n1]

To reproduce this, I used the same config file as in my gist above, and manually did a kubectl edit on the namespace to add kubernetes.io/metadata.name: test. When I did that, it would always show up in the diff when using kubernetes provider version 2.3.0. But when I use the provider version from PR #1295, the diff is resolved!

[sambonbonne]

Wow, I did not think I would see a fix so quickly 😳
Thanks!

And thanks for the information about sensitive data in logs

[sambonbonne]

EDIT: after running a simple terraform apply, it's fixed and the label is still in the namespace, sorry for the inconvenience.

I tried the 2.3.1 Kubernetes provider (by changing the version and running terraform init -upgrade) but I still see the kubernetes.io/metadata.name change in terraform plan. I tried a terraform apply -update but the plan still shows label removing.

Did I miss a step?

[dak1n1]

Can you try running terraform version to confirm which version of the provider is in use? Also, if you turn on debug logging, it will show you the name of the binary in use. It should look something like [DEBUG] plugin.terraform-provider-kubernetes_v2.3.1_x5. That can help identify the more difficult cases where you might accidentally be using a different version in a sub-module, since provider versions aren't inherited into sub-modules. Though it sounds like you did everything right, as far as upgrading with terraform init -upgrade.

[dak1n1]

Actually, don't worry about testing yet; I'm expecting this PR to fix the issue. #1298

[sambonbonne]

Just in case, I ran the terraform version and it seems the provider's version is OK:

Terraform v0.15.5
on linux_amd64
+ provider registry.terraform.io/hashicorp/kubernetes v2.3.1

[dak1n1]

Version 2.3.2 has been released, which has the fix that I believe will solve the issue. Let us know if you're still having trouble with it. Thanks!

[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.