Odds are, software (or virtual) containers are in use right now somewhere within your organization, probably by isolated developers or development teams to rapidly create new applications. They might even be running in production. Unfortunately, many security teams don’t yet understand the security implications of containers or know if they are running in their companies.
In a nutshell, Linux container technologies such as Docker and CoreOS Rkt virtualize applications instead of entire servers. Containers are superlightweight compared with virtual machines, with no need for replicating the guest operating system. They are flexible, scalable, and easy to use, and they can pack a lot more applications into a given physical infrastructure than is possible with VMs. And because they share the host operating system, rather than relying on a guest OS, containers can be spun up instantly (in seconds versus the minutes VMs require).
A from the Cloud Foundry Foundation surveyed 711 companies about their use of containers. More than half had either deployed or were in the process of evaluating containers. Of those, 16 percent have already mainstreamed the use of containers, with 64 percent expecting to do so within the next year. If security teams want to seize the opportunity (borrowing a devops term) to “shift security to the left,” they need to identify and involve themselves in container initiatives now.
Developers and devops teams have embraced containers because they align with the devops philosophy of agile, continuous application delivery. However, as is the case with any new technology, containers also introduce new and unique security challenges. These include the following:
, and as we make the inevitable mistakes (like the configuration error in Vine’s Docker registry that allowed ), best practices are sure to evolve.