Naively mask secret-ish substring within `helm repo add` logs about helmfile

[manics]

In case it's useful here's my temporary workaround manics@9f8e581

[mumoshu]

@cmeury Thanks for the thoughtful response as always!

potential frustration by having to conform to a "foreign" naming scheme
unexpected behavior such as accidentally naming the variable as a "secret" and then wondering why it's not printed for hours.

Good points. I can't agree more!

Then, I'd be happy with something like {{ secretenv "MY_TOKEN" }}, without a hyphen, which conforms naming convention seen in golang text/template funcs in the wild.

[cmeury]

Or we define a function called env_secret that will not output the contents?

[mumoshu]

@cmeury Good point! But I can't exactly say which is the best one here - both seems nice in its own way.

Anyone has a preference, and why is that? 🤔

[cmeury]

I dislike introducing a variable naming convention for this, because it's quite restrictive for the user (potential frustration by having to conform to a "foreign" naming scheme) and it could lead to unexpected behavior such as accidentally naming the variable as a "secret" and then wondering why it's not printed for hours.

[manics]

I just ran into a related issue which might be covered by this whilst setting up a deployment with GitLab. I'm working on an opensource project so I'd like the deploy logs which include helm sync to be open but this means masking some secret env-vars which are passed from GitLab. The quiet -q in helm -q sync is too quiet since it also hides the output of helm.

Might another way around this be a flag that suppresses this line, or prints out a shortened version without all the args?

helmfile/helmexec/exec.go

Line 87 in 283848c

helm.write([]byte(fmt.Sprintf("exec: helm %s\n", strings.Join(cmdargs, " "))))

[mumoshu]

@manics Thanks for sharing your work!

I'd rather like helmfile to be declarative as much as possible so I'm inclined to the secretenv approach noted above, for the purpose of resolving this issue.

However, your work could be useful for operational purpose, like in cases that you want to logger the logging level for fewer outputs from a helmfile run.

So, would it make sense to discuss in another issue about logging level(trace, debug, info, warn, and so on) and probably suppress exec: helm $args outputs in the info/warn levels but not in trace/debug?

[mumoshu]

@manics Hi! Thanks for the suggestion and creating the issue #93.

I'm now inclined to the feature you call a workaround. It turns out to me that, masking only {{secretenv "..." }} of templated strings adds little value compared to the amount of code required for implementation.

Would you mind submitting your work as a PR? Code LGTM and I'll be merging it quickly 😆

[mumoshu]

I believe this isn't needed anymore because we now have configurable log level thanks to #93 #185.
As long the log level is greater than debug, executed helm command and therefore those secrets are not logged.

Also note that we basically should not log secrets #202 #206