Environment variable values should be sensitive only when write_only is enabled

[atorrescogollo]

Since the environment variable value is marked always as sensitive, you are not able to see the actual value in the plan. And, especially when you're passing complex data or doing more than just passing a primitive value (e.g.: interpolation from other variables), it can be very hard to debug.

I think it should be marked as sensitive only when write_only is enabled. That will be more coherent to the Spacelift UI since there you can see any env var value that is not marked as write_only.

[lorengordon]

I have a similar request for spacelift_mounted_file. It's irritating not to see the diff in the plan.

[marcinwyszynski]

Thanks for raising this @atorrescogollo and @lorengordon !

Sadly, this is a limitation of the Terraform provider SDK - as you can see here, there is no way that the sensitivity of the "value" field can be conditional on some other variable.

Thus, the only way to show plaintext variables in the logs, and not show the secrets, would be to have two separate resources for environment variables (eg. spacelift_plaintext_envvar and spacelift_secret_envvar) and two separate resources for mounted files (eg. spacelift_plaintext_mounted_file and spacelift_secret_mounted_file).

[atorrescogollo]

Thanks @marcinwyszynski . That makes sense. It also might be worth noting that there is a terraform-plugin-sdk issue opened:

• Ability to Conditionally Mark Schema Attributes Sensitive hashicorp/terraform-plugin-sdk#736

I'm personally ok with having the additional plaintext resource since seeing the variables in the plan is quite critical in most of the cases. They are the actual inputs to the stack and most of them won't be secrets.

In the end, that will probably go inside a module anyway so you can create one resource or the other depending on the write_only setting from some variable. And I think recreating them is not that big task since it would be just like using terraform.

[marcinwyszynski]

Fair, I'll mark it as a nice starter task for one of our new devs.

[atorrescogollo]

In case it's useful for someone else, I was able to workaround this issue like this (it's cleaner if you use it with a module tbh):

variable "environment_variables" {
  type = map(object({
    value     = string
    sensitive = optional(bool) # technically is called write_only
  }))
  description = "Environment variables to set for the stack"
  default     = {}
}
...

resource "terraform_data" "environment_variable" { # <--- You'll see the plan diff with this resource
  for_each = {
    for k, v in var.environment_variables :
    k => v if !coalesce(try(v.sensitive, null), false) # <--- Only do this for non-sensitive values
  }
  input = each.value.value
}

resource "spacelift_environment_variable" "this" {
  for_each = var.environment_variables

  stack_id   = spacelift_stack.this.id
  name       = each.key
  value      = coalesce(try(terraform_data.environment_variable[each.key].output, null), each.value.value)
  write_only = each.value.sensitive
}

[zhimsel]

In case it's useful for someone else, I was able to workaround this issue like this (it's cleaner if you use it with a module tbh):

variable "environment_variables" {
...

resource "terraform_data" "environment_variable" { # <--- You'll see the plan diff with this resource
...

resource "spacelift_environment_variable" "this" {
...

Yeah, this is basically what I do as well. It works well, it's just got some downsides:

• Users need to know to look at the terraform_data resource to see their variable changes
• There's an extra (unnecessary) resource in state and plan diffs
• Extra complexity/code

[lorengordon]

Thanks for raising this @atorrescogollo and @lorengordon !

Sadly, this is a limitation of the Terraform provider SDK - as you can see here, there is no way that the sensitivity of the "value" field can be conditional on some other variable.

Thus, the only way to show plaintext variables in the logs, and not show the secrets, would be to have two separate resources for environment variables (eg. spacelift_plaintext_envvar and spacelift_secret_envvar) and two separate resources for mounted files (eg. spacelift_plaintext_mounted_file and spacelift_secret_mounted_file).

@marcinwyszynski Could you work around this limitation by adding another attribute to the existing resource, instead of an entirely separate resource? Keep value as a "sensitive" attribute, and add value_nonsensitive or value_cleartext or somesuch as another attribute. User can then specify one or the other, not both. Pretty sure that's how I've seen other providers handle this scenario