Migrate from PSP policies to Policy Bundle

Many organizations have utilized the Pod Security Policies (PSP) to enforce restrictions on their Kubernetes’ Pods. With the removal of PSP from Kubernetes v1.25, we have received feedback from our users that they need policies equivalent to PSP to maintain their security posture. Whether you want to move to Pod Security Standards, or maintain policy continuity with PSP, Policy Controller can meet your business objectives.

In addition to migrating PSP, Policy Controller provides several capabilities such as a central dashboard for viewing policy violations with remediation recommendations across a fleet of clusters for all environments and Google built and managed policy content to help meet desired governance and compliance across multiple enforcement points (ci/cd, admission and audit) and multiple enforcement types (dryrun, deny). 

Alternatives to using Policy Controller for PSP migration

Beyond migrating to Policy Controller, some alternatives include using the Pod Security admission (PSA) controller or Open-Source Gatekeeper.

Using the Policy Controller to migrate PSP

While existing PSPs are often thought of primarily as a validating admission controller, depending on the specific PSP configuration it may also include mutation admission control. This post will first cover migrating the PSP validation aspect using the Pod Security Policy (PSP) v2022 policy bundle, and then cover the two primary options for migrating any PSP mutations.

Migrate PSP validations

PSP bundle is a group of constraints which help audit or enforce Pod Security Policies. The PSP bundle can be installed on a Cluster with Policy Controller v1.11.1 or higher. The policies included are configured in "audit" mode by default, so they do not impact any of your existing or new workloads. You can apply these policies using kubectl (demonstrated below), kpt, or Config Sync.

2. Obtain the Pod Security Policy (PSP) v2022 policy bundle. For example, using git:

Some constraints may require customization based on the Field Name’s value. For example, PSP Restricted includes requiredDropCapabilities: [“ALL”]. This behavior would be configured by copying the psp-capabilities.yaml constraint to your org-restricted-psp folder, removing the allowedCapabilities parameter, and setting the requiredDropCapabilities parameter to [“ALL”].

NOTE: Do not copy any constraints to your folder for which a mapped PSP Field Name is not part of your existing PSP.

4.Apply the customized policy constraints with kubectl:

5. Verify that policy constraints have been installed and check if violations exist across the cluster:

PSP mutations

In addition to validation, your existing Pod Security Policy may include mutating admission control to configure some defaults. If you do not currently make use of PSP mutations, neither migration or configuration of mutations is required. For example, the Privileged PSP example contains no mutation. If you utilize PSP mutations, we recommend directly updating the configuration of your Pods and PodTemplates to include any values which were previously set by PSP mutation. We recommend eliminating all PSP mutation prior to migrating as mutation makes it harder to implement GitOps and shift left for policy, however if it is a must for your business then mutation can be implemented using Policy Controller.

Migrate mutations

To identify if your existing PSP is making modifications, compare your Pod and PodTemplate source configuration against the resources running on your PSP cluster and add any changes into your source configuration.

Configure mutations

Alternatively, you can use Policy Controller’s resource mutation feature to implement similar mutations in your own environment. Mutation is disabled in Policy Controller by default, and must be enabled before use. Policy Controller mutations are not supported on GKE Autopilot clusters.

For example, PSP Restricted includes allowPrivilegeEscalation: false which configures a default value of false for spec.containers and spec.initContainers created without a value for .securityContext.allowPrivilegeEscalation. This mutation behavior can be replicated for spec.containers using the following Assign object which sets spec.containers[*].securityContext.allowPrivilegeEscalation to false if created without a value:

Test changes

Before disabling your existing PSP, you should first test examples of your workloads by applying the Privileged PSP which does not include any mutation. If any issues are discovered, you can easily rollback to your existing Pod Security Policy and address as needed. If appropriate, you can set your PSP bundle to the deny enforcement action. Once the configuration has been fully tested for an appropriate length of time, you can then disable your existing PSP.

Viewing the Pod Security Policy violations on Dashboard

Violations on the cluster can also be viewed in the UI using the Policy Controller Dashboard.

Monitoring the cluster(s) for Pod Security Policy bundle violations 

The PSP bundle by default has its enforcement action set to dryrun which is the configuration for Policy Controller to show you violations without blocking or aborting any resources. This gives you the ability to audit your clusters, share any violations with workload owners and collaborate on fixing critical security issues.

All policy violations are automatically recorded in Cloud Logging and can be found by applying these filters in the Logs Explorer:

You can also set up log based alerts using Cloud Monitoring for policy violations.

Policy Controller includes the metrics related to policy usage such as number of constraints, constraint templates, audit violations detected just to name a few (see list of metrics exposed). These metrics can be exported to Cloud Monitoring and/or Prometheus at install time (blog, docs). You can also set alerts based on metrics.

Conclusion

Policy Controller enables the enforcement of both Google created and maintained Policy bundles and custom policies for your cluster which prevent changes to the Kubernetes API from violating security, operational, or compliance controls. Optionally, Policy Controller can also be used to implement resource mutation or analyze configuration for compliance before deployment to your Kubernetes cluster.

Get started today

The easiest way to get started with Policy Controller is to install Policy Controller and try out some of the other Google created and maintained Policy bundles:

• Anthos Service Mesh security

• CIS Kubernetes Benchmark v1.5.1

• PCI-DSS v3.2.1

• Pod Security Standards Baseline

• Pod Security Standards Restricted

• Policy Essentials