Container Security Best Practices Taking Shape
Almost 20 years after containers’ inception, container security is becoming top of mind. Here are some things to consider
Now that containers are enjoying a notable spike in popularity, it can be easy to forget that they’ve actually been around for decades. Back in 2001, Jacques Gélinas created the VServer project, which according to the 0.0 version’s change log, allowed “running several general purpose Linux servers on a single box with a high degree of independence and security.” If you think that sounds familiar, it’s because it’s a description of a container.
Despite this long history, it seems that everyone is now rushing to secure their containers. Doing so can be complex. We’ve introduced the top 10 container questions to ask your team, how to manage the security of containers in cloud-native architectures and shown you how to tighten security with sidecar proxies.
In this article, we’ll take a broader view, and explain the high-level principles of container security.
Secure Your Images
The first and arguably the most important aspect of securing your containers is to look at the image security. Containers come from images, and your developers will either be developing their own images or sourcing them from a third party. Even if they are building their own, this doesn’t necessarily mean they are secure, because most images (even those that are “custom made”) will be built on third-party code. For example, you may have an Apache layer on top of an Ubuntu base image—and sometimes a custom Node application on top of that.
This means that the first thing the SecOps engineers need to look at is the source of the images in their containers. This means specifying a list of trusted sources and putting in place controls that ensure that only trusted images are used throughout your systems. Open source tools such as Notary, a Docker project, can be useful in this regard because they allow authors to sign the content they publish and users to verify the authenticity of this content.
Combat Vulnerabilities Before Deployment
Another vulnerability that stems from the way that developers use containers is that it can be difficult to scan for vulnerabilities during the deployment of novel software. When working in a containerized environment, you typically won’t have complete upstream control of the code that your developers are producing natively. This means you need a way to subscribe to vulnerability information from upstream projects.
In addition, in making the move to containers you will need to upgrade your vulnerability scanning capabilities so that you are able to perform scans on container formats, since your developers could be pulling down complete images at once.
Hardening Your Host Environment
An important aspect of container security, but one that is often forgotten is that you also need to harden the security of the systems that your containers are running on, and the way that they act during runtime.
For example, one of these hardening practices is to remove noncritical native services from the production host. By doing this, you force users to access the host through the containers, thereby centralizing control at the container daemon and removing the host from the attack surface. This is particularly important if proxy servers are used to access your containers, because these can inadvertently bypass your container security controls.
Ideally, your container security practices should not be narrowly focused on your containers themselves; you need to harden the entire stack. This includes your host as well as your daemons. This is why the Center for Internet Security (CIS) has published a consensus Docker benchmark, widely considered the most comprehensive configuration and hardening guidelines for environments that run Docker containers.
Use Thin, Short-Lived Containers
Given all the recent hype around container security, it’s sobering to remember that containers were supposed to be a MORE secure approach to development than traditional working practices. This is because containers are designed to be lightweight and only used briefly. Unfortunately, this is not the way that many developers use them.
Instead, plenty of devs treat their containers like a server, adding files to them and only updating them every few weeks (or months or years). This is an extremely injudicious way to use them, both in terms of performance and security. Using a low number of large containers increases the attack surface and weakens overall security.
For this reason, a key element in your container security is to minimize the number of files you store in particular containers and refresh the containers you are using frequently.
Use Container Security Tools
It’s difficult, of course, to give a complete list of all the best practices when it comes to container security. However, there are a number of tools available that can help you to continually scan for errors in your container setup.
Docker Bench Security, for instance, is an auditing tool that will analyze your configuration settings and let you know if there are errors. Before using this tool, harden your Docker servers in accordance with the CIS hardening benchmarks. After that, run Docker Bench Security to confirm proper server, as it runs its checks based on the CIS benchmarks.
A Final Word
In short, and as we’ve previously pointed out, containers offer both security advantages and challenges. In securing your containers, you need to look at the way your developers source their images, frequency and length of use and the environment in which they are deployed.
By following these principles, you should be able to realize the central promise of the container model: an agile, adaptive and ultimately secure development process.