[RFE] Extend sos clean to have an option for environment variables

[phvalguima]

On certain environments, such as CI pipelines, we may pass secrets via environment variables. In case of a failure, these secrets may be captured in logs by accident. Specifically in the CI case, Github and Co. will go to great lengths to avoid that, but they will not check if our output is the sosreport tarball.

My proposal is to extend the sos clean command to consider environment variables.

We'd call it as follows:

sos clean TARGET --env-variables=<optional list of keys>

Then, if a given env variable (say, key1) is found, then we search for its value (e.g. value1). If no variables are passed, then we consider all the env. variables available as secrets.

Checking for env. variables would avoid the case of one person writing the actual code and another managing pipelines and accidentally leaking the content.

The reason to not use the keyword in this case is b/c I may not be willing to write those secrets to a file and I do not necessarily want to enforce the user to remember each secret it wants to hide.

[phvalguima]

Hi @TurboTurtle, I discussed this with @arif-ali and @dnegreira already, and I wanted your opinion, if that makes sense. I see you did the contributions to add keyword in the sos cleaner.
Thanks

[TurboTurtle]

I agree this would be a nice addition, I'm of two minds on implementation.

The first is that we create a new parser and mapping for env vars - it would largely be a copy of keyword, but as you note we would source the values from the env var names given.

The other choice is to still hook this up to keyword, so that their values are obfuscated to obfuscatedwordX, but we just have logic in the initializer to read from this new env-var option to get the names and source the values there.

[phvalguima]

Hi @TurboTurtle, thanks for the feedback. To simplify it for me (a beginner :D) can I propose to do a copy-and-paste-and-change of keyword?

[TurboTurtle]

You're welcome to take on contributing a new pbfuscator for env vars, definitely.

You'd need to do the parser and mapping, which could be largely copied from keyword, and changed appropriately. You'd also need to add the relevant options to feed the parser based on environment variable name, as well as provide a basic set of tests for the avocado test suite to ensure we are properly obfuscating requested env vars.