Fixes for sensitive values used as input to provisioners #26611
Conversation
If provisioner configuration or connection info includes sensitive values, we need to unmark them before calling the provisioner. Failing to do so causes serialization to error. Unlike resources, we do not need to capture marked paths here, so we just discard the marks.
If the provisioner configuration includes sensitive values, it's a reasonable assumption that we should suppress its log output. Obvious examples where this makes sense include echoing a secret to a file using local-exec or remote-exec. This commit adds tests for both logging output from provisioners with non-sensitive configuration, and suppressing logs for provisioners with sensitive values in configuration. Note that we do not suppress logs if connection info contains sensitive information, as provisioners should not be logging connection information under any circumstances.
Codecov Report
|
| // Marks on the config might result in leaking sensitive values through | ||
| // provisioner logging, so we conservatively suppress all output in | ||
| // this case. This should not apply to connection info values, which | ||
| // provisioners ought not to be logging anyway. |
There was a problem hiding this comment.
which provisioners ought not to be logging anyway.
😂 ah you're funny, this is funny 😉
|
IMO this is a very nice user-facing change and I appreciate you tackling it. The language in the console also makes it really easy to understand what's going on even if you weren't aware of this behaviour. |
|
A flag/reminder that we should probably add docs about this -- esp since this will impact sensitive outputs used in provisioners (so not just limited to people using new sensitive input variable functionality) |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked as resolved and limited conversation to collaborators
Two separate commits in this pull request, which I'd suggest reviewing separately. The first is a bug fix which I'm pretty confident about, and the second is a UI change that I'd really appreciate feedback on.
Unmark provisioner arguments
If provisioner configuration or connection info includes sensitive values, we need to unmark them before calling the provisioner. Failing to do so causes serialization to error.
Unlike resources, we do not need to capture marked paths here, so we just discard the marks.
Hide maybe-sensitive provisioner output
If the provisioner configuration includes sensitive values, it's a reasonable assumption that we should suppress its log output. Obvious examples where this makes sense include echoing a secret to a file using local-exec or remote-exec.
This commit adds tests for both logging output from provisioners with non-sensitive configuration, and suppressing logs for provisioners with sensitive values in configuration.
Note that we do not suppress logs if connection info contains sensitive information, as provisioners should not be logging connection information under any circumstances.
Screenshot