SecurityContext should support runAsUser

[DerGut]

I have an issue with my PodSecurityPolicy specifying runAsNonRoot as true.

The JuiceBalancer already uses the non-root user app but Kubernetes needs a numeric id in order to verify that it is not the root user:

Error: container has runAsNonRoot and image has non-numeric user (app), cannot verify user is non-root

For this to work, the pod securityContext needs to specify runAsUser with the according user id of app.

I would love a change to either:

1. include the numeric id of the app user in the template:

-- helm/multi-juicer/templates/juice-balancer-deployment.yaml

securityContext:
  runAsUser: 100
  runAsGroup: 101

2. or include a template variable for the pod securityContext, so that users can modify it themselves:

-- helm/multi-juicer/templates/juice-balancer-deployment.yaml

{{- if .Values.balancer.securityContext }}
securityContext:
  {{ toYaml .Values.balancer.securityContext | indent 8 }}
{{- end }}

-- helm/multi-juicer/values.yaml

balancer:
  securityContext: {}

[J12934]

Hi 👋
Yes that something we should definitely do 👍

I'd prefer the second option as this would allow to easier specify other securityContext properties. Drop all other privileges and whatnot.

What I'm currently still unclear on in this securityContext world is, what the best way to do it is.
Is there a easy way to modify the Dockerfile to give the user a high user id which is properly, identified by Kubernetes as a non root user? Because setting a user & group in the Dockerfile and then overriding it in the Pods securityContext always feels weird. Would prefer to be able to do it in the Dockerfile if possible, then we could also push this out to JuiceShop.

[J12934]

If you want to send in a PR for the second option,as you already seem to have that sketched out would be awesome, would be a good a addition even when this is fixable directly in the Dockerfile 👍

[DerGut]

I completely agree with you, the second option seems more appropriate either way. I can submit a PR for that 👍

There should be a way to specify a numeric user without using the securityContext 🤔 . Looking at cert-manager, they did exactly that. However, they used bazel for specifying the docker image instead of using a Dockerfile. I'll try to understand how this works and report back!

[J12934]

Merged and Released with 3.7.0 🎉 Again, awesome work 🙏👍

I've looked a bit into how one can set a numeric uid / gid in the Dockerfile itself. Turned out not to be too hard, see d4e1f0d

So all MultiJuicer Images now run with a 1001 uid and gid. Which allows it to pass the runAsNonRoot rule.
JuiceShop still uses a non numeric user so you'll probably need to override this in the securityContext. I'll try to also apply this to the JuiceShop image, so this should hopefully be possible without any config changes in the near future 😀

If you notice something not working as expected feel free to reopen 🙏

[DerGut]

@J12934 Thanks!

It was all working as expected for us. Thanks for the very quick release 🙏