Sysdig Secure 3.0 introduces Kubernetes Policy Advisor to provide Kubernetes native prevention using Pod Security Policies (PSPs). This feature automates the generation of PSPs and validates them pre-deployment, so they don’t break applications when applied. This allows users to adopt Pod Security Policies in production environments quickly and easily. PSPs also provide a Kubernetes native control mechanism to prevent threats without impacting performance, unlike agents that have to intercept every action on the host.
What is a Kubernetes Pod Security Policy?
Kubernetes Pod Security Policies provide a framework to ensure that Pods run only with the appropriate privileges and can solely access the appropriate resources. Security and DevOps teams operating Kubernetes clusters leverage them to control Pod creation, and limit the capabilities available to specific users, groups, or applications.
Kubernetes permissions (RBAC) are used to link PSPs to users or services through the roles they have. When these users or services try to deploy a Pod, the PSP will act as a gatekeeper evaluating the Pod security configuration against the defined policy in the PSP.
Least privileged Pod permission model: PSPs use cases
If a user or service can create a Kubernetes Pod, the service can do anything the docker command could, including running a privileged container, using node resources, etc. This means that a regular user or a running pod can abuse this to land on a Kubernetes node as root.
Least privilege is the concept and practice of restricting access rights for users, accounts, and computing processes to only those resources absolutely required to perform routine, legitimate activities.
PSPs will be critical to organizations achieving compliance certifications. Regulatory compliance standards like PCI, SOC2, or HIPAA all include references to least privilege access. Here’s an example:
PCI Section 7 – Restriction of access to privileged user IDs to the minimum privileges necessary to perform job responsibilities.
With a Pod Security Policy, you limit Pod behavior to improve security. For example:
Prevent privileged pods from starting and control privilege escalation.
Restrict access to the host namespaces, network, and filesystem the Pod can access.
Restrict the users/groups a Pod can run as.
Limiting the volumes a pod can access.
Restrict other parameters like runtime profiles or read-only root filesystems.
Challenges of using PSPs in production
Configuring Pod Security Policy is a tedious process. Once you enable PSPs in your Kubernetes cluster, any Pod that you want to deploy must be allowed by one of the configured PSPs.
Implementing strong security policies can be time consuming. Generating a policy for every deployment of each application is a burden; if your policy is too permissive, you are not enforcing a least privilege access approach. However, if it is too restrictive, you can break your applications, as Pods won’t successfully run in Kubernetes.
Being able to automatically generate a Pod Security Policy with the minimum set of access requirements will help you onboard PSPs more easily. You can’t just deploy them in production without verifying that your application still works, and going through that manual testing is tedious/inefficient. What if you could validate the PSP against the runtime behavior of your Kubernetes workload?
Using PSPs for Kubernetes native threat prevention
Pod Security Policies are actually a threat prevention mechanism. The security constraints they enforce prevent attacks from spreading across the cluster and block the typical container breakout approaches. PSPs can also enforce fine grained runtime security profiles like AppArmor, SELinux, seccomp, or Linux capabilities that provide a subset of the available root privileges to a process, all without having full root access.
Pod Security Policies are part of the Kubernetes platform, so when they validate Pod configuration and enforce runtime permissions, they don’t impact performance of the application workload. Other tools that tamper with the container infrastructure, or modify the host binaries and container images, can introduce security risks and potentially impact performance.
Implementing Pod Security Policies in production with Sysdig Secure
Sysdig Secure Kubernetes Policy Advisor assists users in both creating and validating Pod Security Policies.
The first step is to set up a new PSP simulation. You can have multiple simulations for different policies over different scopes (like a Kubernetes namespace).
Let’s create a New Simulation. Sysdig allows you to either upload a Pod Security Policy definition that you have created previously or help you build a new PSP if you provide a Kubernetes Deployment yaml definition:
Sysdig analyzes the requirements of the Pod spec in your Deployment definition and creates the least privilege PSP for your application. This controls if you allow privileged pods, users to run as the container, volumes, etc. You can fine tune the PSP and define the namespace against which you will run the simulation:
With the Kubernetes Policy Advisor, we have seen a significant decrease in the time spent configuring security policies.
The next step is to ensure the policies don’t break the application. Policy Advisor allows you to validate the policies prior to enforcement; this is what we call a simulation. Sysdig Secure will combine Deployment definition with runtime data to confirm if the PSP, effectively applied, would break the current requirements and behavior of the application:
The policy on the left would break the application because the nginx Deployment is a privileged Pod and has Host network access. You must decide whether to broaden the PSP to allow this behavior or elect to reduce the privileges of the Deployment to fit the policy. Regardless, you are detecting this before applying the PSP that would block your Pods from running and create a fracture on the application deployment.
Conclusions
Pod Security Policies are one of the most interesting ways to increase the security of your Kubernetes workloads. They let you identify and prevent issues in your applications, establishing a least privilege access model.
Using PSPs can be complex, and when deployed without validation, they can break your application or be too permissive. Sysdig Kubernetes Policy Advisor helps by auto-generating and validating Pod Security Policies so you can adopt them faster and more efficiently
Subscribe and get the latest updates
Thank You For Signing Up!
This form failed to load.
An ad blocking extension or strict tracking protection is preventing this form from loading. Please temporarily disable ad blocking or whitelist this site, use less restrictive tracking protection, or enable JavaScript to load this form. If you are unable to complete this form, please email us at [email protected] and a sales rep will contact you.
Let’s create a New Simulation. Sysdig allows you to either upload a Pod Security Policy definition that you have created previously or help you build a new PSP if you provide a Kubernetes Deployment yaml definition:
Sysdig analyzes the requirements of the Pod spec in your Deployment definition and creates the least privilege PSP for your application. This controls if you allow privileged pods, users to run as the container, volumes, etc. You can fine tune the PSP and define the namespace against which you will run the simulation:
With the Kubernetes Policy Advisor, we have seen a significant decrease in the time spent configuring security policies.
The next step is to ensure the policies don’t break the application. Policy Advisor allows you to validate the policies prior to enforcement; this is what we call a simulation. Sysdig Secure will combine Deployment definition with runtime data to confirm if the PSP, effectively applied, would break the current requirements and behavior of the application:
The policy on the left would break the application because the nginx Deployment is a privileged Pod and has Host network access. You must decide whether to broaden the PSP to allow this behavior or elect to reduce the privileges of the Deployment to fit the policy. Regardless, you are detecting this before applying the PSP that would block your Pods from running and create a fracture on the application deployment.