Containers are an increasingly popular feature of enterprise IT architecture because they bring a number of benefits to the table, mostly in terms of application development and deployment.
Because of the way they abstract specific functions of an application from their run environment – a logical development of the virtual machine concept – containers are ideal for high-speed application deployment at scale.
They also deliver highly consistent performance regardless of the run environment, which is ideal for the modern enterprise that needs to run apps across multiple and hybrid clouds.
From a development perspective, containers also deliver what Google calls “a clean separation of concerns” across DevOps functions – Devs teams only have to focus on the application functions that go into the container, Ops teams don’t need to worry about details like software versions and configurations because of the cross-platform consistency containers deliver. This all leads to shorter, more efficient production cycles.
But what about security? This has been a hotly debated topic in IT communities for a number of years now. Because by their very nature containers lead to a certain degree of isolation of applications and their functions, it has been argued in the past that they are inherently secure. Combined with their high portability, agility, and scalability, this would make containers something of a holy grail in app development.
The general consensus now is that containers are not, in fact, inherently secure, but instead offer a broad range of tools that can help developers improve application security. There is little argument that containers carry some significant security benefits. But the flipside of this is that containerization also poses a number of challenges which must be overcome if those benefits are to be enjoyed.
Let’s unpick what some of these are in turn.
Security benefits of containers
It is easy to understand why the argument that containers are ‘inherently secure’ emerged. Some of the intrinsic features of containerization do indeed lend themselves to improved application security as a matter of course.
For one, containerization makes it easy to run updates and patches at speed and scale without any impact on the application’s performance. When containers are used in a microservices architecture, you can also isolate risks to specific parts of the application, stop them spreading and resolve issues with minimum disruption.
Containers also lend themselves to what is known as an immutable infrastructure. When you update a container, you are not modifying it while it is still running, as you do when configuring patches for conventional applications. You are actually replacing the container completely, switching it for a new version with the update applied. This minimises the risk of glitches being introduced during security updates.
Many of the tools used in containerized environments, including Docker and Kubernetes, are open source. There are many people who argue that open source is in itself beneficial to application security, because any tools you use have been viewed and used by an entire developer community, reducing the likelihood of vulnerabilities slipping through unnoticed.
Challenges to container security
The main reason that the idea of ‘inherent security’ in containers has been widely debunked is because the containerised services that make up an application are not as isolated as people perhaps assume they are. This is maybe a carry-over from experiences with virtual machines, which do very much run in their own bunkers. If a hacker or a piece of malware gets into one VM, there’s little prospect of them being able to navigate their way to other VMs on the same server.
Although they represent a form of virtualisation, containers work differently to virtual machines. The idea that one container being hacked poses no threat to the whole application doesn’t apply. Yes, containers offer a degree of isolation. But it isn’t complete.
To build intrinsically secure applications using containers, developers have to create their own fire doors to stop threats spreading. This isn’t easy because containerized applications are complex things. The level of dynamic interaction between functions and services is highly intricate and mutable, meaning all sorts of possible pathways from one container to another occur over time. Predicting, tracking and then shutting down these routes of infection is a major task.