Adopting containers and preventing container security risks

At the onset of the COVID-19 pandemic, many companies had to quickly embrace cloud applications to enable employees to work efficiently outside the office -- and, thus, outside the protection of traditional network security tools. Some organizations used cloud-native environments for the first time, often adopting containers with Docker or Kubernetes. While containers provide some isolation between different apps on an endpoint, they're still vulnerable to attack. DevOps and security teams need to understand container security risks to prevent bad actors from getting into -- or out of -- their containers.

In Container Security: Fundamental Technology Concepts that Protect Containerized Applications, author Liz Rice explains how containers get hacked and the container security risks that may arise. While providing in-depth, technical explanations around how security teams can better protect containers, Rice also breaks down container fundamentals, which offers beginners and experienced users a solid intro to how containers work and their security challenges.

Here, Rice speaks about how most attackers exploit vulnerabilities to crack into containers, the dangers of default root-level access and containers vs. VMs.

Editor's note: This transcript has been edited for length and clarity.

What made you decide to write Container Security? Who would best benefit from reading it?

Liz Rice: I have long been interested in container security. I did a few well-received talks and felt I could take that material and go more in-depth. There are a lot of security books that have a tendency to talk about subjects as if they have rules, like 'this is what you should do.' I wanted to get into the underlying reasons to give people a mental model of what's happening when they run a container so they can think about security the right way, rather than applying rules without necessarily understanding why. If you understand what a container fundamentally is, it can take you down a path to understanding a lot of its security implications.

My book is likely to appeal to people who want to understand what's happening when running a container or when they build an image. If the reader is interested in getting into the details of what's happening, this book is for them. It's aimed at a technical audience -- you don't necessarily need to be an expert, just someone who's interested in seeing what happens when you use a command line. In today's container world and moving applications into the cloud, there are a lot of different people with a lot of different roles potentially involved -- call it a 'DevOps transformation.' The book will be particularly useful for ops and platform teams that are providing the environment where containers run. Security folks also need to understand the implications of moving to the cloud and using containers.

What is the most common attack on containers?

Rice: A lot of the time, bad actors hope to achieve a container escape, but it's pretty rare for it to actually work. It's much easier to attack known vulnerabilities that haven't been updated yet. People running container images need to scan those images on a regular basis to make sure they're not running containers with known and exploitable vulnerabilities. Some of these vulnerabilities are so easy to attack, and bad actors often use scripted attacks. There are different classes of attackers, but people who are writing scripts and looking for vulnerabilities to exploit or that might be exploitable may be passing on that information to more sophisticated attackers who can say, 'OK, there's a loophole here that allows me to get into a container. Can I escape the container from here?' But that first step -- the vulnerable dependencies that let attackers in -- should be the biggest worry.

Click here to learn more
about Container
Security by Liz Rice.

More on Container Security

For help getting started with container protection, check out an excerpt of Chapter 1 of Container Security.

Could you break down what defense-in-depth container security involves?

Rice: The idea of defense in depth is that you have layers of different defenses between the attacker and what you're protecting. If attackers get through one layer of defense, they won't immediately get your data. For container security, there are several potential layers you might have. For example, say you have a network security layer that limits specific types of traffic or limits sources of traffic that are allowed into a deployment. From there, you may use a network policy to restrict the network traffic that gets to a particular container or a group of containers. Then, you could have runtime enforcement on containers while they're running live and tools that ensure the container only runs certain executables and doesn't suddenly start running a cryptomining program. Or you might employ a read-only file system so that, if an attacker gets into the container, they can't write any files.

Another security layer option involves configuring containers to not run as root. This is something developers can introduce inadvertently. By default, containers run as root, which is the same as the root user on the host where that container is running. What that means is, if the container does get compromised and if a bad actor can escape the container, they have root-level access -- and that's kind of game over.

Given the risk that root-level access creates, do you see rootless containers gaining more popularity in the near future?

Rice: It's getting closer. Docker now supports rootless containers. It's generally available in Docker for desktop applications, which brings it to the masses. People are more and more likely to be using rootless containers on a day-to-day basis. But it's still not supported in Kubernetes, though I think that will come eventually. It takes a while to get new features into Kubernetes, but it's something I would love to see because it would make it easier for people to run more security by default.

Containers and VMs get compared a lot. Why would you want to use a VM or a container and vice versa?

Rice: A lot of it comes down to orchestration, as most of the benefits of containers come with orchestration -- and, to some extent, the DevOps processes that accompany it. With orchestration, the scheduler is trying to pick an efficient place to run each container. You might have a cluster of nodes, and each node has a finite amount of memory and CPU. The scheduler tries to make intelligent choices about where to run a new piece of application code. If you run it in a container, the scheduler is going to try and find a node that has capacity to run that application. This means you can be more efficient about the use of those machines, and hopefully, you're running with much less idle capacity.

With autoscaling, you can scale clusters up and down more effectively. Tools like AWS Fargate or Azure Container Instances help get additional capacity on the fly. You can be more responsive to demand as spinning up a container takes a fraction of the time it typically takes a VM.

But those answers are really technical. It's important for organizations to think about why they want to run a VM and ask if a container would work better. It's a big change technically and culturally for an organization to take a bunch of code currently running in a VM, or maybe even on bare metal, and move it into containers, but it will provide a more dynamic environment. It can come with some huge advantages in terms of being able to deploy applications more quickly, being more responsive to demand and using resources more efficiently. However, it does come with the cost of moving from a traditional way of running applications to a more cloud-native way. A lot of organizations are finding that step worthwhile. But I think people shouldn't just do it because they expect everything's going to be a magic wand. They need to understand the costs, as well as the benefits.

Liz Rice

About the author

Liz Rice is chief open source officer at cloud-native networking and security specialist Isovalent, creators of the Cilium extended Berkeley Packet Filter-based networking project. She is chair of the Cloud Native Computing Foundation's Technical Oversight Committee and was co-chair of KubeCon + CloudNativeCon in 2018. Rice has a wealth of software development, team and product management experience from working on network protocols and distributed systems, as well as experience in digital technology sectors, such as video on demand, music and voice over IP. When not writing code or talking about it, Rice loves riding bikes in places with better weather than her native London and competing in virtual races on Zwift.