runAsNonRoot SecurityContext about gatekeeper-library HOT 7 CLOSED

What is the behavior of Pod Security Policy for runAsUser?

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

These templates were designed to map as close to PSP as is reasonable in order to simplify migration, so this template should try to replicate that behavior.

I will say "not running as root" and "running as a specific user" could have very different implications depending on the infrastructure. Because "run as non-root" is more permissive, it probably deserves its own dedicated template.

It may be reasonable for that separate template to allow either the "runAsNonRoot" directive or for the config to supply a specific (non-zero) user, as either wouldn't be root.

from gatekeeper-library.

The doc tells us this:

MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined (using a numeric UID) in the image.

So in that regard I'd say that it is valid to set the securityContext runAsNonRoot as that will ensure UID != 0 without having to specify the runAsUser in the securityContext.

The rule as is makes it incompatible with the psp, as the psp doesn't require you to set the runAsUser securityContext but the rego does.

In that case it should be in this template right? WDYT?

from gatekeeper-library.

MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined (using a numeric UID) in the image. Pods which have specified neither runAsNonRoot nor runAsUser settings will be mutated to set runAsNonRoot=true, thus requiring a defined non-zero numeric USER directive in the container. No default provided.
https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups

It looks like the PSP does recognise the runAsNonRoot flag, and uses it during mutations. I think this is a good change to make

from gatekeeper-library.

That excerpt is on point, for sure.

It looks like PSP allows a RunAsUser set to MustRunAsNonRoot. Should we add that option?

That would both match what PSP does and avoids retroactively weakening the constraint template's enforcement profile for pre-existing implementations.

Not 100% sure what that parameter would look like. A bool seems easiest, but is discouraged by K8s conventions. OTOH I don't think an enum would make sense.

from gatekeeper-library.

The params.rule runAsNonRoot is already present in the current rego. The only downside is that is checks for a runAsUser field.

See line 38

The only addition in this case is to check for the runAsNonRoot securityContext.

from gatekeeper-library.

Ah, perfect. This change makes total sense then.

from gatekeeper-library.

Good to hear!

I can do a PR with the change and added tests. I need to refactor some existing tests, so I expect this to be ready in the next few days.

(This is an in between daily work thing)

from gatekeeper-library.