Governing your Containers with Pod Security 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?

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.