cloudflare_zero_trust_tunnel_cloudflared cannot be imported

[chris-pinola-rf]

trafficstars

Confirmation

• [x] 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.
• [x] I have searched the issue tracker and my issue isn't already found.
• [x] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version

$ terraform -version
Terraform v1.11.3
on darwin_arm64
+ provider registry.terraform.io/cloudflare/cloudflare v5.3.0

Affected resource(s)

• cloudflare_zero_trust_tunnel_cloudflared

Terraform configuration files

import {
  to = cloudflare_zero_trust_tunnel_cloudflared.tunnel
  id = "{account_id}/{tunnel_id}"
}

resource "cloudflare_zero_trust_tunnel_cloudflared" "tunnel" {
  account_id    = "..."
  name          = "..."
  tunnel_secret = "..."
  config_src    = "cloudflare"
}

Link to debug output

Not comfortable doing this publicly

Panic output

No response

Expected output

The tunnel resource to be imported without needing replacement.

Actual output

The provider wants to destroy and recreate the tunnel resource because it detects a change in the config_src property:

  # cloudflare_zero_trust_tunnel_cloudflared.tunnel must be replaced
  # (imported from "{account_id}/{tunnel_id}")
  # Warning: this will destroy the imported resource
-/+ resource "cloudflare_zero_trust_tunnel_cloudflared" "tunnel" {
...
      + config_src        = "cloudflare" # forces replacement

Steps to reproduce

1. Create a cloudflare_tunnel resource with version 4.52.0 of the provider with config_src set to "cloudflare"
2. Remove the cloudflare_tunnel resource from the Terraform state
3. Upgrade provider to 5.3.0
4. Run terraform plan with the HCL from above (import {} block + cloudflare_zero_trust_tunnel_cloudflared)

Additional factoids

Was expecting this bug to be fixed in version 5.3.0 from #5432 but unfortunately it still persists.

References

Related issues:

• #5363
• #5450
• #5432

[jhutchings1]

Thanks for letting us know. @musa-cf will take a look

[Invincibear]

edit: I upgraded my cloudflare provider and it resolved this issue. Thanks!

@jhutchings1 @musa-cf thanks guys, looks like the root cause was identified in https://github.com/cloudflare/terraform-provider-cloudflare/issues/5363. Recreating the tunnel on every terraform apply means I can't roll this out to production

[jhutchings1]

edit: I upgraded my cloudflare provider and it resolved this issue. Thanks!

@Invincibear thanks, so good to close this one? Give me a shout if that's no longer a problem.

[Invincibear]

@jhutchings1 yeah I'd say close it

[chris-pinola-rf]

@jhutchings1 please reopen this issue. I can still replicate the bug exactly as originally described even on the latest version of the provider (v5.4.0). Specifically, attempting to import (via HCL import {} block) a tunnel still results in the provider wanting to destroy and recreate it due to perceived drift on the config_src attribute:

 + config_src        = "cloudflare" # forces replacement

Also, the bug referenced above that was used as justification for closing this (#5363) was resolved by #5432, which I called out in the description:

Additional factoids

Was expecting this bug to be fixed in version 5.3.0 from #5432 but unfortunately it still persists.

From the debug output of terraform plan (see below) I can see "remote_config": true come back from the API which I'm guessing is not getting mapped properly on to the string values used by the config_src attribute.

Debug output

2025-05-12T14:44:32.399-0400 [DEBUG] provider.terraform-provider-cloudflare_v5.4.0: 
GET /client/v4/accounts/.../cfd_tunnel/7678da45-dafc-435d-8b72-56a40ded57d5 HTTP/1.1
> x-stainless-lang: Terraform
> x-stainless-os: MacOS
> x-stainless-arch: arm64
> x-stainless-runtime: terraform-plugin-framework
> authorization: [redacted]
> accept: application/json
> x-stainless-retry-count: 0
> user-agent: terraform-provider-cloudflare/5.4.0 terraform-plugin-framework/1.14.1 terraform/1.11.4
> x-stainless-package-version: 5.4.0
> x-stainless-runtime-version: 1.14.1: tf_req_id=2fdfd7a4-648e-4ae3-fd7b-1d7e99aee9f7 tf_resource_type=cloudflare_zero_trust_tunnel_cloudflared tf_rpc=ReadResource @caller=github.com/cloudflare/terraform-provider-cloudflare/internal/logging/logging.go:64 @module=cloudflare tf_provider_addr=registry.terraform.io/cloudflare/cloudflare timestamp=2025-05-12T14:44:32.398-0400
2025-05-12T14:44:32.866-0400 [DEBUG] provider.terraform-provider-cloudflare_v5.4.0: 
< HTTP/2.0 200 OK
< api-version: 2025-05-12
< date: Mon, 12 May 2025 18:44:32 GMT
< cf-cache-status: DYNAMIC
< vary: Accept-Encoding
< set-cookie: __cflb=...; SameSite=Lax; path=/; expires=Mon, 12-May-25 21:14:33 GMT; HttpOnly
< set-cookie: __cf_bm=...; path=/; expires=Mon, 12-May-25 19:14:32 GMT; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
< set-cookie: _cfuvid=...; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
< cf-auditlog-id: 0196c5d0-1c4d-72d8-936e-a93d467f252e
< server: cloudflare
< content-type: application/json
< cf-ray: 93ec1166da3ef795-EWR
<

{
    "success": true,
    "errors": [],
    "messages": [],
    "result": {
        "id": "7678da45-dafc-435d-8b72-56a40ded57d5",
        "account_tag": "...",
        "created_at": "2024-04-25T17:17:46.670056Z",
        "deleted_at": null,
        "name": "...",
        "connections": [
          "...",
        ],
        "conns_active_at": "2025-04-11T07:50:27.499161Z",
        "conns_inactive_at": null,
        "tun_type": "cfd_tunnel",
        "metadata": {},
        "status": "healthy",
        "remote_config": true
    }
}

: @caller=github.com/cloudflare/terraform-provider-cloudflare/internal/logging/logging.go:92 tf_provider_addr=registry.terraform.io/cloudflare/cloudflare tf_resource_type=cloudflare_zero_trust_tunnel_cloudflared tf_rpc=ReadResource @module=cloudflare tf_req_id=2fdfd7a4-648e-4ae3-fd7b-1d7e99aee9f7 timestamp=2025-05-12T14:44:32.865-0400

...

2025-05-12T14:44:32.893-0400 [DEBUG] provider.terraform-provider-cloudflare_v5.4.0: Detected value change between proposed new state and prior state: tf_attribute_path=config_src tf_provider_addr=registry.terraform.io/cloudflare/cloudflare tf_rpc=PlanResourceChange @module=sdk.framework tf_req_id=0c315564-96e3-38db-d7d5-8799c33c7dfd tf_resource_type=cloudflare_zero_trust_tunnel_cloudflared @caller=github.com/hashicorp/[email protected]/internal/fwserver/server_planresourcechange.go:220 timestamp=2025-05-12T14:44:32.893-0400

[jhutchings1]

We reactivated and are taking another look. Thanks!

[marwenguesmii]

Any updates on this? Thanks.

[SCSI-9]

Hi, I have also the same issue. I have config_src = "local" on API side, despite I am providing the value on thre code level it tries to recreate again. Is this issue still actual ? I guess there is no solution yet.

[jhutchings1]

We're revisiting this one and will loop back when we know more. Thank you!

[KaydeeDee]

Hi all, checking in to see if you're seeing this in the latest version.

[chris-pinola-rf]

@KaydeeDee yes, I am still able to reproduce this issue exactly as originally described on the latest version (5.8.2).

Is the Cloudflare team unable to replicate this issue? If so, I'd be happy to provide whatever additional details or context may be helpful here.

[KaydeeDee]

I've reached out to the team who works on this to reopen the prior ticket that was hoping to fix this. I'll keep you updated!

[jcsf]

Hi, can you test version 5.8.4. Just tested the following example and it worked.

resource "cloudflare_zero_trust_tunnel_cloudflared" "terraform" {
  account_id    = local.account_id
  name          = "test-import"
  config_src    = "cloudflare"
}

import{
  id = "${local.account_id}/8bea27f3-a215-41bf-a15a-511c9196e502"
  to = cloudflare_zero_trust_tunnel_cloudflared.terraform
}

[KaydeeDee]

Closing this ticket as it is no longer reproducible in the latest version - let me know if this comes up again!

[chris-pinola-rf]

Confirming that I am no longer able to replicate this bug as of v5.8.4. Thanks for the fix!