-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: New environment variable obfuscation functionality #355
base: main
Are you sure you want to change the base?
Conversation
39ceb12
to
790470e
Compare
@jkjell would you be able to do a review? |
With this latest change I go from default blocking behavior to default obfuscate behavior. And the default list Introducing several arguments:
I believe that as we are still in the v0.x.y versions it should not be a problem to change the default @mikhailswift I need a bit of help on the |
9ec0ae2
to
1e45a7b
Compare
Forget the part about the |
da61a58
to
b33029c
Compare
My last changes fixed the tests. I also renamed block to filter. Which seems to me that it is a much more logical. |
7265fbb
to
aedf429
Compare
It looks like we have a challenge with the linux tracing. It also contains all the env vars in the proc info when used. So the behavior needs to pass the same flags there too. |
f8bdde2
to
ecacd4e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Waiting for others feedback
@ChaosInTheCRD and I had a conversation on Slack about the implementation because there is a 'hidden' use of Environment inside the commandrun attestor. It used to use the We discussed that is might be best to introduce the current new flags not on the environment attestor level, but move them to the global flags. This way the flags can be used both in Environment and Commandrun Attestor. Also the filtering and obfuscation methods need to made generic for. So not specifically as part of the attestors. @kairoaraujo @ChaosInTheCRD if we agree on this I'll implement the change that way. A 👍 is enough. |
Nice to see that this gets implemented! 👍 (PS: Is that not more a feature than a chore pr?) |
The purpose of the obfuscation is to have a general list of sensitive keys. And they cover the aspect of keys that are matched based on glob. The current that is captured by glob is already covering a lot. Also we do not want to obfuscate all bamboo values I believe. With the additional flags you can anything that is not covered by these 'sane defaults'. If there is something that is really missing in the sane defaults we could of course add that. See the list here |
Yes, obfuscating all bamboo variables would not make sense. With the list https://github.com/matglas/go-witness/blob/ecacd4ec0ba7a4a12664d3e5d75eedbd433bb9f2/attestation/environment/sensitive_env_vars.go#L24-L28 of defaults are those case sensitive? Secret and password are already covered right now. |
Yes they are.
These are valuable additions indeed. I'll include them. |
d033075
to
0e9b63e
Compare
9c8284c
to
8a69303
Compare
@jkjell do you think we could include this in the next release too? |
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Co-authored-by: Kairo Araujo <kairo@kairo.eti.br> Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Adding flags to behave blocking or obfuscating and adding new keys. Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Co-authored-by: Kairo Araujo <kairo@kairo.eti.br> Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Co-authored-by: Tom Meadows <tom@tmlabs.co.uk> Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
Signed-off-by: Matthias Glastra <matglas.git@gmail.com>
What this PR does / why we need it
Implementing obfuscation of environment variables. Capturing secret values like tokens and api keys is a security risk and attestation should not hold that information. Although it is important to know which values are used to adjust the behavior for scripts.
Which issue(s) this PR fixes (optional)
Fixes:
Acceptance Criteria Met
Special notes for your reviewer:
The default list can be extended with more variable that should be hidden. This can be extended in the cli with flags that add more items to the list. I think that the default obfuscation list does not need to be 'overridden' but only needs extension.
It also obfuscates based on glob. So if an key would be added like
REASON_*
it will pick up allREASON_TEST
etc. variables. There are a few glob keys that are added by default.Final solution
New flags:
--env-filter-sensitive-vars
--env-disable-default-sensitive-vars
--env-add-sensitive-key
can be repeated multiple times.--env-exclude-sensitive-key
can be repeated multiple times.Blocklist is now filter list. It describes better what it does.
Obfuscation is the default behavior.
Variables can be obfuscated or filtered based on glob patterns e.g.
*SECRET
There is a default list of globs which is quite restrictive by default allow users to explicitly use
exclude-sensitive-key
to exclude it from filtering or obfuscation.