DevSecOps: Slaying the Myths of Container Security

Containers are clearly appealing for companies and development teams who want to deliver and iterate on their software faster and efficiently. This is achieved through more consistent, simple and repeatable deployments, rapid rollback, and simpler ways of orchestrating and scaling distributed applications.

The survey shows however that security is very relevant to organizations who are looking to deploy containerised applications. Though the question referred to ‘concerns’, we believe that security is relevant to containerisation in both in the positive and negative senses - how do containers both introduce, but also solve common security challenges?

There are a lot of myths about container security.  Though there have been demonstrated exploits of people for instance breaking out of containers, or attacking container daemons in various ways, we believe that when you consider both sides as above, containers are a net benefit for security minded organisations.  In principle, containerised applications give us tens of different ways of introducing new security approaches which reduce attack vectors and minimise attack surface areas.  

What organisations do need is a lot of education, first to put some of the myths to bed, and then to educate on how to achieve container security in an optimal way.

There are many approaches that teams can bring to the table to maximise security in a containerised environment:

• Least Privilege.  By default, containers add layers of protection and sandboxing around a process.  These protections ensure that processes are not allowed to interact with other processes, or the underlying host operating system in any way other than that explicitly allowed.  By default, container platforms are locked down, but there can be additional restrictions applied at the time that you start the daemon or container.

• Reducing Attack Surface.  Both containers and other pieces of the platform such as the daemon or orchestrator, should also be configured with the minimal possible scope for attack.  

• Container Registry. Companies want to ensure that rogue, untested or unlicensed software is not entering the organisation.  To achieve this, companies will deploy an enterprise private registry as a central store of containers.  These containers can then be validated, scanned, and configured with the proper access controls to ensure a single source of the truth.  

• Container Signing. Container orchestration platforms will integrate container signing mechanisms to ensure that we are only running trusted code insider the organisations boundaries.  

Should The 88% Be Concerned?
The survey shows that 88% of people have some degree of concern around security of containers.  Hopefully this short article has made the case that there are many myths leading to these concerns, and many options in how you deploy your container platform for adding security into your environment.

Want to learn more about DevSecOps?

This blog is one of seven in a series providing expert commentary and analysis on the results from Sonatype’s 2017 DevSecOps Community Survey. For access to all of the blogs in this series and the survey report, please visit: www.Sonatype.com/2017survey.

Benjamin Wootton (@benjaminwootton) is the co-founder and CTO of Contino, and is a guest blogger for Sonatype's 2017 DevSecOps Community Survey.