kubernetes

Understand pod security policies

In Kubernetes, a pod security policy is represented by a PodSecurityPolicy resource. This resource lists the conditions a pod must meet in order to run in the cluster. Here’s an example of a pod security policy, expressed in YAML:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - 'nfs'
  hostPorts:
  - min: 100
    max: 100

Briefly, this pod security policy implements the following security rules:

Let’s look at the broad structure of a pod security policy.

  • The metadata section of the policy specifies its name.
  • The spec section of the policy outlines the key criteria a pod must fulfil in order to be allowed to run.

Here is a brief description of the main options available (you can find more details in the official Kubernetes documentation):

  • The privileged field indicates whether to allow containers that use privileged mode. Learn more about privileged mode.
    • The runAsUser field defines which users a container can run as. Most commonly, it is used to prevent pods from running as the root user.
    • The seLinux field defines the Security-Enhanced Linux (SELinux) security context for containers and only allows containers that match that context. Learn more about SELinux.
    • The supplementalGroups and fsGroup fields define the user groups or fsGroup-owned volumes that a container may access. Learn more about fsGroups and supplemental groups.
    • The volumes field defines the type(s) of volumes a container may access. Learn more about volumes.
    • The hostPorts field, together with related fields like hostNetwork, hostPID and hostIPC, restrict the ports (and other networking capabilities) that a container may access on the host system.

Next steps: Create pod security policies for your cluster

Learn more about how to create pod security policies by applying any of the use cases shown in the following guide.

Last modification April 10, 2024