Marking vcl backends as sensitive

[PaulRudin]

Terraform Version

terraform -v
Terraform v1.6.6
on linux_amd64
+ provider registry.terraform.io/fastly/fastly v5.6.0

Affected Fastly Terraform Resource(s)

Please list the affected resources

• fastly_service_vcl

It seems that the provider treats any fastly_service_vcl blocks as sensitive. This means that we see this sort of thing in a plan:

...
      + backend {
          # At least one attribute in this block is (or was) sensitive,
          # so its contents will not be displayed.
        }
...

This makes it quite hard to quickly determine whether your plan is correct or not. It looks like the ssl_client_cert and ssl_client_keysubproperties are treated as sensitive. I don't know if it's possible to show the remaining subproperties (or maybe this is a feature of terraform itself rather than just the provider?).

[Integralist]

👋🏻

Unfortunately, this issue is outside the control of the Fastly Terraform provider, and is something that the Terraform CLI introduced in its CLI release 1.4 😞

You'll see I've left a few comments on the following open Terraform GitHub issue thread in which I explain in more detail the problem this causes: https://github.com/hashicorp/terraform/issues/33112#issuecomment-1546858832

I also opened a similar issue on the OpenTofu issue tracker and it's something they are interested in resolving 🎉: https://github.com/opentofu/opentofu/issues/708

EDIT: Sorry @PaulRudin I've only just realised/noticed that you're already aware of that Terraform thread as you commented (and I replied to it there as well back in September). As mentioned in my reply in that thread, I am working on a rewrite of the Terraform provider (here) which (as well as fundamentally updating the provider to use HashiCorp's new/non-backwards-compatible plugin framework) replaces all uses of a TypeSet with a TypeMap. Still, that rewrite is a long way off being completed (just simply due to the sheer size of the Fastly provider itself).

[PaulRudin]

Incidentally - FWIW I'm currently using a quick and dirty script, which at least lets me see something useful

#!/usr/bin/env bash

PLANFILE=$(mktemp /tmp/plan.XXX.tfplan)
trap "rm -f ${PLANFILE}" 0 2 3 15
JSONFILE=$(mktemp /tmp/plan.XXX.json)
trap "rm -f ${JSONFILE}" 0 2 3 15
terraform plan -out=${PLANFILE}
terraform show -json ${PLANFILE} > ${JSONFILE}
readarray -t changes < <(jq --compact-output '.resource_changes[]' ${JSONFILE})
for i in "${changes[@]}"; do
    orig=$(jq --raw-output --sort-keys '.change.before|walk(if type=="array" then sort else . end)' <<< "$i")
    after=$(jq --raw-output --sort-keys '.change.after|walk(if type=="array" then sort else . end)' <<< "$i")
    sdiff <(echo "${orig}") <(echo "${after}") | colordiff | less -R
done

[jlav1n]

Great script, @PaulRudin! I adapted to my shell -- it's curious that the diff I see for my backends (with no changes on my side) is:

@Integralist Do you know if anything might have changed on the Fastly API side to cause this diff? I suspect we wouldn't see any backend diffs at all unless the API changed something with this attribute recently.

[Integralist]

@jlav1n looking at https://github.com/fastly/terraform-provider-fastly/blame/d17361cef7e20431fb1d7cadce0aa214d9127da7/fastly/block_fastly_service_backend.go#L70 it seems that was added 10 months ago but hasn't been touched since.

[jlav1n]

Ok, yeah, I see my TF state had it as 0 for some odd reason, but now it's back to null. Sorry!