Image runs as root

[alex1989hu]

Current Behavior:

The currently used base image runs as root:

frontend/docker/Dockerfile

Line 22 in 53a1734

FROM nginx:stable-alpine

Steps to Reproduce:

Check the Dockerfile reference above.

Expected Behavior:

Use the official docker-nginx-unprivileged as base image.

Environment:

• Dependency-Track Version: 1.1.0
• Client Browser: N/A
• Client O/S: N/A

Additional Details:

N/A

[stevespringett]

PR from #49 resulted in broken image

[alex1989hu]

PR from #49 resulted in broken image

Not broken: #49 (comment)

[davidkarlsen]

It would be good to have container-friendly images both for the front-end and backend, i.e. images that:

• can run as non-root (either a random uid, or a fixed one)
• run with readOnlyRootFs (i.e. container is immutable, but writes to specific volumes like /tmp, /data etc

we're not able to upgrade the helm-chart to run the 4.x series on Kubernetes before this is in place.

[stevespringett]

Actually it was broken. The container did not respond to HTTP requests. I would consider that broken. Now if that was an environmental issue on my side, it's possible, but I need to be able to build and test the containers and I was unable to successfully test the container because my browser was not able to communicate with nginx.

Ideally, there would only be a single Dockerfile. I'm not interested in maintaining multiple.

[stevespringett]

Also keep in mind that whatever changes are made to the Dockerfile, need to be compatible with the docker-compose that we publish. This is how the majority of people start adopting DT and its the way I test DT. So if changes were made to the Dockerfile that were incompatible with the current compose file, that may explain why testing failed.

[alex1989hu]

Also keep in mind that whatever changes are made to the Dockerfile, need to be compatible with the docker-compose that we publish. This is how the majority of people start adopting DT and its the way I test DT. So if changes were made to the Dockerfile that were incompatible with the current compose file, that may explain why testing failed.

In my PR I also updated the compose file.

[davidkarlsen]

@stevespringett Is anything of this covered by integration-tests - that could help a bit?

[stevespringett]

@davidkarlsen unfortunately, no integration tests at the moment. All unit tests take around 35-40 minutes to complete. Ideally, once that completes successfully, integration tests would kick off. That's not in place today.

[stevespringett]

I'd like to get this resolved and simply publish an updated Docker image without having to wait for the next version of DT.

[davidkarlsen]

@stevespringett will you factor out the docker stuff into a separate repo?