Skip to content

Rework main Dockerfile #537

@adutra

Description

@adutra

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 . /app

With 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:

  1. Clearly flag this Dockerfile for evaluation and/or testing purposes, e.g. by renaming it to Dockerfile-dev;
  2. Better yet, move it to dropwizard/service to 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 #268I 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions