st2-docker icon indicating copy to clipboard operation
st2-docker copied to clipboard

De root the applications and containers

Open Jrc356 opened this issue 4 years ago • 8 comments

Is your feature request related to a problem? Please describe. Since st2 uses a lot of root files, any underlying k8s configuration that blocks running containers as root (such as openshift) prevents the container from running at all because of all the configuration that is held in the roots (/etc, /root, /opt). It is also a massive security flaw to run the containers as root as any RCE can be used on the underlying host.

Describe the solution you'd like De-root the containers and applications. Contain it to it's own folderspace instead of using system folders for configuration.

Describe alternatives you've considered Not really any that I can think of for not running as root.

Jrc356 avatar Mar 03 '20 19:03 Jrc356

Good point. I think this was discussed before https://github.com/StackStorm/st2/issues/3298#issuecomment-424622410 and there is both historic and technical context why it's as it is right now. Someone will need to explore what are consequences and limitations of running st2actionrunners with no root and what changes st2 core will require for that.

arm4b avatar Mar 03 '20 20:03 arm4b

Are we sure this should be closed ? Might it make more sense to keep the topic alive, and even encourage effort towards identifying resolution possibilities, starting work on such, etc ?

I'd observe:

  • Its very common security best-practice to reject pretty much anything running as root
  • Many large companies with particularly sensitive (i.e. regulated) security concerns are pretty rigid with regards to this
  • A concern like this having the effect of prohibiting use of StackStorm in such scenarios is rather tragic
  • Its also a legitimate concern for everyone, from perspectives of both security and engineering, where current rationale of "because reasons" doesn't seem sufficient to inspire confidence

Speculating along these lines, I'd ask:

  • Why are pack installs executed as "typical" actions, thus entangling the need for root elevation with ALL actions ? Couldn't they be seen as more like "meta-tasks" that engage mechanics that don't have to be intertwined with "routine pack-originated" actions ?
  • If pack installs HAVE to be run as actions, why can't they be a special class of action, where they're endowed with special-purpose capability that isn't present in "routine pack-originated" actions ?
  • Why aren't any/all capabilities that involve need for root privilege isolated to special-purpose programs that can be both handled separately from everything else, and justified in their purpose with respect to security concerns ?

rk4n3 avatar Mar 05 '22 20:03 rk4n3

@rk4n3 Thanks for bumping this! Is it a limitation or bug, but at the end of the day, it's not desired behavior from st2 :100:

I think someone would need to dig into it: try all the containers as a st2 user, run a bunch of manual tests and report back their findings. It's been a while and not sure if anyone can remember the reasons, but the root cause might be somewhere in the st2 core and action executions.

arm4b avatar Mar 05 '22 22:03 arm4b

The st2web container is most likely to have issues because of nginx which uses a variety of privileged capabilities. I believe I've seen someone doing nginx without root, but I don't remember where, so it is probably possible with changes.

Another issue is the actions that can do sudo which might be odd.

And they last issue (off the top of my head) is that the deb/rpm files hard code root in some places, so this might be a rabbit hole that requires a series of changes, not just to the Dockerfiles.

cognifloyd avatar Mar 05 '22 22:03 cognifloyd

Hi all - just thought I'd provide an update on this ...

I've done the work of getting my employer's "Enterprise Offering" of StackStorm all de-root'd, but I've done it in the context of our own custom docker image construction.

I'd like to have (perhaps initially 1-on-1) discussion of pro's and con's with what we've done with our docker layout, and the possibility of adopting it as an alternative deployment strategy. Included in that would be some existing+planned refactoring for the purposes of enabling and evolving HA ... anyone interested ?

rk4n3 avatar Jul 08 '22 13:07 rk4n3

@rk4n3 That sounds great. Would you be up for joining the next TSC Meeting (12th July 9.30 AM US Pacific) and discuss the changes for de-rooting the container and their pros and cons? I can add a discussion item to the meeting if you are available!

rush-skills avatar Jul 09 '22 09:07 rush-skills

@rk4n3 That sounds great. Would you be up for joining the next TSC Meeting (12th July 9.30 AM US Pacific) and discuss the changes for de-rooting the container and their pros and cons? I can add a discussion item to the meeting if you are available!

Yes, I would absolutely be willing to attend.

rk4n3 avatar Jul 11 '22 04:07 rk4n3

@rk4n3 Great, I have added an entry for this discussion in Tomorrow's TSC.

rush-skills avatar Jul 11 '22 11:07 rush-skills