Protect yourself from bad neighbors in the cloud
Smart scheduling can minimize security risks for containers that share a common host.
Smart scheduling can minimize security risks for containers that share a common host.
Cloud computing has given companies the freedom to flexibly adapt their computing needs to the moment. Containerized workloads, as a result, have become the new norm, with cloud providers cramming as many containers as possible into a cluster to maximize efficiency.
This increased density has helped to lower costs, but it leaves containers more vulnerable to malicious attacks through their shared host. Just as the risk of having a bad neighbor goes up in a crowded high-rise building, the same principle applies to a computing cluster packed with pods of containers.
Your pod may be secure, but if a neighbor intentionally or unintentionally compromises the host kernel, it can open you and everyone else on the host to an attack.
System calls provide a relatively easy opening for “bad neighbors” to exploit weaknesses in the host kernel and gain access to neighboring pods of containers. The recent Dirty Pipe attack, and the earlier Dirty Cow exploit, used vulnerable system calls to overwrite permission files, giving the attackers access to privileged information in other pods.
To minimize the impact of similar attacks, we’ve designed a security-aware scheduling scheme for Kubernetes called SySched that places pods in dedicated processing nodes based on their system call usage profile. The strategic placement of pods can minimize their exposure to extraneous system calls on a host which can be exploited by bad neighbors. Security-aware scheduling effectively isolates risky pods, reducing risk across the cluster.
We discuss this work in a new paper at ACM’s Asia Conference on Computer and Communications Security. Security schemes like Linux’s seccomp are necessary, but don’t go far enough to protect the pod. By co-locating pods based on their system call usage, SySched, can limit the extent of an attack.
In our research, we found that about 40% fewer pods, and a third fewer processing nodes, would be impacted by a potential attack using SySched over Kubernetes’ default scheduler. This means a successful attack would find significantly fewer pods to prey upon. SySched accomplishes this feat by taking a cluster-wide approach to security.
We are engaging with the Kubernetes community to upstream our code. Look for its full acceptance in the coming months on GitHub.