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 developer 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.
Read more: https://bit.ly/3MJxYoK
You can also read this: 7 Key Findings from the 2022 SaaS Security Survey Report