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

Add ability to handle sensitive yaml input without leaking sensitive data #546

Closed
mcpappas opened this issue Jul 13, 2020 · 4 comments · May be fixed by #625
Closed

Add ability to handle sensitive yaml input without leaking sensitive data #546

mcpappas opened this issue Jul 13, 2020 · 4 comments · May be fixed by #625

Comments

@mcpappas
Copy link

Description

Currently, the only way to pass in yaml formatted input is through the values attribute which will expose any sensitive data through the metadata.values output attribute on the helm_release resource. I desire a similar values_sensitive attribute (like set_sensitive) whose values will be cloaked in any console output (exactly how set_sensitive does so after #480).

My use case is to input sensitive values that are outside of our control (passwords controlled by external parties) through a "secure file" in an Azure Devops pipeline. Secondarily, I want the flexibility to template various other (terraform managed) secrets into a yaml file using the templatefile function (as I find the number of set_sensitive blocks that would be required to be prohibitively time consuming to create and maintain).

Again, while it would be possible to prevent these values from leaking using set_sensitive, when building enterprise software with many secrets (at varying depths in the yaml values structure) this becomes prohibitively complex and time consuming.

Also, I am willing to give implementing this a shot (would be my first contribution using Go, but seems pretty straightforward).

Potential Terraform Configuration

resource "helm_release" "example" {
  name  = "example"
  chart = "example"

  values = [
<<-EOT
notSecret: "not-a-secret-value"
EOT
]

/* 
any keys used in this section will not be leaked in plan/apply through
the output metadata.values or the values_sensitive attribute itself
*/
values_sensitive = [
file("secureFile.yaml"), /* beware, contains secrets */
templatefile("values.template.yaml", { super_secret = var.super_secret }),
<<-EOT
mySecret: "${ var.super_secret_value }"
maybeASecret: "${ var.maybe_not_secret_value }"
EOT
]
}

References

#480 (I am suggesting a new attribute that is a combination of functionality offered through set_sensitive and the existing values attributes)
#340 (Rejected in favor of 480)

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment
@leandroyou
Copy link

Hello, just wondering if this change is still planned or it was just forgotten.
As it would be really helpful to have the same functionality as values but sensitive.
Thanks

@dshmatov
Copy link

dshmatov commented Jul 15, 2021

Hey @dak1n1 @redeux @mcuadros ! Guys could you please make some effort to push this issue and make it alive, this is a cool feature and PRs are ready but it's abandoned over a year for some unknown reason. Thank you in advance!

Also is any way to inherit the sensitivity of the terraform variables, like if the variable pointed as sensitive sensitive = true it should be masked by default without any explicit actions like setting it via set_sensitive?

@github-actions
Copy link

github-actions bot commented Dec 4, 2022

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

Copy link

github-actions bot commented Jan 5, 2024

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

@github-actions github-actions bot added the stale label Jan 5, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment