Undefined runAsNonRoot doesn't trigger violation

[wedge-jarrad]

The Pod Security Standard Restricted policy requires that runAsNonRoot is set to true. https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted

Containers must be required to run as non-root users.

Restricted Fields

• spec.securityContext.runAsNonRoot
• spec.containers[*].securityContext.runAsNonRoot
• spec.initContainers[*].securityContext.runAsNonRoot
• spec.ephemeralContainers[*].securityContext.runAsNonRoot

Allowed Values

• true

The container fields may be undefined/nil if the pod-level spec.securityContext.runAsNonRoot is set to true.

Therefore, a manifest such as this should violate the policy.

apiVersion: v1
kind: Pod
metadata:
  name: no-nonroot
  labels:
    app: nginx-users
spec:
  securityContext:
    supplementalGroups:
      - 199
    fsGroup: 199
  containers:
    - name: nginx
      image: nginx
      securityContext:
        runAsUser: 1
        runAsGroup: 199
        allowPrivilegeEscalation: false
        seccompProfile:
          type: RuntimeDefault
        capabilities:
          drop:
            - ALL

The above manifest is blocked by the Pod Security admission controller in restricted mode.

$ k apply -n yes-pss -f reject-unset-runasnonroot.yaml
Error from server (Forbidden): error when creating "reject-unset-runasnonroot.yaml": pods "no-nonroot" is forbidden: violates PodSecurity "restricted:v1.33": runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true)

But OPA does not show a violation:

$ gator verify -v suite.yaml
=== RUN   allowed-users
    === RUN   reject-unset-runasnonroot
    --- FAIL: reject-unset-runasnonroot (0.007s)
        unexpected number of violations: got 0 violations but want exactly 1: got messages []
--- FAIL: allowed-users (0.015s)
FAIL    suite.yaml      0.015s
FAIL

Error: FAIL

suite.yaml:

kind: Suite
apiVersion: test.gatekeeper.sh/v1alpha1
tests:
- name: allowed-users
  template: constrainttemplate.yaml
  constraint: constraint.yaml
  cases:
  - name: reject-unset-runasnonroot
    object: reject-unset-runasnonroot.yaml
    assertions:
    - violations: 1

constraint.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: psp-pods-allowed-user-ranges
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    runAsUser:
      rule: MustRunAsNonRoot # MustRunAsNonRoot # RunAsAny
    runAsGroup:
      rule: MustRunAs # MayRunAs # RunAsAny
      ranges:
        - min: 1
          max: 65535
    supplementalGroups:
      rule: MayRunAs # MayRunAs # RunAsAny
      ranges:
        - min: 1
          max: 65535
    fsGroup:
      rule: MayRunAs # MayRunAs # RunAsAny
      ranges:
        - min: 1
          max: 65535

The template is https://github.com/open-policy-agent/gatekeeper-library/blob/master/library/pod-security-policy/users/template.yaml as it was in version 1.0.2.

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[JaydipGabani]

@wedge-jarrad if runAsNonRoot is not set the policy make sure the runAsUser is set to nonroot ID. All in all it makes sure that the container is not run with root users. What is the ask here? why should this policy trigger the violation as restricted mode? IMO this is more flexible then restricted mode since it does not mandate runAsNonRoot field to be set as long as container is running as non root.

[wedge-jarrad]

Our security team notified us that several workloads had been deployed without this configuration in violation of the Pod Security Standards restricted profile. We had thought that the OPA policies we had in place should have prevented that but found that wasn't the case.

I realized somewhat belatedly that these policies were created to enforce the now-deprecated Pod Security Policies, not the current Pod Security Standards. There is significant overlap but they're not quite the same. I guess the ask would be to update these policies for the current PSS but given the availability of the Pod Security Admission Controller I'm not sure if that is a worthwhile undertaking. For our part, we are remediating by moving our PSS enforcement to the built-in admission controller.