Pod Security Policies in production with Sysdig’s Kubernetes Policy Advisor
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.
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.
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.