Check your security in the container revolution
Container technology has become the foundation for running applications. But what has happened to security? When we containerize our applications, we must be aware of important new security issues.
Virtual machines used to run most enterprise software, but now containers are taking their place. Containers are the essential building blocks of microservices architecture, which has rapidly become the de facto design pattern for all kinds of applications.
Why has this container revolution happened? There is a strong hint in the name, which refers to shipping containers.
The main benefit of containers is their enforced modularity. Consequently, they allow easy portability of applications from one cloud server to another. Moreover, in contrast to legacy software, containers are cloud-native, which is extremely valuable for modern applications. Optimally, the program code in each container takes care of just one task or service required by the application. It makes them highly reusable and very light to handle.
By default, containers can be considered more secure than traditional platforms. Each container runs its own tiny slice of a Linux-based host operating system, and their content is separated from all other containers on the same server by using functionality native to the host OS.
A whole new set of risks
Unfortunately, we can not rely on the simple native security setup to make a container environment secure. Just as most technology, containers were not developed with security as the prime motivator.
Some security issues in container technology are familiar from the world of virtualization. However, we expose ourselves to a whole new set of risks as well.
The fact is that once established, a containerized application environment quickly grows into something very complex. With potentially thousands of short-lived containers coming and going, containers have many more layers and dependencies to protect compared to traditional virtual machines.
Let’s take a closer look at some risks.
One obvious risk, already familiar from the virtualization world, is related to distributing containers by cloning them as images. If there’s an unpatched vulnerability in a base image, all clones and applications using them will be exposed, too. Moreover, due to the hierarchical nature of container repositories, the interdependencies present in any complex application will mean that a vulnerable container can spread in ways that are not obvious at first sight.
Easier life for an intruder
Making things worse, the default assumption is that containers running on the same server have network access to every other container. While this makes deployments of even complex microservice collections quick and easy in terms of networking setup, it can also make life easier for an intruder. If he gets access to one container, he can use this to orchestrate a sort of internal DDoS attack, freezing down everything running in the impacted server.
Finally, and possibly most dangerously, the default user for most container systems is root. This presents another issue familiar from virtualisation. If an eventual attacker gains access to a vulnerability, which allows an escape from the container, he can get access not only inside the other containers but to root privileges in the host operating system.
While not an exhaustive list of container security issues, these prototypical examples allow us to discuss ways to mitigate risks. In our next blog posting, we will discuss some best practices to secure container environments in production. Stay tuned!
Do you want to know more about security in the complex ICT era? Download our white paper about visible cyber security.