Containers revolutionized the development process, acting as a cornerstone for DevOps initiatives, but containers bring complex security risks that are not always obvious. Organizations that don’t mitigate these risks are vulnerable to attack.
In this article, we outline how containers contributed to agile development, which unique security risks containers bring into the picture – and what organizations can do to secure containerized workloads, going beyond DevOps to achieve DevSecOps.
Why did containers catch on so fast?
Containers are, in many ways, the evolution of virtualization. The goal was to speed up the development process, creating a more agile route from development through to testing and implementation – a method that’s more lightweight than using full-blown virtual machines, anyway.
At the core of this issue is application compatibility, as applications require certain versions of libraries – which could clash with the requirements of other applications. Containers fixed this problem and happened to link up well with development processes and the management infrastructure that drives these processes.
Containers do their job by taking virtualization to the next level. Virtualization abstracts the hardware layer, whereas containers abstract the operating system layer, essentially virtualizing the role of the OS. Containerization works by packaging applications into “containers” that include all the necessary libraries to make an application work, while keeping applications unaware of each other as each app thinks it has the OS to itself.
Functionally, containers are quite simple – a container is just a text file with a description outlining which components should be included in an instance. This simplicity and the more lightweight nature of a container make it easy to use automation (orchestration) tools for deployment throughout the development lifecycle.
DevOps for the win… but security matters too
Containers have the power to significantly boost development efficiency – acting as the keys that unlock DevOps. That’s likely one of the major reasons why containers have caught on so broadly, with Gartner estimating that by 2023, 70% of organizations will be running containerized workloads.
The process of developing, testing, and deploying apps used to be filled with obstacles, with a constant back and forth between developers and the teams looking after infrastructure. Today, thanks to containers, developers can build and test in an environment that works and simply ship the finished code alongside a spec that defines that environment.
On the operational side teams merely execute this specification to create a matching environment that is ready to use. “Yes, but it works on my machine…” never helped fixed the problem – but today, that’s an expression developers no longer need to use because there are no environmental problems to debug.
So, yes, DevOps means rapid development. But there’s a missing component: security. This is why we’re increasingly hearing about DevSecOps as it evolves from DevOps because developers have noticed that the DevOps model alone does not sufficiently address security concerns.
Containers introduce several security risks
Containers simplify the development process but introduce complexity into the security picture. When you tightly pack an entire operating environment into a container only to distribute it widely you also increase the attack surface and open the door to different attack vectors. Any vulnerable libraries packaged with the container will spread these vulnerabilities across countless workloads.
There are several risks. One is a “supply chain attack” where a malevolent actor mounts an attack not by messing with your application, but by modifying one of the packages or components that is supplied with your application. So, teams looking after development efforts need to assess the application they are developing and every library pulled in as a dependency by the container configuration.
The risks to container security also involve the tools that enable containers – from Dockers though to orchestration tools such as Kubernetes, as these tools need to be monitored and protected. You shouldn’t, for example, allow sysadmins to run Docker containers as root. Likewise, you need to keep a close guard of your container registries to make sure that these aren’t compromised.
Kernel security at the core of container security
Some of the container-related security risks are less visible than others. Every container needs access to a kernel – after all, containers are just a type of advanced process isolation. But it is easy to miss the fact that all containers rely on the same kernel – it doesn’t matter that the applications inside the containers are segregated from each other.
The kernel that apps in a container see is the same as the kernel that the host relies on to operate. It brings a couple of issues. If the kernel on the host that supports the container is vulnerable to an exploit, this vulnerability may be exploited by starting an attack from an app inside a container.
So fact that the kernel is shared by all the containers on the host means that a flawed kernel must be patched rapidly, or all containers can quickly be affected by the vulnerability.
Yet again, it comes down to patching
Keeping the host’s kernel up to date is, therefore, an important step in ensuring safe and secure container operations. And it’s not just the kernel that needs patching, patches must be applied to the libraries pulled in by a container. But, as we know, consistently patching is easier said than done. That’s probably why one study found that 75% of containers analyzed contained a vulnerability that is classified as critical or high risk.
These vulnerabilities can lead to, for example, breakout attacks where an attacker relies on a flawed library within a container to be able to execute code outside of the container. By breaching one container the attacker can eventually reach their intended target whether that’s the host system or an application in another container.
In the context of containers maintaining secure libraries can be a real headache – somebody needs to track new vulnerabilities as well as what’s been patched and what hasn’t. The process is laborious, but it also requires specialist skills which is something your organization would need to acquire if it doesn’t have them already.
Given the value of regular, consistent patching those reasons shouldn’t be enough to cause the sort of hit-and-miss patching routines that we see, but – particularly when thinking about the OS kernel – the disruption of the required reboots and the associated need to maintain downtime windows can significantly delay patching. Live kernel patching helps mitigate this problem, but it’s not yet deployed by all organizations.
Always include security goals in your container ops
It’s common for cutting-edge tech to introduce new complications when it comes to information security. New tools commonly lead to new and novel exploits. That’s true for containers too and while it doesn’t undermine the overall value of using containers in your workloads it does mean that you need to keep an eye on the risks posed by containers.
Educating your developers and sysadmins about the common flaws in container security and the best practices that mitigate these flaws is a start. Patching is another important aspect. As always, putting in place the right steps to mitigate cybersecurity flaws will help protect your organization – and allow your team to benefit from that cutting-edge tech without suffering sleepless nights.
