Why InfoSec Teams Should Embrace Containers | SUSE Communities

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
  • 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

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

William Jimenez is a Solutions Architect at Rancher Labs.

(Visited 1 times, 1 visits today)