Introduction

In a recent blog post Yossi Weizman talks about the Attack matrix for Kubernetes and i had a couple of thoughts about it. As Yossi rightly says, Kubernetes is becoming a vital part in the compute stack of many companies. What i hear in my network and during sessions with IT security teams is that they face new challenges with Kubernetes-based orchestration platforms. The container platforms are also perceived like a black box for traditional networking and IT security folks, so it makes sense to understand the security risks that are inherent to those platforms first.

Mitre ATT&CK

Mitre ATT&CK is a great tool to help you assess tactics, techniques and mitigations for attack patterns and i already posted how the attack matrix can help you assess how segmentation helps to mitigate a lot of attacks.

Mapping Kubernetes

Microsoft Azure Security Center has mapped the security landscape of Kubernetes and found out that the tactics are actually very similar to attacks on traditional (legacy) infrastructure. The techniques they present are to a large part not in the Mitre ATT&CK framework yet, but may find their way in.

What is striking about the matrix is the number of ways to move laterally on the default configuration of container orchestration platforms like Kubernetes. Microsoft mentions the following ways to move laterally and for discovery. Many of the mentioned services like kubelet and the k8s API server are not protected in default configurations and may be open to anyone, including PODs on the Kubernetes platform.

Discovery

• Access the Kubernetes API Server
• Access Kubelet API
• Network mapping
• Access Kubernetes dashboard
• Instance Metadata API

4 out of 5 of the above can be solved by not allowing network access to those resources from the POD network (Access to API and Kubelet API, Network mapping, access to the kubernetes dashboard).

To read more about Kubernetes networking, please take a look at this article on kubernetes.io. The number of available CNI plugin gives you a good impression of the complexity of controlling Kubernetes networking.

Moving laterally

• Access cloud resources
• Container service account
• Cluster internal networking
• Application credentials in configuration files
• Writable volume mounts on the host
• Access Kubernetes dashboard
• Access tiller endpoint

Same goes for lateral movement, access to the tiller endpoint and the dashboard is not required and can safely be shut down through network policy, the cluster internal networking shouldn’t be exposed other than through the CNI as well and can be shut down by network policy as well.

The techniques for initial access, execution, persistence and privilege escalation can easily be mitigated by following Kubernetes best practices and working on a hardened configuration, scanning images, watching your supply chain, just as in any legacy infrastructure environment. The speed of Kubernetes deployment and integration usually is higher and more automated, so mitigation will be easier if it is part of the toolchain.

Can Segmentation help?

After reading the initial assessment it is clear for me that segmentation can help to secure large parts of the Kubernetes infrastructure because attacks can be stopped in a really simple and effective way by not allowing connectivity between services that don’t ever need to connect.

One of the biggest problem in the relatively young container orchestration platforms is that they hardly integrate with existing tools like your L2/L3 SDN platform easily or your firewalling infrastructure.

The other problem i see is that the platforms do not impose segmentation policies as a default and that the container orchestration cluster is operated as a black box with relatively low security standards. For example in a standard kubernetes environment any container can access the Kubernetes API server which it really should not be able to connect to by default.

• ← Previous Post