Stopping attacks against Kubernetes due to hostPath Volume Mounts using Pod SecurityPolicies— Part 2

This is Part 2 of a 2 part series on security implications of insecure hostPath volume mount in Kubernetes. Here we discuss about the attack mitigation using PodSecurityPolicy — Read Part-1 demonstrating the attack

Mitigation

It was possible to breakout of Namespace restrictions in this scenario due to the risky hostPath mount that allows full access to the underlying Node.

Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1

The issue can be mitigated using an appropriate PodSecurityPolicy. The official Kubernetes docs contain some great examples

Pod Security Policies

To use PodSecurityPolicy, ensure it is enabled in the AdmissionController of the master node.

For managed clusters, refer to the provider specific documentation. For GKE, PSP can be enabled using the command below

gcloud beta container clusters update CLUSTER_NAME --enable-pod-security-policy

To test this, we will deploy our PSP as Cluster Administrator

Switch config to cluster-admin

export KUBECONFIG=k8s-research-admin-kubeconfig.yaml

• Create a restricted PodSecurityPolicy (PSP)
• Create a ClusterRole to enforce use of our restricted PSP
• Create a ClusterRoleBinding to bind the ClusterRole to developer-sa Service Account

kubectl apply -f psp.yml

This creates the required resources in the cluster based on our PodSecurityPolicy.

podsecuritypolicy.policy/developers-psp created
clusterrole.rbac.authorization.k8s.io/developers-psp-cluster-role created
clusterrolebinding.rbac.authorization.k8s.io/developers-sa-psp-binding created

Now we can switch back to our developer-sa Service Account and retry the same attack described earlier

export KUBECONFIG=./developer-kubeconfig
kubectl -n developers apply -f ./pod-to-node.yml

Instead of the Pod being created, we get an error indicating restrictions enforced by PSP.

Error from server (Forbidden): error when creating "./pod-to-node.yml": pods "attacker-pod" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID: Invalid value: true: Host PID is not allowed to be used spec.securityContext.hostIPC: Invalid value: true: Host IPC is not allowed to be used spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed spec.containers[0].securityContext.allowPrivilegeEscalation: Invalid value: true: Allowing privilege escalation for containers is not allowed]

Conclusion

We have seen how we can ensure hostPath insecurities don’t compromise the security of our Kubernetes cluster. This is a very important topic and has many naunces. Keep up with Kubernetes security by following the documentation and our blog.

At Appsecco we provide advice, testing and training around software, infra, web and mobile apps, especially that are cloud hosted. We specialise in auditing Kubernetes clusters as per the CIS Benchmark to create a picture of the current state of security. If you are confident about the security of your cluster get assurance for withstanding real world attackers by getting us to do a black box pentest.

We run a hands-on training course “Attacking and Auditing Kubernetes Clusters” for cluster operators and pentesters.

Drop us an email, contact@appsecco.com if you would like us to assess the security of your K8S infrastructure or if you would like your security team trained in advanced pentesting techniques against K8S.

https://appsecco.com