log: add mini log library #365
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lbajolet-hashicorp
force-pushed
the
censor_sensitive_values
branch
from
0172f9d to
18779b1
Compare
nywilken
approved these changes
Feb 8, 2024
|
Honestly that is a good question, I have not considered it since we have access to the |
The Azure log library mimicks what the standard log library allows (with fewer functions exposed), and uses what the Packer SDK exposes for filtering out sensitive strings. We have to do this here for censoring potential sensitive data separately from Packer itself, as the secrets produced/consumed by the plugin itself aren't necessarily known by Packer, so it cannot censor them from its output, and we have no way for a plugin to declare what is sensitive in its logs. Therefore, we do it at log-time, in the plugin process, so Packer receives pre-censored logs, which it can render normally through its pipeline.
Since there's some data we want to censor from the output of the plugin, we start using the plugin's wrapper over stdlib's log which uses the SDK's filtering methods, and replace all the log statements of the plugin by this.
The Azure plugin had used the SecretFilter from the Packer SDK prior to introducing the log wrapper, however, because the process that produces the logs is separate from Packer, the filter was not propagated to the main Packer process, and thus this assignation was ineffective when it came to protecting secrets. The previous commits has introduced a local wrapper for the log printer, and this commit only fixes/introduces a comment to explain the call to SecretFilter.Set in both the ARM and DTL builders.
Since the secret key contains a P12 blob, it is sensitive and should be redacted from the output.
lbajolet-hashicorp
force-pushed
the
censor_sensitive_values
branch
from
b0edf5f to
b6fd698
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Azure log library mimicks what the standard log library allows (with fewer functions exposed), and uses what the Packer SDK exposes for filtering out sensitive strings.
We have to do this here for censoring potential sensitive data separately from Packer itself, as the secrets produced/consumed by the plugin itself aren't necessarily known by Packer, so it cannot censor them from its output, and we have no way for a plugin to declare what is sensitive in its logs.
Therefore, we do it at log-time, in the plugin process, so Packer receives pre-censored logs, which it can render normally through its pipeline.
Then we adopt it for all our logging uses in the plugin, which should censor all the strings we want in the plugin process.
Closes: #358