<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

Magalix Introduces the Cloud-Native Application Policy Pack

Exit icon Learn More

Governing your Containers with Pod Security Policies

DevOps Kubernetes Governance Policies
Governing your Containers with Pod Security Policies
DevOps Kubernetes Governance Policies


We all know running anything as root is bad practice. We also know giving an authorized user more access than necessary is also bad practice. In a Kubernetes world, credentials and permission are handled by RBAC (role-based access control). But what about the pods themselves? Did you know that unless specified, the process inside your container is most likely running as root? To top that off, if someone deploys a privileged pod, the container now has root access to the node it’s scheduled on. Sounds like a security risk, doesn’t it?

Governing your Containers with Pod Security Policies

Securing your Workloads

At the heart of your Cloud-Native stack is Kubernetes. As development teams gain more access to self-serve, it becomes increasingly challenging to monitor every single pod, or deployment that happens across your organization. Even if you had spare cycles, you would have to:

  • Examine every Dockerfile to see which user is running the process,
  • Understand what user IDs are available within the container
  • Search each deployment chain to see if containers are getting run with escalated privileges
  • Verify each deployment isn’t using the root user and has a user and group set
  • Manage access to volumes and various paths
  • Double check the usage of host ports
  • Ensure nobody is giving themselves additional Linux capabilities

Checking these just once won’t be sufficient. There would be a need to continuously check for these configurations, across all of your clusters, all the time. Not to mention all the new microservices that will be developed this year, this month, and this sprint! Inspecting even one of the items on the aforementioned list all the time would not only be impossible, but unnecessary.

Kubernetes Pod Security Policies

Used in conjunction with Kubernetes Role-Based Access Control (RBAC), Kubernetes Pod Security Policies (PSP) automatically perform the proper gatekeeping for pod admittance based on the policy you define. In other words, if it doesn’t meet your requirements, it doesn’t get scheduled.

	apiVersion: policy/v1betal
	kind: PodSecurityPolicy
		name: example
	    privileged: false
			rule: RunAsAny
			rule: RunAsAny
			rule: MustRunAsNonRoot
			rule: RunAsAny
	    - ‘ * ’

A basic Pod Security Policy not allowing containers to run as rootPSPs require an RBAC role and binding (cluster role and binding can work too) that allows a service account permission to use the policy. It then applies the policies in alphabetical order based on the policy name.Once configured and enabled, the PSP will work in real time so you don’t have to go out of your way to police your pods. Using the code snippet above as an example, with this policy applied your development teams would have to explicitly define a user other than root if they wanted their pods to run. In their container, they would need to use a user other than root, and then specify that non-root user in the deployment. Since PSPs are cluster wide, you can set it for each cluster and not spend time worrying about governing any violations of these policies.


Help your team get up to speed with guidance on complex governance and compliance issues.


Enforce Policy Across All Of Your K8s Clusters With A Single Click.

Potential Pitfalls

Managing PSPs and RBAC can be complex.

If you don’t have everything set just correctly, you can prevent properly configured pods from deploying at all. A policy that is too restrictive may present challenges as some containers that are pulled from public registries are using the root user. In these cases, modification and upkeep will need to be maintained by you. If the upstream image changes, you will need to merge those changes into yours. The same challenges exist for Helm based deployments.

Another potential pitfall with PSPs is that testing your policies requires deploying them somewhere and validating them. To do this correctly, you would need to apply the same configurations from your live cluster to your test one. If you are managing different clusters for different teams, it might require additional cluster building automation and configuration management.

One last pitfall is managing multiple policies in one cluster. One obvious reason you might have multiple policies is that one type of pod needs more privileges than the others. A way to achieve mixing-and-matching is by crafting your RBAC policies, service accounts, and PSPs with specific workloads. Since PSPs are cluster wide, you’ll have to come up with your own strategy that best suits your requirements.


For the same reasons you don’t give out root access, you also need your containers to run without unnecessary privileges. Prevent your teams from unknowingly running containers with elevated permissions and configurations to help safeguard your Kubernetes cluster from within. The last thing you need right now is a rogue container deleting all the files on an NFS mount so enable PSPs today, so you won’t be restoring services tomorrow.

Comments and Responses

Related Articles

7 Notable and Costly Security Breaches

Learn some notable security breaches that happened a few years ago, the root causes, and how Magalix can help protect your Kubernetes infrastructure

Read more
Security Context Settings Help Mitigate Kubernetes Risk

Kubernetes isn't secure by default and is attacked relentlessly. But security context settings help DevOps teams better secure their pods and containers.

Read more
DevOps Policy as Code
Cloud Data Asset Management and Tagging Cloud Resources

Learn how cloud data asset management enables organizations to manage, optimize and secure their cloud data assets and resource tagging is a key part of it

Read more