nginx requires container setuid/setguid about egeria-charts

[planetf1]

This looks like a k8s configuration issue - specifically with the 'Operation not permitted'
In this case the chart is running on RedHat Openshift 4.8 - previous tests were done with 4.7 - possible cause?
The SCC has been modified as per docs

[planetf1]

See https://cookbook.openshift.org/users-and-role-based-access-control/how-can-i-enable-an-image-to-run-as-a-set-user-id.html

• suitable additions need to be made to the egeria docs to account for this image requirement -- or we need to use an alternate container/replace by simpler routing

[planetf1]

A simple (but very insecure) fix is to edit the default restricted policy

oc edit scc restricted

then search for the capabilities to remove SETUID/SETGID and comment out/delete. Then save

Then we get:

$ kubectl logs lab-odpi-egeria-lab-nginx-5d874c84d7-xs867                                                      [10:52:26]
/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: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/..data/default.conf.template to /etc/nginx/conf.d/..data/default.conf
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf
20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/..2021_10_12_09_51_43.768559615/default.conf.template to /etc/nginx/conf.d/..2021_10_12_09_51_43.768559615/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2021/10/12 09:52:04 [notice] 1#1: using the "epoll" event method
2021/10/12 09:52:04 [notice] 1#1: nginx/1.21.3
2021/10/12 09:52:04 [notice] 1#1: built by gcc 8.3.0 (Debian 8.3.0-6)
2021/10/12 09:52:04 [notice] 1#1: OS: Linux 3.10.0-1160.42.2.el7.x86_64
2021/10/12 09:52:04 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2021/10/12 09:52:04 [notice] 1#1: start worker processes
2021/10/12 09:52:04 [notice] 1#1: start worker process 42
2021/10/12 09:52:04 [notice] 1#1: start worker process 43
2021/10/12 09:52:04 [notice] 1#1: start worker process 44
2021/10/12 09:52:04 [notice] 1#1: start worker process 45
127.0.0.1 - - [12/Oct/2021:09:52:15 +0000] "GET /nginx_status/ HTTP/1.1" 400 255 "-" "Sysdig Agent/1.0" "-"
127.0.0.1 - - [12/Oct/2021:09:52:16 +0000] "GET /nginx_status/ HTTP/1.1" 400 255 "-" "Sysdig Agent/1.0" "-"
127.0.0.1 - - [12/Oct/2021:09:52:16 +0000] "GET /nginx_status/ HTTP/1.1" 400 255 "-" "Sysdig Agent/1.0" "-"

This is insecure, so we need to document a better/safer method, probably by using a specific service account, or
perhaps more safe is to replace the nginx image.....

Leave issue here until we decide whether to make a code or docs change.

[lpalashevski]

Hmm.. I will investigate options further as well. It is clear that this is specific to the container platform and the security settings there (local Kubernetes works just fine). In order not to get too much into the area of best practices for securing container platforms I think from our standpoint would be better if we can simplify things and leave up for the consumers to decide on infra and security practices.

Proposing to move away form nginx for the labs deploy and have the simpler configuration using 'API_URL setting on the UI side. This needs some minimal enhancement so it will allow us to set this as env. variable (currently only configurable during build time -- but will look into this).

[planetf1]

Yes, this is specific to a cloud runtime - where security defaults are, quite reasonably, higher. Makes sense to address areas like setuid/setgid where we can as these are commonly unliked unless strictly necessary.

Whether we continue with nginx in the deployment is interesting. It could aid in offering a uniform endpoint for both UIs - but here it's only ever a sample, so there's also a good argument to simplify and go down the API config route instead (which didn't exist when the original nginx addition was started)

[planetf1]

In #107 the chart has been updated to work ok in 'unprivileged' mode. (+1 hr for images to update)
You need to add '--devel' to the 'helm install' command to pick up the latest pre-release charts
This has been tested ok using the 'restricted' policy in Openshift

Please reopen if it does not work for you