Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slack webhooks (cloudflare_notification_policy_webhooks) are replaced on every apply #2767

Closed
2 tasks done
jtthackery opened this issue Sep 15, 2023 · 6 comments
Closed
2 tasks done
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/needs-information Indicates an issue needs more information in order to work on it.

Comments

@jtthackery
Copy link

Confirmation

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

Terraform and Cloudflare provider version

❯ terraform -v
Terraform v1.5.4
on darwin_arm64
+ provider registry.terraform.io/cloudflare/cloudflare v4.14.0

Affected resource(s)

  • cloudflare_notification_policy_webhooks

Terraform configuration files

resource "cloudflare_notification_policy_webhooks" "slack_webhook" {
  account_id = local.account_id
  name       = "Slack Webhook"
  url        = local.slack_url
}

Link to debug output

Cannot provide due to company policy

Panic output

No response

Expected output

I expect that running terraform apply or plan when there have been no code changes produces a No changes. Your infrastructure matches the configuration. message.

Actual output

Instead I see a "must be replaced" message, and an apply does actually replace the resource (I see the test "Hello World!" message in slack every time). Additionally, all cloudflare_notification_policy resources that reference this webhook are updated as part each apply. We've had to restructure our terraform project to reduce the alert noise from this issue.

  # cloudflare_notification_policy_webhooks.slack_webhook must be replaced
-/+ resource "cloudflare_notification_policy_webhooks" "slack_webhook" {
      ~ created_at   = "2023-09-15T17:00:43Z" -> (known after apply)
      ~ id           = "<redacted>" -> (known after apply)
      + last_failure = (known after apply)
      + last_success = (known after apply)
        name         = "Slack Webhook"
      ~ type         = "slack" -> (known after apply)
      # Warning: this attribute value will be marked as sensitive and will not
      # display in UI output after applying this change.
      ~ url          = (sensitive value) # forces replacement
        # (1 unchanged attribute hidden)
    }

Steps to reproduce

  1. Define a cloudflare_notification_policy_webhooks resource with a slack webhook.
  2. Create the resource with terraform apply
  3. Observe the test message in slack to confirm the webhook has been successfully created.
  4. Run terraform plan and observe that the plan output includes the replacement of this resource.
  5. Run terraform apply to replace the resource, observe a second test message to confirm the resource has been replaced. (Alternatively, you can check the webhook ID to confirm the replacement.)

Additional factoids

No response

References

No response

@jtthackery jtthackery added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 15, 2023
@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot added triage/needs-information Indicates an issue needs more information in order to work on it. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Sep 15, 2023
@github-actions
Copy link
Contributor

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.

@Nmishin
Copy link
Contributor

Nmishin commented Sep 17, 2023

Hi @jtthackery, this is not a bug, this is a feature :)
This happens because slack webhook url contain secret inside url, and cloudflare automatically get it from url and put to the secret field (you can see how it works when you configure webhook via UI).
For example, my url looks like 'https://hooks.slack.com/services/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'

and the last one part - this is secret, you need to adв it to the secret parameter of terraform config:

resource "cloudflare_notification_policy_webhooks" "example" {
  account_id = "<account_id>"
  name       = "Slack Webhook"
  url        = "https://hooks.slack.com/services/T03LAEUSP2Q/B05SQ412L8K"
  secret     = "p4nV4tEqdHtqkxSULts0kgFK"
}

@jtthackery
Copy link
Author

@Nmishin Thanks for the explanation, maybe this is a docs issue then? The behavior is confusing as it seems there are two valid ways to create a slack webhook, and neither are fully documented.

Option 1:

  • provide the full slack webhook URL in the url attribute (including the secret part). Cloudflare does the split for you, but this results in the "issue".

Option 2:

  • manually split the slack webhook URL into two parts and supply both the secret and url attributes, avoids the issue

I'll note that there's a 3rd, invalid option: forget to split the URL into two parts but define both the secret and url attributes, which returns an error from the API (as expected), but the error message suggests that slack webhooks should only use the url attribute:

│ Error: error connecting webhooks destination Slack Webhook: malformed request: url formatting error: Invalid Parameter: Secret. Value was: Unexpected secret field. Secret is a part of the URL for a slack webhook

I think this could be "solved" with a docs update that clarifies slack webhooks should be defined with both fields, and the secret should be truncated from the webhook URL. I'm happy to make a PR for that update if you think it's appropriate. Thanks!

@Nmishin
Copy link
Contributor

Nmishin commented Sep 19, 2023

i think we need to ask guru @jacobbednarz

for my humble opinion - we need to describe this behaviour in the docs.

@ngayerie
Copy link

Hi @Nmishin
I've raised a PR to add a note in the docs: cloudflare/cloudflare-docs#10832

@jacobbednarz jacobbednarz closed this as not planned Won't fix, can't repro, duplicate, stale Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/needs-information Indicates an issue needs more information in order to work on it.
Projects
None yet
Development

No branches or pull requests

4 participants