As containers continue their march into the IT mainstream, leaders will be increasingly pressed for assurances that containers are ready for prime time. And one of the big fear factors that skeptics may cite is a familiar one: Security.
“The biggest misunderstanding is that containers are inherently insecure,” says David Emerson, VP and deputy CISO at Cyxtera.
Indeed, it’s a major misconception, one we saw with the advent of cloud computing. Is cloud security important? Absolutely. Does that mean cloud environments are inherently insecure? Of course not. A similar principle is in play as containerization grows inside enterprise IT shops.
[ Do you hear "no" a lot during security discussions? Read also: Talking to normal people about security. ]
As you discuss container strategy with more people in the organization, and as you look ahead to what’s next for your use of containers, you must understand and be able to articulate the fundamentals of container security. We asked IT leaders and security pros to share advice for a Container security fundamentals guide for you. Here are five strategic points to utilize:
1. Container security is multi-level
Red Hat security strategist Kirsten Newcomer encourages people to think of container security as having ten layers – including both the container stack layers (such as the container host and registries) and container lifecycle issues (such as API management). For complete details on the ten layers and how orchestration tools such as Kubernetes fit in, check out this podcast with Newcomer, or this whitepaper: Ten Layers of Container Security.
Ned Bellavance, director of cloud solutions at Anexinet, says it all starts with your container host. Just as a set of virtual machines is only as secure as the hypervisor those VMs are running on, your containers will be only as secure as their host.
“The container host needs to be properly secured using a combination of least access privilege, patching of vulnerabilities, and hardening of the system,” Bellavance explains. “An insecure host makes all the containers running on the host vulnerable to attack from the outside and from each other.”
Since containers are deployed from images, Bellavance points out that container security also depends significantly on healthy, well-maintained images.
“The best images are well-maintained and fairly immutable,” Bellavance says. “By well-maintained, I mean that the individual layers that make up the image are kept at a consistent patch level that protects against known vulnerabilities. If the image is created with a vulnerability, then every container deployed from that image has the same vulnerability.”
This is also a good example of how the technical aspects of container security bleed into process. Security needs to be baked into each step of your development and operations pipeline rather than bolted on as a final step right before your teams deploy code. Some organizations call this approach DevSecOps.
Enterprises “are finding ways to move security left in their application development lifecycles,” Red Hat’s Newcomer told us. “They’re adopting DevSecOps by integrating security practices, tooling, and automation throughout the CI/CD pipeline.”
“To do this well, they’re integrating their teams – security professionals are embedded with application development teams from inception (design) through to production deployment,” she says. “Both sides are seeing the value – each team expands their skill sets and knowledge base, making them more valuable technologists. DevOps done right – or DevSecOps – improves IT security.” (Read the full article: Why DevSecOps matters to IT leaders. )
2. Limit dependencies to limit risk
As with most new technologies, you’ll want to understand your risks. Cyxtera’s Emerson notes that containers come with myriad benefits, but that doesn’t mean there are zero costs.
“By reusing services and loosely coupling them, your team may accelerate the delivery of a functioning product,” he says. “But it must also account for the attendant increase in complexity of interactions between components, critical contributors and maintainers of code (many of whom may be third parties), and decreased visibility into the practices, pipelines, and parties delivering the services upon which your product depends.”
By understanding the fundamentals, you can then begin to do your own risk analysis – what does that look like in your organization?
Many experts recommend as a best practice that you limit those kinds of interactions and dependencies to only those that your services actually need; anything else just introduces unnecessary risks. Below, we’ll share some examples.
3. Reassess existing security practices and tools
“The shift toward reusable, compartmentalized services and microservices necessitates a re-evaluation of one’s secure design practices,” Emerson says. That’s because you’re effectively increasing the size of your surface area. Again, though, this shouldn’t be a fear factor; it just means you need to reevaluate your older security practices and tools.
“The reuse of components and adoption of services maintained by others can save tremendous development effort and yield a high-quality product, but it requires attention to one’s ‘service supply chain,’ which previously might have been a much less prominent consideration in designing, securing, and implementing a product,” Emerson says. (For more on securing a container supply chain, see our related article, What Clarence Birdseye can teach us about container security.)
In fact, this reevaluation is one of the security advantages of moving to containers.
“Containers can actually be a forcing function to become more secure,” says George Gerchow, VP of security and compliance at SumoLogic. He likens it to enterprises’ shift from physical to virtual environments: “They had to virtualize the entire image with all of the same services turned on. Now, with containers, you can really optimize the images and reduce risks by whitelisting services on the images.”
Your security reevaluation should include host, images, and processes, paying particular attention to how process impacts the underlying technologies. Bellavance shares an example of how image and process interact; consider what this might look like in your own organization.
“Developers creating container images should be careful to limit the components in the image down to the bare bones of what is required,” Bellavance says. “Don’t need Java installed in your image? Then don’t include it. The less included, the more efficient and secure the image will be.”
Bellavance shares a couple of other examples farther along the software pipeline: “Don’t need SSH into the container? Then don’t configure a port mapping for SSH. Your web front-end containers don’t need to talk directly to the database backend? Then don’t allow that traffic.”
