This page shows you how to continue to enforce many Pod-level security controls in your Google Kubernetes Engine (GKE) clusters by migrating from PodSecurityPolicy to the PodSecurity admission controller.
PodSecurityPolicy was a Kubernetes admission controller that let you enforce Pod-level security controls such as the Kubernetes Pod Security Standards, providing granular control over the security configuration of your deployed workloads. The Kubernetes project deprecated PodSecurityPolicy and removed the feature entirely in Kubernetes v1.25.
If you currently use PodSecurityPolicy in your GKE clusters, disable the feature before you upgrade to GKE version 1.25 and later.
To learn more about the deprecation and removal of PodSecurityPolicy, refer to PodSecurityPolicy deprecation.
PodSecurity and PodSecurityPolicy
PodSecurity admission controller is available and enabled by default on
clusters running the following GKE versions:
- Version 1.25 or later: Stable
- Version 1.23 and version 1.24: Beta
PodSecurity allows you to enforce the policies defined in the
Pod Security Standards
on your deployed workloads.
PodSecurity lets you continue to implement
recommended Pod-level security configurations in your clusters after you migrate
from PodSecurityPolicy. Unlike PodSecurityPolicy,
PodSecurity doesn't support
Requirements and limitations
PodSecurityis available in beta in GKE versions 1.23 and 1.24, and in stable in GKE version 1.25 and later.
PodSecuritydoesn't terminate Pods that are already running on your nodes, even if they violate the applied policy.
PodSecuritydoesn't mutate fields. If you use any mutating fields in your PodSecurityPolicy, modify your Pod spec to ensure that those fields are present when you deploy the workloads.
Before you begin
Before you start, make sure you have performed the following tasks:
- Enable the Google Kubernetes Engine API. Enable Google Kubernetes Engine API
- If you want to use the Google Cloud CLI for this task,
install and then
gcloud CLI. If you previously installed the gcloud CLI, get the latest
version by running
gcloud components update.
- Ensure that you have a GKE Autopilot or Standard cluster running version 1.23 or later.
- Check your
PodSecurityPolicyresources for mutating field configurations. Add those fields to your Pod manifests so that any workloads already running on your nodes conform with a policy defined in the Pod Security Standards. For instructions, refer to Simplify and standardize Pod Security Policies.
Configure the PodSecurity admission controller in your cluster
PodSecurity admission controller enforces the Pod Security Standards at
the namespace level. You must configure the controller to enforce one of the
policies defined by the Pod Security Standards in each namespace. The following
policies are available:
- Restricted: Most restrictive policy. Complies with Pod hardening best practices.
- Baseline: Minimally restrictive policy that prevents known privilege escalations. Allows all default values for fields in Pod specifications.
- Privileged: Unrestricted policy that allows anything, including known privilege escalations. Apply this policy with caution.
To migrate your PodSecurityPolicy configuration to the
controller, do the following in every namespace in your cluster. These steps
are described in detail in the sections that follow.
- Apply the Restricted policy in
dry-runmode to the namespace and check for violations.
- If your Pods violate the Restricted policy, apply the less restrictive
Baseline policy in
dry-runmode to the namespace and check for violations.
- If your Pods violate the Baseline policy, modify your Pod specs to fix the violations.
- When the Baseline policy no longer returns violations, apply the
enforcemode to the namespace.
To avoid potential downtime if
PodSecurity rejects new Pods, perform these
steps in a staging environment. Alternatively, you can apply the identified
audit mode instead of
enforce mode and review your audit logs to
find potential rejected Pods.
audit mode doesn't enforce the policy. GKE deploys
the Pods and adds entries to the GKE audit logs.
List all namespaces in your cluster
Get a list of all namespaces in your cluster. Repeat the steps in the following sections for every namespace in the list:
kubectl get ns
In the following GKE versions, GKE ignores policies
that you apply to the
- 1.23.6-gke.1900 and later
- 1.24.0-gke.1200 and later
In earlier GKE versions, avoid enforcing policies in
Apply each policy of the Pod Security Standards in dry-run mode
In the following steps, you'll apply each policy in
dry-run mode, starting
with the most restrictive Restricted policy. If the output shows a warning,
either modify the violating Pod spec to comply with the policy, or try the less
restrictive Baseline policy. If the output doesn't show a warning, you can
then apply the Baseline policy without
Apply the Restricted policy in
kubectl label --dry-run=server --overwrite ns NAMESPACE \ pod-security.kubernetes.io/enforce=restricted
If a Pod in the namespace violates the Restricted policy, the output is similar to the following:
Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest" namespace/NAMESPACE labeled
If the Restricted policy displays a warning, modify your Pods to fix the violation and try the command again. Alternatively, try the less restrictive Baseline policy in the following step.
Apply the Baseline policy in
kubectl label --dry-run=server --overwrite ns NAMESPACE \ pod-security.kubernetes.io/enforce=baseline
If a Pod in the namespace violates the Baseline policy, the output is similar to the following:
Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest" namespace/NAMESPACE labeled
If your Pods violate the Baseline policy, modify your Pods to fix the violations and repeat this step until GKE no longer displays a warning.
Enforce the policy on a namespace
When you identify the policy that works for a namespace, apply the policy to the
kubectl label --overwrite ns NAMESPACE \ pod-security.kubernetes.io/enforce=POLICY
POLICY with the name of the policy, which can be
Ensure that you repeat the preceding steps for every namespace in your cluster.
Disable the PodSecurityPolicy feature on your cluster
After you configure the
PodSecurity admission controller for every
namespace in your cluster, disable the PodSecurityPolicy
gcloud beta container clusters update CLUSTER_NAME \ --no-enable-pod-security-policy
CLUSTER_NAME with the name of your
When you upgrade your cluster to GKE version 1.25,
GKE automatically removes all remaining
objects, including those added by GKE,
Anthos Config Management, and any
PodSecurityPolicy objects that you
- Try to conform to the Restricted policy where possible. Audit your applications to see if the configuration can be hardened further.
- You can lock the Pod security mode to a specific Kubernetes minor version
by adding the
pod-security.kubernetes.io/MODE-version: VERSIONlabel to the
kubectl labelcommands in the previous steps. Replace
VERSIONwith the Kubernetes version number, such as
- After you disable the PodSecurityPolicy feature, review your running applications to check for disruptions or gaps in the security configuration.
- After you configure
PodSecurity, update your namespace creation process to automatically apply a
PodSecuritylabel to all new namespaces. For information, see Review namespace creation process
- Learn more about Pod Security Standards.
- Learn more about the
- Learn how to apply custom Pod-level security policies using Gatekeeper.
- Read about the PodSecurityPolicy deprecation.