Why Container Security is such a Challenge
The Power of Containers
Containers are having a moment. They are revolutionizing the way we do application development, but, as with most new technologies, their adoption in the enterprise is (rightfully) hindered by genuine security concerns. Ultimately, containers can bring huge security benefits not found in traditional infrastructure. But with new technologies come new risks.
First of all, what is a container?
In one sense, containers are an OS-level virtualization method for running multiple isolated Linux workloads on a host using a single Linux kernel. Effectively, everything outside the kernel is virtualized; applications, runtimes and files in one container can’t see other containers on the same machine, but they share an underlying operating system, which makes them far more lightweight than virtual machines.
Containers have not only allowed companies to pack more onto a single machine, they’ve made it much easier to build portable software that is continuously redeployed. Container images can be easily shipped around, are portable from machine to machine, and start fast. They’ve become a key technology to enable microservices and auto-scaling applications, and are now a staple in many continuous integration/continuous delivery (CI/CD) pipelines.
Microservices break down the process of developing an application into a collection of small services; each service implements business capabilities, runs in its own process, and communicates via HTTP APIs or messaging. Microservices make it so you can have different people working on various parts at the same time, which not only speeds up the development process but also makes it easier to check for errors within individual services.
To manage all of the containers and microservices therein, you also need an orchestration platform, such as Kubernetes or Docker Swarm. These platforms have built-in security, but it’s more around making sure nothing gets out. The issue then becomes: what is going on inside?
The Challenge of Container Security
Containers enable things to happen faster, so while this means faster deployments, it also means faster failures. And while containers are great for isolating valuable data, it’s also holding…valuable data. The more you put into a container, the more you have to trust everyone (and everything) that has access to it and that it can access. This creates a situation where you are always one kernel bug or misconfiguration away from everything being affected.
Recent high-profile breaches, like the Equifax breach, prove that isolation is not enough, as bad actors never had to gain more privileges than the hacked web server to get access to all of their customers’ data. That access was already allowed. You are never going to know all the vulnerabilities, or how someone could get in, but you need to know when something inside a container is doing something bad. The challenges of monitoring containers are rooted in the very reasons that they are useful in the first place; they provide more flexibility and reuse of resources.
A survey of 450 IT and information security professionals in North America and Western Europe uncovered some major concerns that are hindering container adoption.
Security concerns and obstacles related specifically to running containers:
We use a separate container security solution as our current server workload security solution does not support/offer the same functionality
There is a lack of mature cybersecurity solutions for containers
An infected container can cross-contaminate other containers
The potential for container sprawl creates loose access controls between containers that could leave our production environment(s) vulnerable
By design, containers come and go at a much faster rate than virtual machines (VMs), and while that’s great for speed, it’s not great for monitoring. When deployed, a container often receives access to resources allocated to it, e.g., an IP address on a software-defined network inside of a VM or a small portion of the filesystem. When finished, these resources are then reallocated to the next container. Traditional security identifiers, such as the IP address assigned to a given container, then become meaningless unless you can cross-reference them with the state of the container runtime and orchestrator. To compound matters even further, containers and container orchestrators are built from software-defined components which only exacerbates their dynamism. If you’re monitoring something that is always changing, how do you know when that one change is bad?
Solving the Container Security Problem
Security appliances have been a crucial tool in protecting the current environments of many enterprises today, but when it comes to containers, security appliances fail. While there are a number of reasons (9 of which we outline here), one of the most significant issues is that inter-container traffic mentioned above. When multiple containers live on the same machine and talk to each other, communication doesn’t go over the network and can never be seen by an appliance—even a virtual appliance. You still don’t have access to what is going on inside.
The solution to container security lies within tooling that is container aware. You need to monitor what is going on, all of it, and somehow not be caught up in a mountain of false positives. By looking real-time into system, network and intra-container data, you achieve the level of visibility needed to know when something bad is happening inside of a container and can respond to it appropriately, such as shutting down or isolating the affected container.
This is the problem we are solving at Capsule8. With the transparency required for real-time protection, monitoring and troubleshooting, we’ve developed the first real-time attack disruption platform purpose-built for the cloud-native world of containers, Linux, and microservices. We bring continuous security to an entire production environment, automating the detection, isolation, and shutdown of attacks in the instant they happen.
Learn more about how we are securing container runtimes.