Helm-operator: Proposal: Run helm-operator as unprivileged user

[runningman84]

Describe the feature
helm-operator should not run as root

What would the new user story look like?
I might be able to run flux and helm-operator in a restricted environment which forbids any root containers.

Expected behavior
helm-operator should run as a normal user

flux suffers from the same problem https://github.com/fluxcd/flux/issues/1327

[stefansedich]

@runningman84 I had a go at tackling this a while ago now but it fell to the side through other priorities.

The main issue I had was the way we mount secrets for the ssh/gpg keys, my solution at the time was to mount them to an interim location mapped as 0440 and then copy them elsewhere with an init container where we could chmod them to 0400 so that the key would work.

The main downside with that solution was that it would mean that keys would not change as the underlying secrets changed so it meant it would require a reboot of the pod if you wanted to update keys (we could add some kind of watcher to run this again once the underlying secrets change but that felt like unneeded complexity), I began some discussions to see if this was a compromise we were willing to accept but it never really got anywhere.

Would like to see if you had any ideas for how to tackle this and if I might have missed anything at the time, I appear to have "lost" the POC branch I had lying around at the time where I got an end-to-end working will have to check my other laptop.

Maybe also a good one for @stefanprodan and @hiddeco to comment on, do you have any other ideas? is the above compromise something we are willing to accept?

[hiddeco]

Sorry it took so incredibly long to get back to you about this. Given #142 most of the things that are mounted at the moment will soon become a runtime problem.

I think the init container can thus be seen as an interim solution until then. And in our defense, we now have support for HTTPS repositories backed by credentials from a secret, which essentially makes mounting any private keys optional.

One downside of the above is that the setup without Helm will mean quite some boilerplate and modifications to the Deployment for the user (although this is already the case), this could be solved by making the init container chown things by default, but this would not do any good to users not making use of any private keys.

Other things to keep in mind, as these are mounted too in the present:

• Helm repository files, mounted so they can be imported with the available import flag
• .netrc file used for container wide HTTPS credentials for Git repositories

[stefansedich]

Thanks @hiddeco makes sense, I will get onto a fresh POC then to tackle this, feel free to assing this issue to me.

[marmelin]

Hey guys .. is there any major progress on this topic? I decide to use helm-operator, but only if it is usable in a non-root-environment.

I could not find a HTTPs parameter for git connection - how can I set up this?
Is there any working configuration template or documentation?

I also getting the error "waiting: container has runAsNonRoot and image will run as root" . Is it even possible to run this image in a non-root environment? There has to be a "non-root-image" right?