ignore_changes not working for worker script secret_text_binding

Confirmation

• [X] My issue isn't already found on the issue tracker.
• [X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.2.4 Cloudflare provider v3.18.0

Affected resource(s)

cloudflare_worker_script

Terraform configuration files

resource "cloudflare_worker_script" "worker" {
  name    = "worker"
  content = file("${path.module}/code/build/index.js")

  lifecycle {
    ignore_changes = [secret_text_binding]
  }
}

Debug output

2022-08-25T12:01:59.658+0200 [INFO]  Terraform version: 1.2.4
2022-08-25T12:01:59.658+0200 [DEBUG] using github.com/hashicorp/go-tfe v1.0.0
2022-08-25T12:01:59.658+0200 [DEBUG] using github.com/hashicorp/hcl/v2 v2.12.0
2022-08-25T12:01:59.658+0200 [DEBUG] using github.com/hashicorp/terraform-config-inspect v0.0.0-20210209133302-4fd17a0faac2
2022-08-25T12:01:59.658+0200 [DEBUG] using github.com/hashicorp/terraform-svchost v0.0.0-20200729002733-f050f53b9734
2022-08-25T12:01:59.658+0200 [DEBUG] using github.com/zclconf/go-cty v1.10.0
2022-08-25T12:01:59.659+0200 [INFO]  Go runtime version: go1.18.1
2022-08-25T12:01:59.659+0200 [INFO]  CLI args: []string{"terraform", "apply", "-target=module.staging_cloudflare_frontend_worker"}
2022-08-25T12:01:59.659+0200 [DEBUG] Attempting to open CLI config file: /home/utay/.terraformrc
2022-08-25T12:01:59.659+0200 [INFO]  Loading CLI configuration from /home/utay/.terraformrc
2022-08-25T12:01:59.659+0200 [DEBUG] Explicit provider installation configuration is set
2022-08-25T12:01:59.659+0200 [INFO]  CLI command args: []string{"apply", "-target=module.staging_cloudflare_frontend_worker"}
[...]
2022-08-25T12:02:01.860+0200 [DEBUG] created provider logger: level=debug
[...]
2022-08-25T12:02:08.079+0200 [DEBUG] Starting graph walk: walkApply
2022-08-25T12:02:08.080+0200 [DEBUG] created provider logger: level=debug
2022-08-25T12:02:08.080+0200 [INFO]  provider: configuring client automatic mTLS
2022-08-25T12:02:08.093+0200 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.18.0/linux_amd64/terraform-provider-cloudflare_v3.18.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.18.0/linux_amd64/terraform-provider-cloudflare_v3.18.0]
2022-08-25T12:02:08.093+0200 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.18.0/linux_amd64/terraform-provider-cloudflare_v3.18.0 pid=969571
2022-08-25T12:02:08.093+0200 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.18.0/linux_amd64/terraform-provider-cloudflare_v3.18.0
2022-08-25T12:02:08.097+0200 [INFO]  provider.terraform-provider-cloudflare_v3.18.0: configuring server automatic mTLS: timestamp=2022-08-25T12:02:08.097+0200
2022-08-25T12:02:08.111+0200 [DEBUG] provider: using plugin: version=5
2022-08-25T12:02:08.111+0200 [DEBUG] provider.terraform-provider-cloudflare_v3.18.0: plugin address: address=/tmp/plugin3555448642 network=unix timestamp=2022-08-25T12:02:08.111+0200
2022-08-25T12:02:08.139+0200 [WARN]  ValidateProviderConfig from "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" changed the config value, but that value is unused
2022-08-25T12:02:08.139+0200 [INFO]  provider.terraform-provider-cloudflare_v3.18.0: using specified account id 9b08113c6661bb49f270bb5ee40554c8 in Cloudflare provider: tf_req_id=81901d11-2917-3807-17b3-1fd32338bdb4 tf_rpc=Configure @caller=github.com/cloudflare/terraform-provider-cloudflare/internal/provider/provider.go:301 @module=cloudflare tf_provider_addr=registry.terraform.io/cloudflare/cloudflare timestamp=2022-08-25T12:02:08.139+0200
module.staging_cloudflare_frontend_worker.cloudflare_worker_script.frontend_worker: Modifying... [id=frontend-worker-staging]
2022-08-25T12:02:08.141+0200 [INFO]  Starting apply for module.staging_cloudflare_frontend_worker.cloudflare_worker_script.frontend_worker
2022-08-25T12:02:08.141+0200 [DEBUG] module.staging_cloudflare_frontend_worker.cloudflare_worker_script.frontend_worker: applying the planned Update change
2022-08-25T12:02:08.142+0200 [INFO]  provider.terraform-provider-cloudflare_v3.18.0: Updating Cloudflare Worker Script from struct: &{ZoneID: ScriptName:frontend-worker-staging}: tf_resource_type=cloudflare_worker_script @module=cloudflare tf_provider_addr=registry.terraform.io/cloudflare/cloudflare tf_req_id=f97f4887-8558-2fc2-4b60-4d976fd5a2fa tf_rpc=ApplyResourceChange @caller=github.com/cloudflare/terraform-provider-cloudflare/internal/provider/resource_cloudflare_worker_script.go:243 timestamp=2022-08-25T12:02:08.142+0200
2022-08-25T12:02:08.143+0200 [ERROR] vertex "module.staging_cloudflare_frontend_worker.cloudflare_worker_script.frontend_worker" error: error updating worker script: Text for binding "SECRET_NAME" cannot be empty
╷
│ Error: error updating worker script: Text for binding "SECRET_NAME" cannot be empty
│
│   with module.staging_cloudflare_frontend_worker.cloudflare_worker_script.frontend_worker,
│   on ../modules/cloudflare/frontend-worker/main.tf line 1, in resource "cloudflare_worker_script" "frontend_worker":
│    1: resource "cloudflare_worker_script" "frontend_worker" {
│
╵
[...]
-----------------------------------------------------
2022-08-25T12:02:08.340+0200 [DEBUG] [aws-sdk-go] {}
2022-08-25T12:02:08.341+0200 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-08-25T12:02:08.343+0200 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.18.0/linux_amd64/terraform-provider-cloudflare_v3.18.0 pid=969571
2022-08-25T12:02:08.343+0200 [DEBUG] provider: plugin exited

Panic output

No response

Expected output

I expect terraform apply to ignore the manually added secret and the worker to be updated in that case

Actual output

│ Error: error updating worker script: Text for binding "SECRET_NAME" cannot be empty

Steps to reproduce

1. Run terraform apply to create the worker
2. Add an encrypted environment variable in the Cloudflare console for this worker
3. Update the worker js script locally
4. Run terraform apply to update the script --> Plan runs just fine but I get an error on apply because there's no value for the manually added secret (which is expected because secret_text_binding is in ignore_changes)

As a workaround, I also tried to set a dummy secret_text_binding with "SECRET_NAME" and then change it manually in the Cloudflare console but when I re-applied (step 4.), it replaced the secret value with the dummy value.

Additional factoids

No response

References

No response

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.

This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

I have added the terraform debug logs

looks like the debug logs are missing the HTTP interactions. can you please paste it, untruncated please? feel free to redact sensitive details but leave the rest.

i'm also unable to replicate the issue you're explaining here. you should:

1. create the resource with a dummy version and lifecycle action
2. update the UI
3. changes shouldn't apply

(Note: I don't recommend this approach at all)

ignore_changes is a terraform primitive and not something we control; it essentially prevents any updates on the attribute when it is applied.

Sorry for the delay here @jacobbednarz and thank you for your answer.

i'm also unable to replicate the issue you're explaining here. you should:

1. create the resource with a dummy version and lifecycle action
2. update the UI
3. changes shouldn't apply

I believe step 3. is not correct, changes won't show for this resource on terraform plan but the dummy version in code will still replace the secret text binding in Cloudflare on terraform apply. You can easily reproduce it by following exactly the steps you mentioned.

But now I'm not sure whether this is a bug in the Cloudflare provider or in Terraform's ignore_changes, what do you think?

(Note: I don't recommend this approach at all)

Agreed it's not ideal but we really want to avoid having secrets in clear text in the Terraform state and I don't think this can be done in a different way :/

want to avoid having secrets in clear text in the Terraform state and I don't think this can be done in a different way :/

the less bad (still not great) way to handle this is through something like local-exec (or remote) to fetch the credentials as these don't end up stored in state. in the past, i've used this approach to make calls to vault and other config files on the system without writing them to state.

Indeed we could fetch credentials from our vault within local-exec but we would still save the secret in state if we use a secret_text_binding. To avoid this, we would have to replace cloudflare_worker_script with a raw PUT worker request in local-exec but it kind of defeats the purpose of Terraform.

The ideal for us is still the dummy value that should be ignored on apply by ignore_changes but isn't

It seems to work as expected if also adding the plain_text_binding to be ignored, eg. ignore_changes = [secret_text_binding, plain_text_binding]

Right! In our case, we'd like to ignore only secret_text_binding :)

Marking this issue as stale due to 90 days of inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 7 days it will automatically be closed. Maintainers can also remove the lifecycle/stale label. 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. Thank you!

This issue was closed because it has been stalled for 7 days with no activity.