Using constraints to enforce Pod security

This page shows you how to use Policy Controller constraints to achieve many of the same protections as PodSecurityPolicies, with the added ability to test your policies before enforcing them. The examples in this document do not cover every related constraint, but show you how to get started.

The source code for the constraints and constraint templates discussed in this document is available in the pod-security-policy directory of the Gatekeeper project repository. Each of the constraint templates includes unit tests as well.

Before you begin

Preventing Pods from running privileged containers

We recommend that you prevent Pods from running privileged containers because privileged containers can potentially impact the host operating system on the node or other workloads running on the node.

This constraint prevents Pods from running privileged containers by using the K8sPSPPrivilegedContainer constraint template:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces: ["kube-system"]

Requiring a read-only root file system on the container

By default, a container can write to its root file system. Aside from security concerns, this can cause performance bottlenecks due to write latency in the container's writable layer. You can require a read-only root file system on containers by using a PodSecurityPolicy or by using a constraint.

This constraint uses the K8sPSPReadOnlyRootFilesystem constraint template:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPReadOnlyRootFilesystem
metadata:
  name: psp-readonlyrootfilesystem
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Restricting the types of volumes a container can mount

By default, a container can mount any type of volume registered with the Kubernetes API on the cluster.

This constraint restricts containers to a bounded set of volume types by using the K8sPSPVolumeTypes constraint template:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
  name: psp-volume-types
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    volumes:
    # - "*" # * can be used to allow all volume types
    - configMap
    - emptyDir
    - projected
    - secret
    - downwardAPI
    - persistentVolumeClaim
    #- hostPath #required for allowedHostPaths
    - flexVolume #required for allowedFlexVolumes

Auditing results

You can test the effectiveness of constraints without disrupting active workloads by using the dryrun enforcement action. This produces audit results for your policies without actively blocking. To learn more, see Auditing using constraints.

What's next