There's no option for marking output as sensitive

[srlobo]

I'm trying to handle some sensible strings with this provider. When there's a change on the output, the output is always shown:

$ terraform plan
shell_script.secret: Refreshing state... [id=cgi15aiuab7ml8hhg690]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # shell_script.secret must be replaced
-/+ resource "shell_script" "secret" {
      ~ dirty                 = true -> false # forces replacement
      ~ id                    = "cgi15aiuab7ml8hhg690" -> (known after apply)
      ~ output                = {
          - "secret_text" = "cGVyb2xh"
        } -> (known after apply)
      - read_error            = "" -> null
        # (2 unchanged attributes hidden)

      ~ lifecycle_commands {
            # (3 unchanged attributes hidden)
        }
    }

Plan: 1 to add, 0 to change, 1 to destroy.

We have the sensitive_environment attribute, but we don't have any means for marking the output as sensitive, it would be great to have that.

[ideasculptor]

I have the same requirement. I wanted to use a shell_script resource to generate an api key but it renders it in the clear. For now, I'm planning to to rsa encrypt the value inside the shell script and then decrypt it prior to using it in the rest of my terraform code. Not terribly convenient, but workable.

[ideasculptor]

Looking at the source code, it seems like treating the output as always sensitive would be almost trivial, if you don't mind forking the code. Making it so that the sensitivity of the output is dynamic based on an incoming variable value, or only marking some keys of the output json as sensitive would be more work. But cloning the repo and adding a shell_script_sensitive resource looks like it might be just a single line of code difference from resource_shell_script.go file, adding Sensitive = true to the schema for output. I haven't implemented in a provider in something like 7 years, so I'd have to revisit what that looks like to be certain that is all that is required, but it is certainly a good place to start.

Coming up on 2 years since the last sign of life from the author - I'm fairly likely to fork this and republish if the license allows. I haven't checked yet.