Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Our partner program is designed with flexibility in mind for partners who are at various stages of their business lifecycle. With financial investment and dedicated resources, you will continue to grow with TuxCare.
Would you like to work with a leader in open source and Linux security that values innovation and partnerships?
Partners receive benefits that are designed to reward the commitment that they have made to the sale of our products and services.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
Follow Us on Social
OS virtualization was a huge step forward for the delivery of large-scale enterprise computing applications. But virtual machines were just the start. Containers take virtualization a step further, delivering unprecedented flexibility as applications become almost seamlessly transportable.
However, containers come with a hidden security risk that derives from the nature of containerization. In this article, we discuss the role of containerization in the enterprise, explain why contains can be an enterprise security risk – and point to effective solutions.
What Is A Containerized Workload?
From Virtualization To Containerization
How Containers Are Used In The Enterprise
The Relation Between Containers And The Host
Isolated, Yes, But Still Vulnerable
Unpatched Kernels: A Hidden Container Security Risk?
The Problem With Patching Kernels
KernelCare Live Patching Integration
Other Tips For Container Kernel Security
To understand why containers can be a security risk you need to understand what exactly a container is – and what a containerized workload is.
First, a step back to virtualization. Not that long ago, a computer OS and the hardware it runs on would be inextricably linked – one physical server is associated with one operating system. Virtualization changes this by inserting a layer between the hardware and the operating system that runs on it. It removes the one to one, binding relationship between the operating system and hardware.
To a virtualized operating system it looks as if it is the only operating system on the hardware. In the background, the virtualization software (the hypervisor) manages the abstraction layer to ensure each OS is unaware of the presence of other operating systems on the machine.
Thanks to virtualization you can run several operating systems on one machine, and easily transport an operating system from one machine to another. As a result, you enjoy a boost in efficiency and flexibility.
We point to virtualization because it helps explain what containerization does. Where virtualization puts a layer of abstraction between the physical equipment and the operating system, containerization adds an abstraction layer between the operating system – and the application.
Essentially, where virtualization virtualizes hardware, containerization virtualizes the operating system. With containerization, each application is encapsulated in an isolated unit called a container. Containerized applications do not share the operating system environment, because each container operates discretely.
However, containers do share read-only access to elements of the operating system, including its kernel. Nonetheless, to each application, it looks like it is running alone in an operating system all of its own – and applications are mutually unaware that they share the operating system environment.
By consequence, a containerized workload refers to an environment where the applications that support enterprise requirements are running in isolated containers inside of a host operating system.
You might guess that isolating applications inside of containers provide benefits in terms of security and stability, and you would be right. However, the benefits of containerization go far beyond that.
At its core, containerization allows enterprises to package and deploy applications across different types of infrastructure in a standardized manner. In theory, any host that is capable of hosting a (compatible) container is also capable of hosting your containerized application.
This happens because containerization abstracts the application layer. Container technology such as Docker facilitates this abstraction in a standardized manner. The key to this standardized behavior is something called a container image. A container image includes not only the application code but also system libraries and other key settings that ensure that a containerized application is ready to go.
This brings us to a key benefit of containerization that goes beyond application security and stability: containers are intrinsically portable. It leads to several important advantages for enterprise applications:
Containerization extends and amplifies the benefits of virtualization. Enterprise users gain unprecedented levels of scalability and manageability when applications are deployed via standardized containers.
Containerization delivers significant benefits, particularly where large-scale, enterprise applications are concerned.
Containers are a sea change in the way applications are deployed, however, and from a practical and indeed a security viewpoint, it is helpful to get a view of the relationship between a container, and its host.
While it is true that containers run in an isolated fashion, it is important to understand that containers also share components. Doing so eliminates the overhead of running a separate operating system for every application in a container.
It also means that containers are quicker to start up – compared to a full operating system. So, what elements of the host is shared by containers? The operating system kernel is the most important shared aspect: there is only one running kernel in the host and every container in the host shares this kernel.
Next, drivers and OS application binaries are shared by the containers – while containers also share host OS storage, though the storage is isolated. Finally, containers also share the container platform – such as Docker, for example.
The ability of containers to run in such an isolated fashion stems from a few core Linux features that are used by container platforms (e.g. Docker) to enforce isolation. Kernel namespaces and cgroups facilitate the ability of independent containers to all share the same Linux host.
It is clear that containers deliver a high level of isolation, which in turn delivers a degree of protection – threats can’t propagate from one application to another all that easily.
However, due to the sharing of resources inherent to containerized workloads, containers remain vulnerable – and can indeed introduce new vulnerabilities that organizations must watch out for. Let’s take a look at a few examples:
So, while applications are isolated, the isolation mechanism – containers – bring their own security risks to the table and enterprises need to manage their containerized workloads in a way that mitigates these security risks.
The shared components of containers clearly lead to security risks. But arguably the biggest security risk for containerized application is the shared OS kernel. The security risks posed by the host kernel essentially hides in plain sight.
Remember: every container in a host shares the same operating system kernel. There is a risk that organizations may misunderstand the isolation and therefore security benefits of containerisation by neglected to factor in the risks posed by a shared OS kernel.
However, once the OS kernel is compromised, the application inside the container can also be compromised. And we know that OS kernels have a long track record of leading to security breaches of all shapes and sizes.
That is why kernel security matters so much when it comes to securing containerized workloads. There are a few things you can do to ensure a secure kernel for your containerized workload: stay aware of the latest kernel security risks and ensure your Linux kernel only contains the services you need for container workloads.
Don’t forget, of course, about kernel patching.
The Linux kernel is continuously patched. As vulnerabilities emerge, the community adjusts the code in the Linux kernel to combat these vulnerabilities – and releases a patch. Unpatched systems are at risk, patched systems are not.
Patching should be a no-brainer: it’s a simple security measure that significantly boosts your container security. Yet patching consistently can be very difficult:
Clearly, one of the biggest security risks for containerized workloads is, in fact, very difficult to manage consistently.
Patching automation is the first step to successfully reduce the risks of kernel vulnerabilities under containerized workloads. Another critical step is live kernel patching: the ability to update the OS kernel without requiring a server restart. KernelCare live patching offers both.
Enterprises that manage containerized workloads can use KernelCare to ensure that the kernels in their container hosts are consistently patched, and patched without disruption. It is simple to do so: simply install KernelCare the way you normally would.
When you KernelCare to patch your container hosts you also, by consequence, enjoy fully automated patching of the kernel in use by the containers. Because containers share the host’s kernel you only need to install KernelCare on your container host once – and kernel updates will apply to all the containers on that host.
In short, KernelCare is an efficient and practical way to handle one of the biggest security risks associated with containerization.
Before we conclude the article we’ll touch on a few other points worth considering when keeping your container host’s kernel secure. Yes, patching is critical, but you should also consider the following points – most of which are simply just good practice for server security:
As always, comprehensive security requires careful server configuration and ongoing, pro-active server management.
Containerization is transforming enterprise application workloads by reducing the cost of infrastructure, speeding up the process of rolling out applications, and introducing unprecedented flexibility and scalability.
However, running applications inside of containers also bring unique security risks that may not be immediately obvious. Kernel security and patching is one critical area that must be handled with great care.
KernelCare gives your organization the automatically update the kernels that support your containerized workloads, and to do it without the disruption and downtime associated with system restarts.
TALK TO A CYBERSECURITY EXPERT
Stay updated with the latest news and announcements from TuxCare.com
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...
In a symphony orchestra, instruments harmonize to create one pleasing...
We are pleased to announce that a new updated ePortal version...
We are pleased to announce that a new updated KernelCare agent...