Skip to content

k8s-podsecuritypolicy-defined

Ensure that if a Pod Security Policy exists, it enforces best practices.

When defining a Pod Security Policy, it is highly recommended to make the best use of it and configure to enforce all the most important security best practices.

The following is a list of PodSecurityPolicy attributes that should be set and the recommended value for each.

Prevent containers to share the Host Process ID namespace

By allowing containers to share the Host Process ID namespace, it will make the list of other processes on the host visible. This feature could be useful when using debugging tools or when a sidecar container needs some visibility into its neighbor.

That said, by sharing the host process ID namespace it impacts the isolation between containers in a Pod and between Pods. Worse, this exposes the content of the /proc pseudo-directory, which can often contain sensitive data, passwords or cryptographic keys when they are stored as environment variables.

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  hostPID: true

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  hostPID: false

Prevent Pods from running privileged containers

By running containers as privileged, you are basically asking for the processes inside of it to be given access to all of the capabilities that the root user of the host machine has.

It is highly recommended to never run a Web App with such privileges. The use of such functionnality should be reserved in rare cases when you actually need special access to critical features of the underlying system (such as changing host configuration in a DaemonSet, when running host debugging tools or "Docker-in-Docker" for CI/CD tooling - where more secure alternatives actually exist).

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  privileged: true

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  privileged: false

Prevents Pods from running with added capabilities

It is possible to grant certain special system-level capabilities to containers running in Kubernetes. This may allow one to specify only a limited set of capabilities instead of granting root-equivalent permissions. It is highly recommended NOT to add any extra capability that would be set to Pods by default. Leave the Kubernetes default intact.

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  allowedCapabilities:
  - NET_RAW

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  # simply omit specifying extra capabilities

Prevents Pods from sharing the host IPC namespace

It is highly recommended to prevent Pods from sharing the underlying host IPC namespace. By doing so you ensure that the isolation between containers and the host is maintained.

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  hostIPC: true

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  hostIPC: false

Prevent Pods from sharing the host network namespace

All pods are allocated an IP address. If you allow the Pods to share the underlying host network namespace it violates the isolation between container and host. It would allow a Pod to bypass the Kuberntes network traffic routing. It is highly recommended to disallow Pods from sharing the host network.

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  hostNetwork: true

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  hostNetwork: false

Prevent Pods from running as root

The user ID of the Pods map to the host user table. If you allow your Pods to run using the root user, it means that the underlying process also runs as root on the host.

It is highly recommended to run your containers with a user other than root (uid 0) so that you minimize the impact of a remote code execution.

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  ...

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  runAsUser:
    rule: 'MustRunAsNonRoot'

Prevent Pods from using the NET_RAW capability

If you allow Pods to request the elevated Linux capability NET_RAW, it would allow ICMP traffic between containers and thus they could manipulate arbitrary raw packets in the cluster.

This is an unecessary risk, unless you have specialized needs to affect the raw network traffic.

Examples

Insecure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  ...

Secure Example

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: some-psp
spec:
  requiredDropCapabilities:
  - ALL

More information