The increasing popularity of traditional cloud computing technologies such as server-less, on-demand compute and containerized environments has made technologies like Kubernetes part of our daily vernacular as it relates to running our applications and workloads.

Kubernetes solves many of the problems with managing containers at-scale. Automation, orchestration, elasticity are a few of the major draws for organizations to leverage Kubernetes, either in the cloud, on premises, or hybrid. Kubernetes creates a network abstraction layer around the siloed containers that allows for this facilitation. Think of it as a wide open highway that allows you to route throughout the many containers that are actually performing your workloads.  From web servers to database servers, these containers are the flexible, scalable workhorses for an organization.

With great accessibility comes a drawback, however. Should an attacker gain access to a pod, a node or an internal Kubernetes service, then part or all of that cluster is at risk of compromise. Couple that with the fact that in many instances Docker containers are actually running scaled down Linux operating systems like CoreOS or Alpine Linux. Should one of those containers become exposed to the Internet (and many workloads require access to the Internet), you now have an exposed attack surface that expands along with the exposed workloads themselves.

Last week the most severe Kubernetes vulnerability discovered to-date was announced, CVE-2018-1002105. It scored a 9.8 out of a possible 10.0 on the CVSS severity score...which is unprecedented.  In a nutshell this vulnerability allows an attacker to send an unauthenticated API request to the Kubernetes API service. Despite being unauthenticated, the access request leaves a remaining TCP connection open for the API backend server. This connection then allows an attacker to exploit the connection to run commands that would grant them complete access to do anything they desire on the cluster.  Scary stuff!

This vulnerability underscores the fact that organizations need to have both the visibility to see such traffic and also the analytics to know if the traffic represents a risk or compromise. Suppose you unknowingly expose a group of Apache Kubernetes pods to the Internet to perform their intended web services and a new vulnerability is exploited on that pod, like Struts. The attacker would then have root access on the pod to perform recon, install necessary tools and pivot around the cluster. And, if they are aware of the API vulnerability, then it's a walk in the park for them to take full control of your cluster in a matter of minutes.

Not a good day for an organization if -and more likely when -this occurs. Data theft, compute theft, skyrocketing bills....just to name a few, are immediate side effects to a takeover of this magnitude.  So how can Stealthwatch Cloud help in this scenario and similar potential exploits?

How Stealthwatch Cloud Protects Kubernetes Environments 

Stealthwatch Cloud deploys into a Kubernetes cluster via an agentless sensor that leverages Kubernetes itself to automatically deploy, expand and contract across a cluster. No user interaction is required. The solution deploys instantly to every node in a cluster and exposes every pod and the communication with those pods between internal nodes and clusters, as well as externally. This allows for an unprecedented level of visibility into everything a cluster is doing, from pods communicating to the internet to worker nodes communicating internally with the master node. We then add entity modeling which compares new behavior to previous behavior and machine learning based anomaly detection to alert on IOC's throughout the Kill Chain to alert on over 60 indicators of suspicious activity across a cluster.

Hypothetically speaking, if one of your Kubernetes clusters were compromised, Stealthwatch Cloud would send alerts in real-time on various aforementioned activities. The tool would alert on the initial pod reconnaissance, and on connection activity once the pod was exploited. If the attacker moved towards the API server, Stealthwatch Cloud would alert on internal reconnaissance, suspicious connections to the API server itself, further data staging, data exfiltration and a variety of other alerts that would indicate a change from known good behavior across every component of a Kubernetes cluster...all in an agentless, automated, scalable solution.

Find out more about how Stealthwatch Cloud can protect your Kubernetes environments in this recent blog post, learn more about Stealthwatch Cloud on our product page -or to see how it works in your environment by starting a Free Trial today.