feat: Various codejail improvements for devstack usage #92
Conversation
A collection of improvements to enable the usual live-reloading workflow. Running as app meant we couldn't recompile files, modify the container environment, etc. - Run as root in dev target, for convenience and matching other images - Fail RUN commands if there's an error - Use gunicorn for both targets, since in devstack we can specify the CMD in the docker-compose file anyhow. - Install make, less, and some editors in the dev target - Set up virtualenv for dev environment
timmc-edx
force-pushed
the
timmc/cj-root
branch
from
9cd2656 to
a38e7df
Compare
This goes with edx/public-dockerfiles#92 which switches the default CMD from runserver to gunicorn; we want to keep runserver.
This goes with edx/public-dockerfiles#92 which switches the default CMD from runserver to gunicorn; we want to keep runserver.
| # Drop to unprivileged user for running service | ||
| USER app |
There was a problem hiding this comment.
I don't know enough about Docker. This will apply to the Docker's container's process, even though the command was moved from the end of the file? Just double-checking.
There was a problem hiding this comment.
Yeah, as far as I can tell from experimentation and the Dockerfile reference. I believe it even persists across layers (although that's not relevant here).
|
|
||
|
|
||
| FROM app AS dev | ||
|
|
||
| # Developers will want some additional packages for interactive debugging. |
There was a problem hiding this comment.
Since you are the security person, I imagine you have determined this is the right balance between security and usability? Just double-checking.
There was a problem hiding this comment.
Adding these packages shouldn't be a concern, as they're fairly standard and will only be applied to the dev target anyhow. In the prod target you generally want to limit the number of system packages because they can allow an attacker who has gained a foothold to solidify their persistence on the host and pivot to other hosts, but on dev, well... the developer already has full control.
The possibly more concerning thing is that the dev will be running as root (since I've removed USER app from the end of this target). The way people use Docker by default is already very dodgy, since it allows a trivial privilege escalation. More a problem on Linux than Mac. But we do this for all of our Dockerfiles, for a variety of reasons (volume mounting and user table mismatch, service restarts, package installation, etc.)
This goes with edx/public-dockerfiles#92 which switches the default CMD from runserver to gunicorn; we want to keep runserver.
Apparently GoCD has an older or different version of `docker build` that doesn't understand RUN heredoc.
A collection of improvements to enable the usual live-reloading workflow. Running as app meant we couldn't recompile files, modify the container environment, etc.