pattilabelle - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

Quest for the best security for containers: Seven steps

Despite their name, containers are by no means impervious to threats. With their use expected to grow, the time is ripe for determining the best security for containers.

Containerization is a relatively new form of operating system virtualization that lets developers run applications in resource-isolated units.

Opinions vary on how quickly companies are taking a shine to containers. Earlier this year, 451 Research projected that market adoption of containers would grow from $762 million in 2016 to $2.7 billion by 2020. However, a survey released this September by the nonprofit Cloud Foundry Foundation posited that container adoption was tepid: Container use had increased only 3% between 2016 and 2017, from 22% to 25%.

But even market watchers like Cloud Foundry that report modest growth in the use of containers over the past year nonetheless envision containers eventually taking off. Their speed of deployment and ability to function with fewer resources should make containers appealing to many organizations -- which means having effective security for containers now is a must for CIOs.

By virtue of their contained environment, containers minimize vulnerabilities and, essentially, lock down development. But that doesn't mean these software packages are entirely secure. Containers weren't created with security in mind. Nonsecure images, simple and innocent mistakes by developers, and lax administrative controls are legitimate security concerns.

jason cohenJason Cohen

"Because it's called a container, it's easy to forget that there's no physical separation between a container and the host environment," said Jason Cohen, CTO and founder of the WordPress hosting service WP Engine. "There are safeguards in place to prevent accidental contamination, but containers are not an airtight security object, especially when run as privileged."

Cohen runs container applications as if the environment is hostile and takes precautions such as using client-side and end-to-end encryption rather than assuming networks are secure. Other users also don't take security for containers for granted. Here are seven security steps they follow that should protect, as much as possible, the inside and outside of your container environment.

Seven ways to secure a container

1. Ascertain if containers are sufficiently isolated from the host OS

neil macdonaldNeil MacDonald

It's not an oversimplification to ask a larger question about your containers: Are they sufficiently isolated from the shared host OS? Gartner analyst Neil MacDonald pointed out that virtualization had long contended with a similar problem: A virtual machine (VM) hypervisor wasn't fully secured until it was "hardened," much as a container OS has to be isolated. But a container has a broader attack surface than a VM hypervisor does, MacDonald said, and users need to determine just how successfully they can isolate each container's footprint without disrupting development. This high-level review of isolation sets the stage for the security steps that follow.

2. Treat containers like hardware-based servers

Mike FeldmanMike Feldman

Mike Feldman, CTO of the online doctor review service CareDash, contended that container security should be approached with the same caution and prudence applied when securing traditional hardware. Maybe it's the flashiness of containers spinning up fast, he said, but he's found that it's easy to get complacent about security. By assuming that every step can be compromised, your development team will recognize that security is paramount and learn to double-check processes, Feldman said.

3. Restrict permissions for individual access

When running applications inside a container, CareDash developers cannot -- except in very special circumstances -- run root privileges that give default access to commands and files. This goes a long way to protecting the inside of a container.

Every CareDash developer, including the CTO himself, has a name-specified user ID to restrict permission. Feldman takes this precaution because if a container is compromised, there's no way the hacker can become a root user and wreak larger havoc. He also recommends not using group privileges for the same reason: They don't provide the type of accountability and control that an individual user ID does.

4. Minimize the services running on a container

Alex FarrillAlex Farrill

"The idea is to remove anything you're not using to make sure there aren't any additional points an attacker can compromise," recommended Alex Farrill, CTO of the real estate service Open Listings. Time-pressed developers often introduce an application into a container environment, find a better tool and then forget to uninstall the initial software, opening a security gap. "Those kinds of mistakes happen all the time," he said. Farrill creates Docker files that list all of a container's dependencies to minimize the risk of forgotten or obsolete services.

5. Teamwork upholds high security standards

Of course, for Farrill's dependency list to succeed, every Open Listings team member has to double-check it, he noted. Effective container security requires collective vigilance. "It's all about teamwork," he said.

Container work should be held to high peer-review standards that call for just about every action to be verified, in Farrill's view. "Say I'm changing a web server; I submit that for review," he said. "So, if I change a version of the web server to one with a vulnerability, it's scanned and I get an email that I should instead take another step. Peer review is vital."

6. Use images from a secure library

One of the most cited security concerns is image vulnerabilities in containers. An image is a file which contains all the requirements for how each container should function. The flexibility to create images or download public ones from Docker Hub and other open source registries is what makes containers appealing. The downside is that as more changes are made to an image and the container -- developers call each change a "layer" -- there's a greater chance that a component will sneak into development without first being scanned and validated.

Security for containers is one of those things where you don't know you have a problem until you have a problem. ... You just need an absolute best effort to stay ahead of that.
Mike FeldmanCTO, CareDash

It's inevitable a developer will want to use an effective image that also has a vulnerability, Gartner's MacDonald said. In that case, a developer should alert colleagues early in the process that a known vulnerability was used. But many organizations don't even want to take that chance and, instead, build internal component libraries, restricting developers from using the internet. Feldman and his CareDash team use a secure, private Docker image repository. Developers start projects with base images, but they "inevitably put a layer on top of that," he said. "It's nice to know all of the images (and layers) are under our closed control."

7. Automate processes to bake-in security early

Containerization encourages a "shift left," which is developer-speak for incorporating security early into the DevOps process. Many experts believe automation through continuous integration and continuous development tools best enable IT security pros to see if security protocols are being followed without interrupting the work of developers. Security becomes "baked" into development with everyone following the same easy and transparent processes.

When security is embedded early in the development process through automation, companies reduce risk as well as avoid back-and-forth steps to verify security, said Rani Osnat, vice president of marketing for the container security provider Aqua Security Software Ltd. For example, all images that were previously scanned for vulnerabilities through automation don't need to be double-checked during runtime -- assuming that you have a chain of custody of the image from development to production, he said.

No assumptions, please

Bottom line? Don't assume security for containers is fully assured until it actually is.

"It took 10 years to secure virtualization to where security was no longer an issue," said MacDonald. "It will probably take containers half that time. There's a very high level of interest and money invested in containers. Security will progress in rapid time."

Until that day comes, the advice of WP Engine's Cohen and CareDash's Feldman to not blindly trust any container environment seems like a logical security starting point.

Added Feldman: "Security for containers is one of those things where you don't know you have a problem until you have a problem. You can keep your OS up to date and someone still has a will and a way to find a vulnerability. You just need an absolute best effort to stay ahead of that."

Next Steps

Ask the Expert: What are the major risks of application containers?

Software containers: Impact on networks

Containers as a service: A path to better governance?

Dig Deeper on Cloud computing for business