search

odpi / egeria-ui

User interface instance using main Egeria functionalities.
https://odpi.github.io/egeria-ui/
Apache License 2.0
35 stars 17 forks source link

Switch UI Docker base image to UBI #289

Open planetf1 opened 2 years ago

planetf1 commented 2 years ago

I propose to switch the UI container base image to a UBI image

planetf1 commented 2 years ago

Additionally, the image needs to run as an unpriviliged user.

Currently the container fails (openshift, 'restricted' security context) with:

/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2021/12/22 14:16:51 [warn] 1#1: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2021/12/22 14:16:51 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

This was addressed for a 'raw' nginx deployment (which we use in front of UI & api) in the odpi-egeria-lab helm chart in 9ae21390d6679ef7736934eb8966857a1d446325

Whilst a similar approach could be followed, combining the improved security stance with a new base image likely makes the most sense

In the short term I will work around this issue in the chart itself. If/when this image is updated, the chart will need updating in any case.

sarbull commented 1 year ago

@planetf1 is this still a thing?

planetf1 commented 1 year ago

The failure no longer occurs.

However I still think we should look at whether we can/should use a UBI8 image, since these typically include some forms of monitoring & are scanned for security vulnarabilities.

We have to balance this with resource overhead

sarbull commented 1 year ago

@planetf1 is this something that has been done in another project/repository?

planetf1 commented 1 year ago

We did it for base Egeria. The idea of the UBI images is that they are more security hardened/reviewed . There was a good image for java apps, which we used.

I have not looked into what we might have to help with the UI - a quick search suggests there are some options such as https://catalog.redhat.com/software/containers/ubi8/nginx-120/6156abfac739c0a4123a86fd

We would need to see if these are suitable for us, and look at what value they provided - the hope, primarily, is that they address security issues in the base image layer when compared with base nginx.

For example our current UI image -> https://quay.io/repository/odpi/egeria-ui/manifest/sha256:602709226ebe82f5148e3f44c8742487250dec372c13da29785229ebc48ad4cf?tab=vulnerabilities

planetf1 commented 1 year ago

So we probably should try

From registry.access.redhat.com/ubi8/nginx-120

Or search for other similar variants. But the base image is somewhat problematic

planetf1 commented 1 year ago

reasoning: https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image

sarbull commented 1 year ago

i merged the current docker image without platform linux/arm64 as it didn't build the image due to some errors, i will try to prioritize this issue, next iteration is not supporting linux/arm64