This is a commentary on the way Terraform excessively marks as “sensitive” a block even though the provider is only marking a single attribute as sensitive.
The real world upshot is that managing an Azure Devops Variable Group resource causes the plan output to hide all changes even if none of the variables are supposed to be sensitive. I don’t think the implementors of the Azure Devops provider did anything wrong. Only the secret_value attribute is marked as sensitive. This has been brought up before as a provider issue but it’s actually a limitation of the current state of Terraform.
Is there anything that could be changed in Terraform to fix this? Maybe if the sensitive value is using the default value then it doesn’t need to be treated as sensitive?
I guess the solution on the provider side would be to use an entirely separate block type to hold sensitive values. This seems awkward both for the provider implementor and for the end user, and it would still be excessively hiding details, e.g. the name attribute doesn’t need to be hidden, only the secret_value so it’s hard to know which variable is changing even if the intention is to hide the value.
Unfortunately there’s not much Terraform can do here while simultaneously maintaining the sensitivity feature. Once the set value reaches the UI for rendering, there is no way to differentiate where the sensitive marks came from. The sensitive mark might be there because of an attribute’s schema within that block, or it might be there because the user assigned a sensitive value within the set, which could come from either another resource or is something they purposely configured to be sensitive themselves.
Any changes would need to be made on the provider side. While less convenient for some use cases, a list block can still usually be used in place of a set block, keeping more semantic separation between the individual objects. In some cases the provider may determine that the value isn’t truly “sensitive” enough to warrant the inconvenience, since it’s not a security measure and can only attempt to hide values in the normal CLI output. If the provider is built with the more modern plugin framework, there are more complex data structures available and something like a map of objects could be used to represent the data.
Yeah, I’ve run into the same issue and it can be pretty frustrating. When everything gets marked as sensitive in the plan output, it basically hides all the useful context you’d normally rely on to see what’s actually changing. Like you said, only secret_value should really be hidden, not attributes like App name. It makes debugging harder than it should be. Hopefully Terraform can improve this so that only the truly sensitive fields are masked.