gatekeeper-library Add an allow list parameter, allowedSysctls, to the Forbidden sysctl constraint template

The K8sPSPForbiddenSysctls constraint template allows limiting sysctls available to pods using a deny list. This change adds another option, allowedSysctls, which allows a constraint to specify an allow list in addition to, or instead of, the deny list.

The matching logic is as follows:

When specified, any sysctl not in the allow list is considered to be forbidden.
The allow list can be omitted.
The deny list takes precedence.

Oct 14 '20 05:10 shomron

A little bit of background on how PSPs handle a similar concern:

PSPs define allowedUnsafeSysctls and forbiddenSysctls fields. The semantics are a bit different:

If a sysctl is explicitly forbidden, it is blocked.
If a sysctl is in the hardcoded safe list, and not explicitly forbidden, it is allowed.
If a sysctl is not in the safe list, it must be explicitly allowed in allowedUnsafeSysctls to be allowed.

What I'm not 100% sure about is whether this logic runs on only sysctls listed explicitly in the PodSecurityContext, or whether the defaults are also considered in step 1. The relevant code is here.

Oct 14 '20 17:10 shomron

Following up with additional context:

PSP's allowedUnsafeSysctls and forbiddenSysctls fields only affect kernel parameters specified via a pod's securityContext.sysctl field. They do not affect a container's ability to set these parameters directly in any way. A privileged container can set a forbidden sysctl by writing to /proc/sys/, regardless of what is set on the pod's securityContext.sysctl and regardless of effective PSP restrictions.

The hardcoded safe list only affects PSP validation of pod securityContext.sysctl fields and means that those parameters can be set without a PSP explicitly allowing them.

I believe that the semantics of allowedSysctls in this PR has the advantage over the PSP implementation in that it is more explicit and does not merge in a Kubernetes version-specific default set.

In both native PSPs as well as this constraint template, forbiddenSysctls takes precedence over allowedSysctls and behaves similarly.

Oct 26 '20 20:10 shomron

@ritazh @sozercan @maxsmythe let me know what you think!

Oct 26 '20 20:10 shomron

+1 to the idea of making things explicit. I don't like the idea of trying to make sure a list of "safe" sysctls is up-to-date