Kubernetes Isn’t Immune to Ransomware – And How Illumio Can Help

Ransomware is not a problem in Kubernetes, right? Containers constructs are so dynamic and ephemeral that there is little risk that ransomware would have time to highjack a pod, for example, and then try to laterally propagate malicious payloads between namespaces. Pods spin up and spin down so dynamically that ransomware is of little concern in Kubernetes, thus my cluster is safe from this specific cybersecurity threat, right?

Unfortunately, this assumption has been proven wrong too many times. Ransomware tends to work differently in Kubernetes than it does outside of containers clusters, but it is a very real cybersecurity risk that DevSecOps architects can’t afford to ignore. Ransomware can do very real damage in a Kubernetes cluster, and the best form of remediation is prevention.

Illumio can prevent ransomware from hijacking your Kubernetes cluster, stopping your organization from being the next cyberattack victim to appear in the news.  ‍

How ransomware propagates in Kubernetes

In non-containers workloads, ransomware will hijack a host and then look for open ports. Common ports which are open by default on many workloads are RDP, SSH, and SMB. It is trivial for ransomware to spoof connections over these ports and establish a connection to a neighboring host. Once the connection is open, ransomware can quickly deliver malicious payload to the next host, take control of it, and look for open ports, repeating this process across all neighboring hosts very quickly.  

This propagation between hosts can happen faster than most detect-and-response malware protection solutions can identify and respond to. Before long, the entire infrastructure can be taken hostage.  

In Kubernetes, hosts – also known as “nodes” – are virtual machines (VMs) or bare-metal hosts which run containers code. They create a layer of abstraction above the node’s underlying operating system (OS). A cluster is created when pods and services are associated with a namespace, and that namespace contains all of the code and libraries required by the application running within it. The constructs within a namespace are dynamic: As compute resources are scaled horizontally, pods will spin up and execute code and then can be quickly spin down again, only to be spun back up at a later time with a different IP address.  

The lifetime of a pod can be very brief, and most pods don’t run open ports such as RDP or SSH. This is because pods don’t tend to use these protocols to communicate with other pods. Thus, ransomware is often perceived as being of little relevance within a cluster.  

‍Ransomware is a major threat in Kubernetes‍

However, ransomware can quickly become a cyber disaster in a Kubernetes cluster. Malicious code can be introduced early in the code development life cycle but not get detected because they are not yet running. Malicious payloads can also be introduced into a Kubernetes cluster via exposed APIs, weak authentication settings, un-patched software, or perhaps the most common risk: misconfigured settings.  

Cyber threats can be introduced anywhere in the software supply chain. For example, if a container’s image is downloaded from an open-source repository; and then run within a cluster, that image can contain embedded code which can be executed and “escape” from a pod into the underlying node. It will then deploy ransomware into that underlying node. At that point, ransomware can hijack that node and establish connections over open ports to neighboring nodes, allowing the threat to quickly hijack or encrypt all underlying nodes hosting the Kubernetes cluster.  

This can cause the applications running on worker nodes to become “bricked” – effectively shut down. If the code escapes into an underlying master node, the control plane of the Kubernetes cluster can be hijacked and will risk bricking the entire cluster. A small problem introduced early in the code development lifecycle can quickly become a major disaster.  

An example of this type of malware is Siloscape, discovered in March of 2021. It uses vulnerabilities in little-documented thread processes to access the underlying node, and then is able to access kubectl to execute commands which will spread itself to neighboring nodes. This is a stark example of why the control plane of Kubernetes nodes needs to be protected, and access limited by other processes. Illumio is able to enforce access to specific processes on a host, limiting who has access to them.  

‍Illumio can proactively protect against ransomware in Kubernetes

Illumio enforces workload communication both within a Kubernetes cluster and the underlying node.  

Within a Kubernetes cluster, Illumio will enforce communication between namespaces, or between namespaces and workloads outside of an ingress controller, preventing unnecessary communication between workloads. Unlike other vendors, Illumio visibility and enforcement extends across the entire hybrid attack surface, not just containers, allowing SecOps teams to eliminate policy silos and extend existing operations into containers, improving cyber resilience.

Between underlying nodes, Illumio will also enforce communication so that if unknown malicious code escapes from the Kubernetes cluster and down to the node, that malicious code will be prevented from propagating to any neighboring nodes. This is possible because Illumio prevents sessions from being established between those nodes. Since Illumio assumes breaches are inevitable, even from threats introduced at the beginning of the software supply chain, Kubernetes clusters are secured against ransomware with intentions to disrupt the underlying infrastructure.  

‍How to shift-left security in Kubernetes with Illumio

In cybersecurity, shift-left refers to introducing security solutions at the beginning of the code development lifecycle:  

• The right side of the lifecycle represents hosting code as an application and deploying a firewall in front of it.

• The left side represents the birth of that code as it is developed.  

If any managed workload contains an unknown threat embedded in code which later launches and tries to spread to neighboring hosts, Illumio will prevent that threat from spreading.

This is true even without Illumio knowing the intention of that threat. Most detect-and-respond security solutions attempt to understand the nature of a threat before making a decision. But Illumio doesn’t waste time trying to understand this before making a decision. The amount of lateral communication required by most workloads is limited, and most open ports should be closed or continuously monitored. Devices can be quarantined and Illumio can prevent all lateral communication without needing to know what type of damage is being attempted.  

Kubernetes should never be considered immune to ransomware. Prevention is the best form of remediation, and Illumio prevents ransomware from infecting all workloads, even in Kubernetes.

Want to learn more about how Illumio can secure Kubernetes from the spread of ransomware? Contact us today for a free consultation and demo.