-
Notifications
You must be signed in to change notification settings - Fork 387
Description
Is your feature request related to a problem? Please describe.
The Dockerfile that sits at the repository root is rather insecure, especially this directive:
COPY --chown=default:root . /appWith this directive it's a piece of cake to introduce a backdoor, build a hacked Polaris image, and distribute it.
Moreover, I'm concerned that people would think that this is the "official" Dockerfile for Polaris and would use it to push Polaris into production – since it sits at the repository root. This Dockerfile is also referenced in the main README.md, which contributes a bit more to branding it as the "official" thing.
Describe the solution you'd like
I would like to suggest at least one of the following mitigation actions:
- Clearly flag this Dockerfile for evaluation and/or testing purposes, e.g. by renaming it to
Dockerfile-dev; - Better yet, move it to
dropwizard/serviceto reduce its build context to just that module and also to reduce the risk of people using it in production.
Moving that Dockerfile would require changing the build steps though, since it won't be possible to build the entire code base anymore inside the docker build. An alternative was suggested a while ago in #268 – I think we need to revive that PR. In particular, I don't see a sensible difference between building the code in the docker build vs copying pre-built artifacts, neither in terms of build reproducibility nor in terms of security (both are equally insecure, in fact).
Describe alternatives you've considered
No response
Additional context
Side note on the "official" Dockerfile: we don't have one yet, but ideally, that Dockerfile would check out a released tag and build it. Alternatively, it could download the released Maven artifacts from Maven Central. As a third option, it could copy the final artifacts from the local build directory – but that would only be safe if done in CI and triggered by a trusted user.
In any case, I wouldn't recommend using the current strategy of building the local codebase inside the docker build as the strategy to use for future official Docker images.