Why InfoSec Teams Should Embrace Containers

Each time a new software technology arrives on the scene, InfoSec teams can get a little anxious. And why shouldn’t they? Their job is to assess and mitigate risk – and new software introduces unknown variables that equate to additional risk for the enterprise. It’s a tough job to make judgments about new, evolving, and complex technologies; that these teams approach unknown, new technologies with skepticism should be appreciated. This article is an appeal to the InfoSec people of the world to be optimistic when it comes to containers, as containers come with some inherent security advantages: Immutability In a typical production environment, you have a number of things managing state on your servers. These include system imaging, configuration management (CM), and deployment tools. The end state of the system is very dynamic (particularly with CM tools), with libraries and packages determined based on various runtime variables. Here’s some examples of when this can be problematic:

• The version of OpenSSL you have running on your hosts may vary based on the operating system you’re using – your RHEL 6 hosts might have one version, while your Ubuntu hosts using a different patch release have a different version. Even these small differences can have a measurable impact, and can enable recent OpenSSL exploits like Heartbleed.
• If you’re ahead of the game and don’t have different operating systems, what if the CM tool you’re running on a particular set of hosts encounters a bug and stops before it can ensure package versions (assuming you have defined explicit versions!)? Now, an outdated package lives on in the system until someone notices. In a small environment, you might have a good pulse on successful CM runs, but in a large environment with thousands of hosts and some level of complexity, you’ll have some number of hosts on which you lack assurances of consistency, either because you don’t know about it, or you haven’t addressed it yet. The lack of determinate state creates the need for inventory and CVE scanning technologies in your environment.

This is where containers offer an extra benefit. Because of the immutable nature of a container image, I can know the state of my runtime before it’s deployed. This provides me with a single point to inspect and reason about the state of runtime, rather than constantly taking inventory of every runtime deployed in my system. It’s much easier to scan images once during the build process for known CVEs and other vulnerabilities, and to catch risks before deployed. Isolation With containers, the Linux kernel has been engineered to provide isolation between the containers on a host. It allows each process to have a different runtime than its neighbor. For InfoSec, this reduces the abilities of an attack vector to affect other parts of the system if an application is compromised. While this compartmentalization isn’t airtight, no security mechanism truly is. Easy adoption for developers and application teams And finally another reason this should appeal to InfoSec is that you can get all the above benefits much more easily than security-only tools because of the shared advantages to developers and application teams. No security group operates in a vacuum and even the most security minded org needs to balance control with productivity. But when your solution satisfies both, you have very little resistance toadoption and justifying the resources required. As much as this sounds like a paradox that shouldn’t exist, you can to some degree have both increased agility and security with containers. Conclusion I hope that these points have encouraged you to further explore and see for yourself how containers can benefit security in your organization, if only to start an internal conversation on using them in production. As always, the Rancher team is here to help along with your container journey – reach out to us on Twitter @Rancher_Labs

William Jimenez is a Solutions Architect at Rancher Labs.