Businesses leaving their Kubernetes containers exposed to ransomware
As businesses look for faster and more flexible development frameworks, the use of containers and Kubernetes (K8s) continues to rise. While Kubernetes theoretically has several security advantages compared to traditional applications, it remains one of the top concerns for organizations on their cloud-native journey. This concern is fairly valid it seems. A recent report found that Kubernetes clusters belonging to more than 350 organizations, including several Fortune 500 businesses, were openly accessible and exposed to cyberattacks like ransomware. So, why are organizations struggling with Kubernetes security on this scale?
Global Field CTO at Veeam.
Fail fast
People often describe security as a race. Typically, this refers to security teams competing to stay one step ahead of bad actors – adopting new technology and responding to new techniques and vulnerabilities. However, sometimes it’s just as much a race to keep up with your own organization as it adopts new technology. Either way, security is expected to keep up with the pace and ensure the business is safe, whatever direction it chooses to go.
A recent report from Enterprise Strategy Group found that Kubernetes usage is about to hit a “turning point” – with 82% of organizations using containers by the end of 2024. Containers have been in use for more than a decade. Although the adoption of Kubernetes hasn’t been exactly rapid, when an organization decides to take the plunge into something new, there’s always a learning curve. With Kubernetes, there are unseen pitfalls that developers and security teams can miss as they race to get new applications off the ground.
The compromise between speed and security is a familiar one for development teams, and since one of the main drivers for container adoption is speed and agility, it is unsurprising that rapid Kubernetes adoption has left some open doors. Unsecure development is never a conscious decision, but if businesses are feeling the pressure to add new features or develop new products from scratch, something has to give.
Containing the chaos
Kubernetes vulnerabilities often come down to misconfiguration during the design and development phase. The already-mentioned timeline is a factor here, but a lack of K8-specific knowledge is often the key ingredient.
The report from Aqua Security that identified hundreds of vulnerable container environments was largely made up of two key misconfigurations. The first one involves anonymous users only requiring a single layer of authentication, which if passed can grant anonymous access with privileges including admin privileges. It’s similar to having a flimsy lock on a sports car, with the keys in the ignition. The other common vulnerability is misconfigured clusters, exposing clusters to the public in some places. This can enable bad actors to leverage tools such as ‘Kubectl’ to simply connect to your Kubernetes cluster and start wreaking havoc.
This issue isn’t unique to K8s, leaving applications exposed to the internet when they don’t need to be is a common attack vector across all kinds of applications. Internet access is another door for attackers to break in through. If the door didn’t exist, it wouldn’t be an issue. This comes back to zero trust or the “principle of least privilege” – even with cloud-native applications, not everything should be accessible at all times.
Backing it up
Again, professionals don’t wake up one day and decide to develop security flaws in their applications. It’s just a result of knowledge gaps and fast development timelines. In time, as developers become more experienced with cloud-native platforms, these issues will become less common. This makes the need for robust backup and recovery processes even greater. Cyber resiliency is multi-layered. You can never be completely confident in your first line of defense (application security) so it’s vital businesses have things in place to fall back on.
Unfortunately, this is another area of Kubernetes where we are seeing a steep learning curve. The latest Enterprise Strategy Group report on Kubernetes protection found that 33% of organizations using Kubernetes have carried on using the same data protection tools and processes as they would for normal applications. This is a problem. Cloud-native applications require cloud-native backup solutions. While these companies will have backups in place, so may assume they’re safe, traditional backups can’t track the moving part of Kubernetes. That means when you try and recover the data it can lead to performance issues and data loss.
If security and recovery are fundamentally flawed, businesses are leaving themselves fully exposed to attacks like ransomware. With September recorded as one of the biggest months of ransomware attacks ever, businesses have to ensure they’re getting this right. This isn’t an appeal to avoid or stop using Kubernetes or container-based applications, far from it.
However, security needs to catch up with any new development practices, or criminals will pour through the gaps. These environments are complex to master alone, which is why DevSecOps is so crucial. Collaboration between development and security teams can keep infrastructure secure from the off, and keep businesses running, safe from the never-ending wave of ransomware.
We’ve featured the best IT infrastructure management service.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
As businesses look for faster and more flexible development frameworks, the use of containers and Kubernetes (K8s) continues to rise. While Kubernetes theoretically has several security advantages compared to traditional applications, it remains one of the top concerns for organizations on their cloud-native journey. This concern is fairly valid it…
