What does "securityContext.runAsNonRoot=true" actually prevent?

General Discussions
1

We’re running a number of k8s clusters running v1.24.

When we upgraded our clusters from v1.13 to v1.24, we saw several security warnings appear on “kubectl apply”. One of them is “runAsNonRoot != true”. So, I implemented a change that adds “securityContext.runAsNonRoot: true”, and also a “runAsUser: ”, where “” is the userid that should be set at the end of the Dockerfile, when the main process is run.

I did verify that if I set that property, the warning doesn’t appear anymore. However, I also had to verify that the presence of this setting is actually preventing a security problem, for instance if it actually prevented a container from running as nonroot, which I would assume is the point.

So, I simply changed the Dockerfile in one service that I’m testing this with, and I added “USER root” right before the main process is started. I expected that at some point in the deployment, k8s would fail in some way, telling me that this constraint has been violated. Nothing like that happened. It deployed the new image successfully with no complaints at all.

What am I missing?

2

I just thought to exec into the container and see what userid owns the main process, and it’s user “kube”, not “root”. In the Dockerfile, I did “USER root” just before the “RUN” of the main process script. Is k8s just ignoring my request to set the user as root? If so, then what is the point of “securityContext.runAsNonRoot”?

3

I think I’m figuring this out. In addition to setting “runAsNonRoot”, we also had to set “runAsUser” to the uid of the user it needs to run as. If we omitted that, I think it gave us an error, but I don’t remember the exact wording right now.

I think what this is doing is not validating that it’s running as that user, it is FORCING it to run as that user. I don’t know why I didn’t realize that before.

Assuming this is true, now I’m wondering what the impact would be of using “runAsUser”, but NOT “runAsGroup”.