Closed EugenMayer closed 2 years ago
Besides keeping in mind https://github.com/tianon/gosu/issues/37 (which I don't think you are telling your container runtime to allocate a TTY and that supervisor is not a shell), I don't know of other gosu
specific concerns.
For general container security, I'd recommend to run the container with --security-opt no-new-privileges
(which will prevent any re-escalation in the spring process). I'd also recommend splitting out multi-process containers generally (use docker or container orchestrator as the "supervisor"), but that may not be feasible in all cases.
Thank you a lot for you insight.
Splitting out in one process per image is of course something we do as often as possible / by default, but sometimes we have legacy stacks with other needs or special needs which require running a second service.
In any case, thank you a lot for your answer - IMHO this issue could be closed
I often end up in the situation running a simple nginx service and some kind of spring boot app.
To run those 2 i usually use supervisor (supervisor runs as root and the other processes too).
My question is, are there any comments/concerns on running gosu to start the spring boot / nginx application while supervisor initially is started as root.
The question is, can i consider this a root-less(ish) design already. Both hight level process would run as non root, so e.g. if a the spring boot application is exploited, the escalation to root is not possible.
Still, once process pid 1 (supervisor) will run as root.
What are your thoughts on combining gosu for this approach? I cannot see a better way of running more then one process (under different users) in a docker image.