Yes, Containers Are Terrific, But Watch the Security Risks

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^[1].

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^[2]
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^[3]
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^[4]
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.