Open planetf1 opened 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.
@planetf1 is this still a thing?
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
@planetf1 is this something that has been done in another project/repository?
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
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
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
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
I propose to switch the UI container base image to a UBI image
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