Kubernetes n'est pas à l'abri des ransomwares - et comment Illumio peut vous aider

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 peut empêcher les ransomwares de détourner votre cluster Kubernetes, évitant ainsi à votre organisation d'être la prochaine victime de cyberattaque à apparaître dans les nouvelles.  ‍

Comment les ransomwares se propagent dans Kubernetes

Dans les charges de travail sans conteneurs, le ransomware détourne un hôte et recherche ensuite des ports ouverts. Les ports courants qui sont ouverts par défaut sur de nombreuses charges de travail sont RDP, SSH et SMB. Il est facile pour un ransomware d'usurper les connexions sur ces ports et d'établir une connexion avec un hôte voisin. Une fois la connexion ouverte, le ransomware peut rapidement transmettre une charge utile malveillante à l'hôte suivant, en prendre le contrôle et rechercher des ports ouverts, répétant ce processus sur tous les hôtes voisins très rapidement.  

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.  

‍Les rançongicielsconstituent une menace majeure pour 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.  

‍Illumiopeut protéger de manière proactive contre les ransomwares dans Kubernetes.

Illumio applique la communication de la charge de travail à la fois au sein d'un cluster Kubernetes et du nœud sous-jacent.  

Au sein d'un cluster Kubernetes, Illumio appliquera la communication entre les espaces de noms, ou entre les espaces de noms et les charges de travail en dehors d'un contrôleur d'entrée, empêchant toute communication inutile entre les charges de travail. Contrairement à d'autres fournisseurs, la visibilité et la mise en application d'Illumio s'étendent à l'ensemble de la surface d'attaque hybride, et pas seulement aux conteneurs, ce qui permet aux équipes SecOps d'éliminer les silos de politiques et d'étendre les opérations existantes aux conteneurs, améliorant ainsi la cyber-résilience.

Entre les nœuds sous-jacents, Illumio appliquera également la communication de sorte que si un code malveillant inconnu s'échappe du cluster Kubernetes et descend jusqu'au nœud, ce code malveillant sera empêché de se propager à tous les nœuds voisins. Cela est possible parce qu'Illumio empêche l'établissement de sessions entre ces nœuds. Comme Illumio part du principe que les brèches sont inévitables, même à partir de menaces introduites au début de la chaîne d'approvisionnement des logiciels, les clusters Kubernetes sont sécurisés contre les ransomwares ayant l'intention de perturber l'infrastructure sous-jacente.  

‍Comment passer à la sécurité de gauche dans Kubernetes avec Illumio.

Dans le domaine de la cybersécurité, l'expression "shift-left" désigne l'introduction de solutions de sécurité au début du cycle de développement du code :  

• La partie droite du cycle de vie représente l'hébergement du code en tant qu'application et le déploiement d'un pare-feu devant celle-ci.

• La partie gauche représente la naissance de ce code au fur et à mesure de son développement.  

Si une charge de travail gérée contient une menace inconnue intégrée dans un code qui est ensuite lancé et tente de se propager aux hôtes voisins, Illumio empêchera cette menace de se propager.

Cela est vrai même si Illumio ne connaît pas l'intention de cette menace. La plupart des solutions de sécurité de type "détection et réponse" tentent de comprendre la nature d'une menace avant de prendre une décision. Mais Illumio ne perd pas de temps à essayer de comprendre cela avant de prendre une décision. La quantité de communication latérale requise par la plupart des charges de travail est limitée, et la plupart des ports ouverts doivent être fermés ou surveillés en permanence. Les appareils peuvent être mis en quarantaine et Illumio peut empêcher toute communication latérale sans qu'il soit nécessaire de savoir quel type de dommage est tenté.  

Kubernetes ne doit jamais être considéré comme immunisé contre les ransomwares. La prévention est la meilleure forme de remédiation, et Illumio empêche les ransomwares d'infecter toutes les charges de travail, même dans Kubernetes.

Vous voulez en savoir plus sur la façon dont Illumio peut sécuriser Kubernetes contre la propagation des ransomwares ? Contactez-nous dès aujourd'hui pour une consultation et une démonstration gratuites.