Changing a Cloudflare Worker Secret results in a delete; then create

[JamieSinn]

Confirmation

• This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
• I have searched the issue tracker and my issue isn't already found.
• I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

Terraform v1.9.5
on darwin_arm64

• provider registry.terraform.io/cloudflare/cloudflare v4.43.0

Affected resource(s)

cloudflare_worker_secret

Terraform configuration files

Can't provide full configuration - but assume that there is a worker - with an already managed secret - changing that secret results in a destruction; and then creation of a new secret. Instead of updating within the next execution.
This is the plan output.


-/+ resource "cloudflare_worker_secret" "worker-secrets" {
      ~ id          = "59775269137828e79d859bb835a3b1f2" -> (known after apply)
        name        = "SECRET_NAME"
      ~ secret_text = (sensitive value) # forces replacement
        # (2 unchanged attributes hidden)
    }

Example:

variable "worker_script_name" {
  type = string
  description = "CF Worker Script Name - as defined in wrangler.toml"
}

variable "secrets" {
  type = map(string)
  description = "Map of AWS Secret Values to Cloudflare Env Vars"
}


variable "cloudflare_account_id" {
  type = string
  description = "Cloudflare Account Id"
}
variable "environment" {
  type = string
  description = "Environment"
}

locals {
  worker_script_env = "${var.worker_script_name}-${var.environment}"
}


data "aws_secretsmanager_secret" "secrets" {
  for_each = toset(keys(var.secrets))
  name = each.value
}

data "aws_secretsmanager_secret_version" "secrets" {
  for_each  = data.aws_secretsmanager_secret.secrets
  secret_id = each.value.id
}

resource "cloudflare_worker_secret" "worker-secrets" {
  for_each    = var.secrets
  account_id  = var.cloudflare_account_id
  name        = each.value
  script_name = local.worker_script_env
  secret_text = data.aws_secretsmanager_secret_version.secrets[each.key].secret_string
}

Link to debug output

Unable to link due to security.

Panic output

No crash/panic.

Expected output

I would expect that the provider not destroy; and rather recognize that the value just needed to be updated/set again.

The cloudflare API supports the PUT endpoint; and the provider should not destroy the resource.

https://developers.cloudflare.com/api/operations/namespace-worker-put-script-secrets

Actual output

Resource was destroyed in one operation; which resulted in multiple deployments for a worker; one of which had the wrong (ie - none) value for the secret as it was deleted.

Steps to reproduce

1. Create a worker with a secret (either through terraform or wrangler.)
2. Manage that secret through terraform; either creating a new one, or updating the existing one.
3. Change the value in the terraform resource for the secret; and the plan will result in destroying; then creating a new version of the worker deployments with the secret removed; and then another with the secret re-added.

Additional factoids

No response

References

No response

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[github-actions]

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.

[jacobbednarz]

changing the text value of the resource is expected to force creation of a new terraform resource. there is no way to retrieve the secret value once it has after creation to determine if the value has changed or if it should be inline replaced. instead, you may want to look into the create_before_destroy or a two phase swap of secrets.

side note: including a graph with three lines and no context is of no use to helping describe the problem here 🙂

[JamieSinn]

The graph was referring to the deployments above it - showing the extra deployments created by changing the value.

I would expect that the provider never "destroys" the cloudflare secret unless the resource itself is deleted; only updates it via put - even in a case where managing multiple secrets - that it would only ever create a single deployment.

Maybe it's better to suggest something like https://developers.cloudflare.com/workers/wrangler/commands/#secretbulk get added to Cloudflare-Go? and then downstream to TF? That way you can change n secrets without multiple calls?

[jacobbednarz]

I would expect that the provider never "destroys" the cloudflare secret unless the resource itself is deleted; only updates it via put - even in a case where managing multiple secrets - that it would only ever create a single deployment.

as i mentioned above, this isn't possible to differentiate in all scenarios hence why the replacement causes a new resource to be created. if you don't want this behaviour, you'll need to use the meta-arguments or a two phase apply.

Maybe it's better to suggest something like https://developers.cloudflare.com/workers/wrangler/commands/#secretbulk get added to Cloudflare-Go? and then downstream to TF? That way you can change n secrets without multiple calls?

terraform operates on a per resource operation; using bulk endpoints requires additional parsing and overhead that we don't want to capture in the provider. this is why we have individual endpoints that support all the CRUD lifecycle operations.

[JamieSinn]

How would moving to a create-before-destroy method change this? It would still result in the secret being removed from the worker would it not?

[JamieSinn]

Tested this - using create-before-destroy actually is not at all what should happen - it creates/updates the secret correctly - then removes it entirely from the worker. This is absolutely not proper - and caused an outage.