Prefix doesn't respect sensitive values

[KyleKotowick]

Terraform CLI and Provider Versions

Terraform v1.1.7
on linux_amd64

• provider registry.terraform.io/hashicorp/random v3.1.0

Terraform Configuration

resource "random_id" "example" {
  byte_length = 8
  prefix      = sensitive("!!SECRET!!")
}

output "random_id" {
  value = random_id.example.hex
}

Expected Behavior

terraform apply should throw one of these errors, because it includes sensitive content:

To reduce the risk of accidentally exporting sensitive data that was intended to be only internal,
│ Terraform requires that any root module output containing sensitive data be explicitly marked as sensitive,
│ to confirm your intent.
│
│ If you do intend to export this data, annotate the output value as sensitive by adding the following
│ argument:
│     sensitive = true

Actual Behavior

It outputs the sensitive prefix in plaintext.

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

random_id = "!!SECRET!!acef1892078df48c"

Steps to Reproduce

1. terraform apply

How much impact is this issue causing?

Low

Logs

No response

Additional Information

I've demonstrated with the random_id resource, but this likely affects all random resources that accept a prefix.

Code of Conduct

• I agree to follow this project's Code of Conduct

[bflad]

Hi @KyleKotowick 👋 Thank you for reporting this.

Value sensitivity does not currently transverse the protocol between Terraform CLI and providers, therefore the provider does not "know" it received a sensitive value as an input. Adjusting the protocol to include this type of information is not exactly straightforward and would be outside the scope of this particular provider. hashicorp/terraform-plugin-sdk#736 goes into some discussion on the internals here, which may only be possible for this particular provider after #177.

Conversely, the only way that providers can signal to Terraform CLI that an attribute value is sensitive is by statically setting the attribute schema to Sensitive: true, which unfortunately would hide the value from all configurations (sensitive or not). A configuration-only approach may be possible with an upstream enhancement such as hashicorp/terraform#29331.

Given the combination of those two, I believe some of the few currently options available for provider implementations today would be offering either a prefix attribute on the random_password resource (whose result attribute is already marked sensitive) or providing a separate "sensitive" random_id resource, although that does not seem ideal since it could technically apply to any of the non-random_password resources.

I'm guessing that marking the output as sensitive or using the sensitive() function on the value in your configuration, while it would "fix" this problem for downstream consumption, would unfortunately still show that prefix in the random_id resource plan.

Would adding prefix to the random_password resource be a suitable solution for your use case?

[KyleKotowick]

Yes, adding a prefix parameter for random_password would be a great solution!

Unrelated, but just FYI that the opening of this ticket failed the associated workflow/action, might need a fix.