`cloudflare_zero_trust_access_identity_provider` keeps trying to update `config.client_secret` when there are no changes

[F21]

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 v1.9.8 on linux_amd64

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

Affected resource(s)

cloudflare_zero_trust_access_identity_provider

Terraform configuration files

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.45"
    }
  }
  required_version = "~> 1.9"
}

provider "cloudflare" {
  api_token = "REDACTED"
}

resource "cloudflare_zero_trust_access_identity_provider" "test" {
  account_id = "REDACTED"
  name       = "TEST"
  type       = "azureAD"

  config {
    client_id      = "123456"
    client_secret  = "123456"
    directory_id   = "123456"
  }
}

Link to debug output

https://gist.github.com/F21/25df3576a43e4f48c548879da9ba493f

Panic output

No response

Expected output

The cloudflare_zero_trust_access_identity_provider.config.client_secret should not be updated when the secret has not changed.

Actual output

Terraform attempts to update cloudflare_zero_trust_access_identity_provider.config.client_secret even when the client_secret has not changed.

Steps to reproduce

1. Run terraform apply and accept.
2. Run terraform apply or terraform plan and see that it tries to update cloudflare_zero_trust_access_identity_provider.config.client_secret even when the secret is the same.

Additional factoids

This is because the client_secret is stored as CONCEALED_STRING in the state. Therefore, unless the client_secret is literally CONCEALED_STRING, terraform will always thing it has changed.

References

No response

[github-actions[bot]]

Terraform debug log detected :white_check_mark:

[github-actions[bot]]

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.

[JonasBak]

We're also experiencing this problem, and see the same problematic log (also when building the provider from master today):

.config[0].client_secret: planned value cty.StringVal("**********************************") does not match config value cty.StringVal("1234567890") nor prior value cty.StringVal("")

Relevant code: https://github.com/cloudflare/terraform-provider-cloudflare/blob/86cd8749ed6948889800a691dc7d038868c36a7c/internal/sdkv2provider/schema_cloudflare_access_identity_provider.go#L92

What's interesting is that we didn't see this 3 days ago, running the same version, so I suspect there might have been some API change that triggered this.

Changing the StateFunc for the client_secret schema to simply return "" fixes this issue, but recreates an issue we experienced last week where changing the input to the client_secret field didn't trigger an update to the resource or upstream configuration.

[allwalte]

Reading the linked PR above, that seems to have been closed, saying that it's actually fixed in the upcoming 4.47 (via https://github.com/cloudflare/terraform-provider-cloudflare/pull/4419/). So does that mean this issue is resolved in 4.47? Additionally, I'm getting the same issue not just with the identity provider secret, but with cloudflared tunnel secrets and device posture integrations secrets. Should I add logs here, or file a separate issue, or would the above fix cover those too? (I don't think so, from looking at the PR though; it seems to be specific to the id provider?)