Optional data in kubernetes secret causes destroy on every apply

[innovate-invent]

Terraform Version, Provider Version and Kubernetes Version

Terraform v0.14.6
+ provider registry.terraform.io/brinkmanlab/galaxy v0.2.11
+ provider registry.terraform.io/hashicorp/aws v3.28.0
+ provider registry.terraform.io/hashicorp/external v2.0.0
+ provider registry.terraform.io/hashicorp/kubernetes v2.0.2
+ provider registry.terraform.io/hashicorp/local v2.0.0
+ provider registry.terraform.io/hashicorp/null v3.0.0
+ provider registry.terraform.io/hashicorp/random v3.0.1
+ provider registry.terraform.io/hashicorp/template v2.2.0
+ provider registry.terraform.io/hashicorp/time v0.6.0

Kubernetes version: 1.9

Affected Resource(s)

kubernetes_secret

Terraform Configuration Files

resource "kubernetes_secret" "kube_dashboard_key_holder" {
  metadata {
    name      = "kubernetes-dashboard-key-holder"
    namespace = kubernetes_namespace.kube_dashboard.metadata.0.name
    labels = {
      "k8s-app" = "kubernetes-dashboard"
    }
  }
  type = "Opaque"
}

Steps to Reproduce

1. terraform apply --> create secret
2. app modifies secret
3. terraform apply --> tries to recreate secret

Expected Behavior

Secret left unmodified

Actual Behavior

   ~ resource "kubernetes_secret" "kube_dashboard_key_holder" {
      ~ data = (sensitive value)
        id   = "kubernetes-dashboard/kubernetes-dashboard-key-holder"
        # (1 unchanged attribute hidden)

      ~ metadata {
          ~ labels           = {
              + "k8s-app" = "kubernetes-dashboard"
            }
            name             = "kubernetes-dashboard-key-holder"
            # (5 unchanged attributes hidden)
        }
    }

Important Factoids

kuberentes dashboard modifies the secret after it has been created

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

[redeux]

Hi @innovate-invent! Have you tried using Terraform's ignore_changes lifecycle meta-argument?

[innovate-invent]

That is a reasonable workaround but should not be required. A check needs to be added to the provider to differentiate if the optional input has been specified and is empty or is unspecified and should not force a value on the deployment.

[alexsomesan]

@innovate-invent I am not sure I understand your issue clearly. You mention in the issue description that the kubernetes_secret resource is getting destroyed and re-created. However, the plan output you shared illustrates an in-place update of the resource.

Also, can you please clarify what changes are performed to the secret when you say: "2. app modifies secret"?

This part is important as out-side modifications is something Terraform by default tries to guard against. This is the reason why @redeux suggested above that you use the ignore_changes attribute. I think you might be misinterpreting the meaning of "optional" as a characteristic of attributes in Terraform. It only designates the fact that they are allowed to be absent from configuration and not that they should be completely ignored by Terraform. Although somewhat briefly, it is explained here: https://www.terraform.io/docs/extend/schemas/schema-behaviors.html#optional

[innovate-invent]

The issue is that the data field is optional. When omitted, I expect terraform to not track the value of that field. It currently overwrites the value with a null on apply. I wrote a draft fix to illustrate the issue: #1171

[innovate-invent]

@alexsomesan asked that I elaborate on why I need this functionality in my PR.

This is required for the kubernetes dashboard. I translated the recommended dashboard deployment from k8s documents to terraform: https://github.com/brinkmanlab/cloud_recipes/blob/master/aws/dashboard.tf
You can see the original document here: https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

You will need to inquire with the Kubernetes dev team as to why they chose to use secrets in this way.

[alexsomesan]

@innovate-invent I think I understand the issue better now. It looks to me like that secret is only used as an output from the Dashboard app to communicate the authentication key that it generated. In this case, I really don't see a need for that secret to be managed as a resource, and you could just make it a datasource. This of course only works if the Dashboard is actually able to create the secret if it's not present.
If that doesn't work, or even if it does but you want a simpler alternative, the initial solution that @redeux suggested is a very valid one. Just make use of ignore_changes as needed to suppress those diffs. This is indeed a canonical way to solve this type of issues in Terraform and fully endorsed by us.

[innovate-invent]

Are you sure the code is handling the 'optional=true,computed=true' aspect of the schema correctly? The code does not check if the data is unset and tries to assign a null value to the data.

When optional=true you need to use the GetOk function rather than Get to fetch it.

[github-actions]

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

[innovate-invent]

bump

[iBrandyJackson]

Please use ignore_changes as needed to suppress those diffs. This is indeed a canonical way to solve this type of issues in Terraform and fully endorsed by us.