May 05, 2021

Kubernetes PodSecurityPolicy Depreciation

PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, with plans to completely remove in Kubernetes release 1.25. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely 

PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, with plans to completely remove in Kubernetes release 1.25. 

Define PodSecurityPolicies 

PodSecurityPolicy (PSP) is a built-in admission controller that allows a cluster administrator to control security-sensitive aspects of the Pod specification. PSP resources are created in a cluster to define the requirements Pods must meet. Then, RBAC rules are created to control which PSP applies to a given pod. If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual. In some cases, PSP can also modify Pod fields, effectively creating new defaults for those fields. If a Pod does not meet the PSP requirements, it is rejected, and cannot run. 

Why use PodSecurityPolicies?

PodSecurityPolicies (PSPs) were defined by Kubernetes to mitigate risk associated with default configurations.

Kubernetes was designed to be easy to get up and running, so by design if not modified you could be opening a large potential attack vector. For example: Networking defaults to an 'allow all' rule, all ingress and egress traffic is allowed which could lead to a denial of service threat if no networking rule is specified. 

Challenges with PodSecurityPolicies 

PodSecurityPolicies has been known to have many usability issues which cannot be addressed without significant changes. Here are a just a few examples: 

  • In order to leverage PSPs there is no audit mode, the user must apply and mitigate friction after the fact leading to high organizational friction.  

  • When there is a conflict, PSPs are designed to resolve alphabetically, this has lead to cases where a pod will run with Privileged context rather than the desired Restricted policy resulting in large security risks. 

  • HELM charts do not ship with a built-in PSP controller. Often user installing charts do not have permissions to apply PSPs leaving many workloads without a policy. Else teams would need to compromise their secure RBAC practices to satisfy requirements.

Securing your Kubernetes Assets Now 

Customer recommendations per Kubernetes: 

"If you’re just beginning your PSP journey, you will save time and effort by keeping it simple. You can approximate the functionality of PSP Replacement Policy today by using the Pod Security Standards’ PSPs. If you set the cluster default by binding a Baseline or Restricted policy to the system:serviceaccounts group, and then make a more-permissive policy available as needed in certain Namespaces using ServiceAccount bindings, you will avoid many of the PSP pitfalls and have an easy migration to PSP Replacement Policy. If your needs are much more complex than this, your effort is best spent adopting one of the more fully-featured external admission controllers..."

Making PSPs simple with Carbon Black Container  

CBC Container provides a fully-featured admission controller to apply PSPs in a simple and operationally beneficial manner.  

  1. Through templated policy options you are able to apply a baseline of rules based on CIS Benchmarks, or Kubernetes Pod Security Standards. All rules provide an alert or block option depending on your desired outcome. Integration into CI solutions empower security administrators to shift left and notify developers if security guidance is not being met. Native CLI tool allows developers to verify locally as well. 
  2. Scope allow administrators to confidently enforce policy on the appropriate assets based on namespace, cluster, cluster group, or even the particular phase of the workload (build/deploy). 
  3. Within the same workflow administrators are empowered with the ability to audit scope before pushing to all scoped assets. Violations highlight if any existing workloads within scope are breaking the defined rules. 
  4. If you are looking to tune up your policies and reduce attack surface you are able to search your assets to understand if there are any violations. 




VMware Carbon Black Cloud Container helps organizations reduce risk, obtain compliance, and achieve simple, secure cloud-native Kubernetes environments at scale. This solution provides the visibility and control that DevOps and Security teams need to secure Kubernetes clusters at scale with operational simplicity. If you are currently leveraging or were planning to leverage PodSecurityPolicy admission controller, consider getting hands on with CB Container and assess the simplicity for yourself. 

Access a trial instance of CB Container here.

Filter Tags

Container Blog