![]() Let’s start with what Kubernetes administrators control least: the hypervisor and the firmware. So it’s not enough to download patched software, you also need to make sure that the memory image is patched. Does it mean that my hypervisor is patched? No! To execute a program, its binary needs to be loaded from disk – or ROM, if we talk about firmware – into memory. Say I downloaded and installed a new qemu binary. But what about the underlying Kubernetes cluster, the VM Linux kernel, the hypervisor and the hardware’s firmware?įirst, let’s make a distinction between applying a security patch and actually making sure the patch is live. Change the image in the Deployment to trigger a zero-downtime rolling update. Patching an application in Kubernetes is rather simple. If not treated properly, eventually an attacker can get their hands on precious data. Each vulnerability is like a door left unlocked. The consequences are always the same, a weaker application’s security posture. Without getting into too many details, Kubernetes and container runtimes also regularly feature security bugs. Once they manage to exploit a vulnerability in one application component they can get a hold of another application component, completely bypassing NetworkPolicies. Impact: Escape container vulnerabilities allow an attacker to move laterally. Unfortunately, just the next 6 months have seen 3 escape container vulnerabilities ( one, two and three). The Linux kernel enforces containerization, e.g., making sure that each process gets its own network stack and filesystem, and cannot interfere with other containers or – worse – the host network stack and filesystem. An attacker managing to escape a VM can potentially steal data from your VM. Impact: In public clouds, VMs on the same server typically belong to different cloud customers. For example, both qemu and VMware ESXi used to have several escape VM vulnerabilities. Unfortunately, this layer has also seen its share of security bugs. The Hypervisor ensures that Virtual Machines (VMs) running on the same server are well-behaved and isolated from one another. If this doesn’t work properly, your whole security posture falls like a house of cards. Impact: Much of the software above relies on the hardware for enforcing security boundaries. For example, memory used to be vulnerable to row hammer CPUs to the likes of Spectre – not to be confused with Alan Walker’s song – and Meltdown. Fortunately, hardware doesn’t really feature vulnerabilities … except when it does. Hardwareįirst, you have the hardware – CPU, memory, network, disk – tireless transistors pushing bits to the left and right. Let us look at the various tech stack layers from metal to application, and review which ones need security patching. Vulnerabilities – also called security bugs – are weaknesses in the tech stack that – if left unchecked – can be used to compromise data security. Vulnerabilities in a typical Kubernetes Stack Layers. Through empathy and technical solutions, we highlight how administrators and application developers can collaborate to keep the application both up and secure. Part of the solution involves rebooting Nodes, which may be disruptive to the application. ![]() In this post, we will highlight how you can keep your Kubernetes cluster patched. While many organisations are doing a great job patching their application dependencies, all that effort risks being wasted if the underlying Kubernetes cluster is left unattended. Part of keeping personal data safe is vulnerability management, i.e., ensuring security patches are applied throughout the whole tech stack. As recently highlighted by the Swedish Authority for Privacy Protection (IMY), data breaches are on the rise in particular in the healthcare sector.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |