@jamie_jackson I confirmed some behaviors and understand the reason, but I cannot think of a workaround other than what was mentioned in previous posts. Based on my analysis, it might be worth posting on the aws provider github, in case there is a simple fix that could be made on the aws provider to set the sensitivity on a specific origin or even better, on a specific property of a specific origin.
Details:
I verified that when none of the origins have sensitive data, the plan shows origin diffs, moreover it does so EVEN if there was previously sensitive data (ie if no sensitive data, apply, then add sensitive data, apply, then remove sensitivity of data, apply, then plans resume showing mods – I wasn’t sure of that.
I found that the reason that adding one sensitive property to one origin blocks makes all origins of that cloudfront resource sensitive is that the cloudfront resource “origin” attribute is modelled as one object: a list of origins, even though in the HCL it is represented as a sequence of blocks. The following gets added in the terraform state file in the cloudfront instance:
"sensitive_attributes": [
[
{
"type": "get_attr",
"value": "origin"
}
]
],
which does not discriminate between different origins.
However, that setting only affects that particular cloudfront instance, as can be seen from the state file. So while it is accurate that having sensitive data in one origin block taints all origins of a cloudfront instance, this does not propagate to other cloudfront instances; changes to these will remain visible in the plan (I confirmed this).
This seems like a limitation of how the provider modelled a cloudfront distro IMO. It might be worth posting on the aws provider github, maybe there is a simple fix that could be made on the provider (eg maybe there are other allowed types in the tfstate sensitive_attributes
block, one that would allow specific items of origins list to be referenced instead of whole list).