Switch UI Docker base image to UBI

[planetf1]

trafficstars

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

• supported base image
• tested/updated for security vulnarabilities
• consistent with image used for base egeria
• hosted on quay.io so will avoid dockerhub pull request limitations (but note that either side could have outages)

The likely base is https://catalog.redhat.com/software/containers/ubi8/nginx-118/5f521a6f9dd2d5ca7158e5dc

[planetf1]

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]

@planetf1 is this still a thing?

[planetf1]

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]

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

[planetf1]

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]

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]

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

• security, support

The former is a must. But if the image is inappropriate in some way, then we need to source a similarly secure and maintained image to use. Our current one has too many vulnarabilities

[sarbull]

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