Creating Pod Security Policies

caution

Pod Security Policies are only available in Kubernetes until v1.24. Pod Security Standards are the built-in alternative.

Pod Security Policies (PSPs) are objects that control security-sensitive aspects of the pod specification (such as root privileges).

If a pod doesn't meet the conditions specified in the PSP, Kubernetes won't allow it to start, and Rancher will display the following error message: Pod <NAME> is forbidden: unable to validate....

How PSPs Work

You can assign PSPs at the cluster or project level.

PSPs work through inheritance:

• By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects.
• Exception: Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior.
• You can override the default PSP by assigning a different PSP directly to the project.

Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.

Read more about Pod Security Policies in the Kubernetes documentation.

Default PSPs

Rancher ships with three default Pod Security Policies (PSPs): the restricted-noroot, restricted and unrestricted policies.

Restricted-NoRoot

This policy is based on the Kubernetes example restricted policy. It significantly restricts what types of pods can be deployed to a cluster or project. This policy:

• Prevents pods from running as a privileged user and prevents escalation of privileges.
• Validates that server-required security mechanisms are in place, such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added.

Restricted

This policy is a relaxed version of the restricted-noroot policy, with almost all the restrictions in place, except for the fact that it allows running containers as a privileged user.

Unrestricted

This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.

important

When disabling PSPs, default PSPs are not automatically deleted from your cluster. You must manually delete them if they're no longer needed.

Creating PSPs

Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file.

Requirements

Rancher can only assign PSPs for clusters that are launched using RKE.

You must enable PSPs at the cluster level before you can assign them to a project. This can be configured by editing the cluster.

It is a best practice to set PSP at the cluster level.

We recommend adding PSPs during cluster and project creation instead of adding it to an existing one.

Creating PSPs in the Rancher UI

1. In the upper left corner, click ☰ > Cluster Management.
2. In the left navigation bar, click Pod Security Policies.
3. Click Add Policy.
4. Name the policy.
5. Complete each section of the form. Refer to the Kubernetes documentation for more information on what each policy does.
6. Click Create.

Configuration

The Kubernetes documentation on PSPs is here.