The battle against containers

The battle against containers

The battle against containers describes Adrian Asher’s view of containers and why he doesn’t like them. Adrian is CISO of LSEG and has worked in a mixture of tech and financial services across his career and holds an MSc in Information Security.

I don’t get them. So not only do I not understand the need for them, but I also don’t allow them! Given one of my mantra’s (of my many mantras!) is to enable and not constrain it seems strange that I won’t allow them, so why?

What is a container anyway?

A container is a grouping of some code, dependency libraries and configuration files. The idea being that a developer can individually specify all these items and provide the manifesto (description of the above) into a single deployable package. This package remains the same as when they are developing and testing on their local laptop, through to testing environments and ultimately production.

So that all sounds good, consistency between environments, why are you against it!

Security Answer

Containers are not a trust boundary. Therefore two containers running within a single virtual machine would not have full separation between each other. Whilst there are increasing technologies (and associated companies) that have a solution attempt to help with this, my core belief is that containers will never have the same level of isolations that Virtual Machines have via the hypervisor.

So what do you allow?

As a firm believer in the merits of DevOps and the huge security benefits that can be gained from it I strongly believe in empowering the developer. Many years ago someone came to me and asked to remove all passwords from their team.

A little aghast I swallowed my initial response (laughter, crying or a combination of the two) and asked them why. Their reply changed the way I have approached solving problems working in technology over the past two decades. Their team continued to forget their passwords and was causing them problems logging in and out frequently during the day, especially with the new screen saver time outs (from nothing to an hour).

Because they had come to me a preconceived solution to their problem, the “How” rather than the “What”, it had taken us to the point of a disagreement from the outset. Once I had understood what they were trying to achieve we worked together on the how to best achieve it. In this instance I rolled out bio-metrics and their team loved it (and locked and unlocked their machines frequently).

So when a developer comes to me and asks to use containers I swallow my initial response and ask what they are trying to achieve. At first they talk about specifying configurations and details about how containers work. But after we step back and look at the bigger picture they then talk about faster deployments, consistency between the environment they build in and production and ultimately a greater cadence of feature delivery to production.

All things I of course support and sprinkle in a little security magic and we’ve got a great goal. So if not containers then what can deliver all their desires?

Other things do exist

The advent of computers has brought us through a number of iterations. Starting off in the dim and distant past with centralised compute power (mainframe), distributed (x86/PC), virtual (hypervisor based), IAAS (virtual on someone else’s hardware), PAAS (you provide the code, we provide the platform) and now Event Driven Code Execution (EDCE).

EDCE? So some people refer to it as ServerLess but I find that to be a misnomer as of course a server does exist. Event Driven could be an API call, a web page fetch, an object being updated in a datastore (relational or otherwise) or even a developer requesting a virtual machine.

Anything including and above PAAS I will allow. So PAAS and EDCE.

Patching

As various ransomware has proven corporations don’t patch. And with good reason. The architectures that we have designed and built over the last 22 years in my technology career have (in the main) sucked. We haven’t designed our environments to be operated 24×7, to be automatically patched, to have auto scaling capabilities.

We all have legacy environments that we have to patch and maintain. Keeping them ring fenced and minimising change on them until they are finally replaced is often the best we can hope for. Ask any sysadmin, security person or CTO/CIO and they will tell you that they have a problem with their legacy environments.

Yet they don’t seem to equate what they are building today as tomorrow’s legacy problems. If we abstract away the platform from the application then patching, automated deployments, scaling (though state management has to be designed well in this case) and of course consistency between environments; all become easier to manage now and in the future as well.

Of course my strategy has the ultimate of ironies. EDCE users containers!

Session Credit

Adrian Asher is speaking in a Keynote Stage seminar at Infosecurity Europe – Securing the Code: Building Resilience, Security & Agile into Coding, Design & Development on Tuesday 6th June, 16:35 – 17:25

Leave a Comment

Your email address will not be published. Required fields are marked *

Are you human? *