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.

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

👇👇

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.