Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There's no option for marking output as sensitive #123

Open
srlobo opened this issue Mar 29, 2023 · 5 comments
Open

There's no option for marking output as sensitive #123

srlobo opened this issue Mar 29, 2023 · 5 comments

Comments

@srlobo
Copy link

srlobo commented Mar 29, 2023

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
Copy link

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
Copy link

ideasculptor commented Jul 26, 2023

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.

@kerbou
Copy link

kerbou commented Aug 19, 2024

Any news on this issue? I'm having this exact issue right now

@kerbou
Copy link

kerbou commented Aug 19, 2024

I ended up creating an Azure keyvault in Terraform and then adding my token to the keyvault using Azure CLI from inside my script:

# generate secret token...
az keyvault secret set --vault-name $keyvaultName --name $keyvaultSecretName  --value $token >/dev/null

...and then reference my secret from Terraform again using an azurerm_key_vault_secret datapointer. Only thing is to get dependencies right so the datapointer won't be accessed before the script has run.

Oh well. It's not pretty, but it does the job for us. I'll leave this comment here for inspiration to others

@justinmchase
Copy link

justinmchase commented Jan 2, 2025

This is a major security issue. My secrets are being exposed by this and its a huge problem.

This also happens when there is an issue in the script, the provider will emit stdin and expose all the secrets. Additionally, because it is encoding html characters the built-in redaction by github actions does not redact the password as it should exposing it publicly.

Screenshot 2025-01-02 at 11 17 14 AM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants