How to improve container security

Gartner has named container security one of its top ten concerns for this year, so it might be time to take a closer look at this issue and figure out a solid security implementation plan. While containers have been around for a decade, they are becoming increasingly popular because of their lightweight and reusable code, flexible features and lower development cost. I’ll look at the kinds of tools needed to secure the devops/build environment, tools for the containers themselves, and tools for monitoring/auditing/compliance purposes. Naturally, no single tool will do everything.

Start by following a few basic steps

1. Look at what your cloud provider offers

Your first step is to familiarize yourself with what built-in security comes from your cloud provider. These include tools such as Azure Security Center, Google Kubernetes Engine, Google Cloud Security Command Center and Amazon Inspector. Some, such as Azure Security Center, are general-purpose security tools and not designed for containers.

2. Familiarize yourself with native Docker-related security features

This includes using policies to prevent abuse of resources, setting up access control groups and ensuring that you remove root access where it isn’t needed.

3. Consider GitHub open-source projects

Projects such as Bench Security, which checks for security best practices in your code, and other Linux-native tools such as seccomp can be low-cost options in some cases. I’ll cover other open-source tools later.

That is a lot of software to learn and understand, but you should look for several common features. These include identity and authentication, both for your users and for the ultimate apps that you intend to build, and how you control this access. Also, you want to be able to examine and audit log files and how you view and filter them to provide actionable information on your security posture. Finally, there is the underlying infrastructure for protecting secrets such as API keys and SSL certificates. You want these stored in an encrypted format.

Overwhelmed yet? We are just getting started. Let’s look at three areas you need to secure to protect containers in your environment.

1. Secure the build environment

Because containers are so useful for developers, it makes sense to move next into the DevSecOps arena and add security at the time you are creating your container, rather than wait until after a project has been coded as a bolt-on. This is always a best practice for securing your apps. Here are some important questions to answer before you pick the right security tool:

• What workflows are you able to automate to keep your apps secure? Some tools can help with this, particularly with orchestration. However, many of the orchestration tools focus on the management of the containers and scaling issues, not necessarily on security details. Finding the right balance (between utility and actual protection) might be difficult.
• How much granularity do you need on your access controls for your apps, and for your users? Here it is good to understand how these controls are applied and what are their limitations. For example, it is always a good idea to see which code portions and containers have root/kernel access and whether you need this level of access for them to do their jobs.
• Should you use runtime application self-protection (RASP) techniques? In a word, yes. Like regular RASP-oriented tools that focus on apps, some tools specialize in container runtime application protection, either with a static scan or with continuous integration using your development environment. The latter form is helpful because container code is constantly changing and having a continuous code audit is a big time-saver when you have to patch or update things. A good RASP container tool should be able to flag abnormal behavior, remediate potential threats and be able to isolate peculiar events for further forensic analysis.

2. Secure the underlying hosts that house your containers

Most of the time this means running a stripped-down version of Linux that has as few running services as possible to reduce the potential attack surface. Some of the tools are designed to harden the host itself. Another way to do this is to use the Docker control groups mentioned above, along with isolating namespaces to reflect your security policies and separate containers from infecting each other. Some shops use virtual private connections from the cloud provider for this isolation. Part of this process is to segregate your workloads by using access levels and other mechanisms, and to limit the number of running containers per host. Some shops run only a single container per host for this very reason.

3. Secure the content of your containers

Here we are looking at the software supply chain of images. These are the container building blocks, so one basic feature is being able to enforce image source integrity protection, meaning that if someone on your staff (or through the open source project that you originally obtained the container from) makes changes to the image, do you know what was changed?

Given that many containers are shared around the internet, this is a useful feature. Related to this is being able to scan these images to assure they are infection-free. How often can you do this, and can you automate these scans? Being able to obtain images from trusted sources is helpful, but everyone makes mistakes and can introduce security issues inadvertently too.

However, with some shops, you may not actually care what vulnerabilities are in your containers. That seems surprising, but it makes sense — with one caveat. This will only work if you can secure the container boundaries sufficiently, or because your actual app code doesn’t touch these parts of the container code. How much confidence you have in your security tools might be the ultimate factor in deciding how many vulnerabilities you can tolerate.

Typical container security products

Now that you have the scope of your security needs in mind, let’s look at some of the typical products. The basic decision here is how much open source do you feel comfortable using, or put another way, what kind of budget do you have for buying commercial products?

A good place to start your tool discovery process is with Sysdig. They have a series of excellent tutorials (using their software of course as models) that walk you through some of the common security use cases, such as auditing runtime code for odd behaviors, performing forensic analysis and examining vulnerabilities. The company also offers its open-source RASP tool Falco and commercial tools Monitor and Secure, the latter for image scanning and vulnerability monitoring.

The major open source tools include:

• Anchore for vulnerability analysis and image scanning,
• Apparmor for RASP needs,
• Cilium for network and HTTP layer security,
• Coreos Clair for static code analysis,
• Dagda for static vulnerability analysis and monitoring, and
• Saucelabs, which offers free live and automated code testing.

The major commercial vendors include:

• Alertlogic for managing container identities and log analysis,
• AquaSec for RASP, auditing, image scanning and container IDS,
• Flawcheck, which Tenable acquired and folded into its container image scanner that leverages their Nessus security expertise,
• Twistlock for RASP and additional machine learning protection, and
• Threatstack, which has vulnerability monitoring tools as part of its Cloud Security Platform.

Finally, some general advice on what this is going to cost. Most vendors offer limited evaluations (with some periods as short as a week and others lasting months), so you can try before you buy. Many of these evals have signup pages, so they can track their leads. Because the tools charge by API calls or other usage metrics, most of them have complex pricing models that aren’t posted on each vendor’s website.

For example, Sysdig has this rather uninformative pricing page. I was able to find out that its prices start at $30 per month per host on annual plans, with quantity discounts. One of the challenges with pricing your container protection is you might not know the full scope of your container infrastructure, and given the velocity of change, it might not be possible to even estimate the overall costs. So, you might want to start with open source before you move into the commercial arena.