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

Learn the 3 Key Elements to Successfully Shifting your Security Left - Live Webinar

Exit icon Register Now

Governing your Containers with Pod Security Policies

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

OVERVIEW

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.

 
Example-psp.yml
	apiVersion: policy/v1betal
	kind: PodSecurityPolicy
	metadata:
		name: example
	spec:
	    privileged: false
	    seLinux:
			rule: RunAsAny
	    supplementalGroup:
			rule: RunAsAny
	    runAsUser:
			rule: MustRunAsNonRoot
	    fsGroup:
			rule: RunAsAny
	    volumes: 
	    - ‘ * ’

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.

Conclusion

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

How Shifting Left Helps Organizations Mitigate Cloud-Native Security Risks

By shifting-left, organizations are instilling security measures into the DevOps workflows, not just at the tail-end of the process. Shift-left now for a more agile, friction-free & secure environment

Read more
Breaking Down the Complexity of Cloud Native Security for Leadership

Securing Cloud-Native applications can be complex because of the volume of skills and knowledge required

Read more
Securing Cloud-Native Applications is the New Foundation to Digital Transformation Success

Security can no longer remain on its own independent island & must be incorporated into the rest of the stack in to maintain a hardened infrastructure

Read more

Start Your 30-day Free Trial Today!

Automate your Kubernetes cluster optimization in minutes.

Get Started View Pricing
No Card Required