Terraform version: 0.15.4
Kubernetes provider version: 2.3.0 (latest at the time of the bug)
Kubernetes version: 1.21.1
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
}
}
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.
No panic
terraform plan after the namespace has been created, without modifying the Terraform configurationThe plan should not change anything.
The plan show a removing of the namespace's kubernetes.io/metadata.name label.
The cluster is running on Scaleway Kapsule.
I have kubernetes_secret configured in the same file but it does not have this issue.
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.
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, …)?
@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:
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.
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.
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!
Wow, I did not think I would see a fix so quickly :flushed:
Thanks!
And thanks for the information about sensitive data in logs
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?
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.
Actually, don't worry about testing yet; I'm expecting this PR to fix the issue. https://github.com/hashicorp/terraform-provider-kubernetes/pull/1298
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
Most helpful comment
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.