Remove deprecated hubble.ui.securityContext.enabled from hubble-ui

[stelucz]

We hit issue couple months back where hubble-ui was not starting after fresh deployment.

Backend container complained about rights on mounted certificates:

frontend /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
frontend /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
frontend /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
frontend 10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
frontend /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
frontend /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
frontend /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
frontend /docker-entrypoint.sh: Configuration complete; ready for start up
frontend 2024/05/03 06:21:00 [notice] 1#1: using the "epoll" event method
frontend 2024/05/03 06:21:00 [notice] 1#1: nginx/1.25.3
frontend 2024/05/03 06:21:00 [notice] 1#1: built by gcc 12.2.1 20220924 (Alpine 12.2.1_git20220924-r10) 
frontend 2024/05/03 06:21:00 [notice] 1#1: OS: Linux 6.2.0-1015-aws
frontend 2024/05/03 06:21:00 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker processes
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 21
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 22
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 23
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 24
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 25
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 26
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 27
frontend 2024/05/03 06:21:00 [notice] 1#1: start worker process 28
frontend 10.0.2.103 - - [03/May/2024:06:21:01 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
frontend 10.0.2.103 - - [03/May/2024:06:21:08 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
frontend 10.0.2.103 - - [03/May/2024:06:21:18 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
frontend 10.0.2.103 - - [03/May/2024:06:21:28 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
frontend 10.0.2.103 - - [03/May/2024:06:21:38 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
frontend 10.0.2.103 - - [03/May/2024:06:21:48 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
frontend 10.0.2.103 - - [03/May/2024:06:21:58 +0000] "GET / HTTP/1.1" 200 688 "-" "kube-probe/1.28" "-"
backend time="2024-05-03T06:21:46Z" level=warning msg="using fallback value for env var" fallback=false var=GOPS_ENABLED
backend time="2024-05-03T06:21:46Z" level=error msg="failed to initialize application config" error="failed to load keypair: open /var/lib/hubble-ui/certs/client.crt: permission denied"
Stream closed EOF for kube-system/hubble-ui-77f86b68b6-nmt2s (backend)

I found issue having similar symptoms #18816. I started digging into changes of hubble-ui and chart templates, and I observed following details:

• release 1.12 deprecated hubble.ui.securityContext.enabled commit and it was removed in 1.13 commit.
• However, logic evaluating enabled parameter was not removed from template in commit.
• This worked fine as containers run under root and mounted files are owned by root too.
• But this commit changed container image user to 101 and 65532 for frontend and backend images.
• This combination of commits currently breaks hubble-ui backend container with rights issue mentioned above.

What's changed:

Change removes hubble.ui.securityContext.enabled from hubble-ui deployment template and allows to securityContext part be properly applied from values file. It probably does not exactly resolved root-cause of #18816, but current symptoms are resolved by it. Reviewer, please decide if it is valid to close that issue or not by this change.

Possible improvement?
As both containers are in same pod, setting securityContext changes user id, group id and fs id to 1001 for both containers. But Dockerfiles contain different user/group (101 and 65532) for each container image. Probably this could be aligned to single same user/group?

Fixes: #18816

Remove deprecated `hubble.ui.securityContext.enabled` from hubble-ui deployment template

[squeed]

Good catch!

Does this need to be backported? If so, do you know which versions are affected?

[stelucz]

@squeed I am not really sure, but I guess any release since commit 8ac9159 is impacted. I am not so skillful with GitHub to tell specific releases since that commit :) Releases 1.15.4 and 1.14.7 are impacted for sure, these are the versions which we are running right now.

[squeed]

@stelucz It looks like 3092ed1 bumped hubble-ui to v0.12.3, which has the commit changing user ID. It was backported to v1.13, v1.14, and v1.15. So, this fix will need to be backported too. @lambdanis, can you confirm?

[lambdanis]

Nice catch @stelucz.

@squeed My understanding is the same, I marked it for backports. cc @geakstr you might want to take a look.

@stelucz The CI is complaining about a long commit message title: https://github.com/cilium/cilium/actions/runs/8937892162/job/24552554956?pr=32338 Could you rephrase it so that the title is no longer than 75 characters?

[stelucz]

@lambdanis commit message fixed :)

[lambdanis]

/test