Who still needs VMs today? – the IT Security Blog by AVANTEC

About the job

You have probably seen the image in the title before in this or a similar form. It feels like in 90% of all articles about container platforms. Although this type of image is already "overused", I still want to use it here. This article is about containerised platforms, specifically Docker, Kubernetes and Openshift. When I hear the term "container", I always first think of the old, rusty, heavy iron blocks that are transported on huge ships across the oceans. But apart from the term, these have little to do with today’s topic of container technology in IT. Many containers fit on a ship, but how does this differ from another virtualisation platform like, for example, VMWare ESX? There, too, several VMs fit on an ESX, so why containers? Where the hype comes from The word "Agile" (pronounced: áʤɑjl) may be familiar to you. It encompasses several agile software development methods, all of which can be considered relatively young. The Wikipedia article on agile software development goes back to 2005, but it only really became well known after 2010; I would even dare to say only after 2015 did this topic become truly known in large Swiss companies (banks, insurance companies, etc.) and spread with the release of Docker. This then created a hype – the "They have it, so we want it too" effect. Once someone started using it, it quickly became adopted by many companies. I was working in the banking sector during this hype and the hype was clearly noticeable. Everyone wanted containers and to be agile because others were doing it too. Everyone wanted to sit at the table with the cool kids. Thus, Docker as the market leader quickly found its way into companies. What one thinks of agile methods is up to each individual. Many are enthusiastic about them, but I have also heard some criticism in the past: if the methods are not followed exactly, software development can become chaotic with everyone just doing their own thing because "we are agile". But being agile does not mean developing software freestyle. The negative opinions are also due to the hype around the term "being agile". I have personally worked too little with it to give a definitive judgement. Development of containers It is not particularly surprising where the concept of containerisation was developed on Linux. At the company with the 6 coloured letters, headquartered in sunny California, a lot has been developed for IT. This is Google. Google needs a considerable amount of resources for all the services it offers. In the past, everything was classically virtualised as we know it: host, virtual machine and on it an operating system with the application. However, this requires the resources of an entire operating system for each application, as rarely do multiple applications run on one system, making resource sharing very difficult. Paul Menage and Rohit Seth from Google tackled this problem and under the project name "process containers" began developing the foundation for containers on Linux from 2006. Their work was the beginning of a Linux kernel feature called Control Groups or cgroups. With cgroups, resources such as CPU, RAM or I/O can be bound to individual processes or groups of processes. This was to lay the foundation for the cloud computing revolution: containerisation. Function Containers are an abstraction on the app layer that bundle code and dependencies. Multiple containers can run on the same machine and share the operating system kernel with other containers, each running as isolated processes in their namespaces. Since containers do not have a full operating system, they have less overhead and require less space than VMs. The basic idea of the container is not new; perhaps some may still remember the old Solaris machines? These sturdy aluminium parts? Containers and nodes were already known there, but it was not as advanced as today. Unlike virtual machines on a host platform, Docker operates one layer higher. There is only one host OS, whose kernel the applications in the container access. This makes container deployment extremely fast and easy. Containers in software development Software development benefits from efficient work with containers. A container is deployed within seconds, can be briefly tested and then removed again. Then the application code is adjusted and the container redeployed and tested. This always ensures versioning. Once a container has reliably worked with all components, it can be stored as functional and remain unchanged as a backup. This container can always be used as a base. What about security? The security of the best-known container virtualisation "Docker" is often criticised. But the same applies as in a classic installation: it always depends on the security of the host system. A fitting example is SELinux, which is often disabled because the administrative effort is immense. Although the security of a container environment is described as comparable to that of classic virtualisation, this should also be questioned. Precisely because Docker operates one layer higher, the resources are not as strictly separated. Keyword "buffer overflow", where I can access areas I should not be able to reach. With a classic hypervisor, virtualisation operates one layer lower, making this type of exploit impossible. Among other things, the motto is: the isolation, when multiple containers run on a common host, is only as good as the kernel’s ability to provide multi-tenant isolation between containers and the underlying host operating system. This includes, among other things, the Linux kernel namespaces, SELinux and other security features of the chosen Linux distribution and the security of the distribution itself. Ultimately, this means that a container can only be as secure as the kernel of the host it runs on. This does not mean, however, that the container is "always" as secure as the host underneath. Each container must be patched in case of a vulnerability; otherwise, the container remains vulnerable. Vulnerabilities such as Spectre or Meltdown can, in the worst case, also affect the entire system. The biggest concern for me currently is that we always run with only one kernel and are only separated from other systems by the various namespaces. If the kernel has a vulnerability, it can happen that the host system can be broken out of and code executed on the host system. A risk also arises if the host system is not configured correctly and – hypothetically speaking – the Docker API is publicly accessible. Who would do such a thing? … Something happened two years ago … Exactly that! It was the case in mid-2017, when an open port for the Docker API allowed an attacker to deploy a Docker image. This image contained a miner for the cryptocurrency Monero and mined the currency using the CPU power of others. Due to container isolation, it was not easily possible to access the host system, so it remained limited to Monero mining. Apart from the increased electricity bill, no damage was caused. However, it still leaves an uneasy feeling. The attack is described in more detail at this link if interested: https://kromtech.com/blog/security-center/cryptojacking-invades-cloud-how-modern-containerization-trend-is-exploited-by-attackers Container orchestration with Openshift Once several containers have accumulated in a system landscape, they must also be managed. The number can quickly reach the triple digits, making it increasingly difficult to keep track. Kubernetes is a suitable (open source!) project for this. Openshift is the appropriate product built on Kubernetes, developed by RedHat, for managing a container landscape. Unlike Kubernetes, it already offers many fully developed components such as continuous integration/continuous delivery or backup and security features. OpenShift was developed with the enterprise mindset and is therefore more restricted by default. For example, containers running as root cannot be deployed, and it only runs on RedHat/CentOS. Conclusion The whole story with containers is therefore already widespread depending on a company’s activity. Where RedHat is already used, at least a POC for Docker & Openshift is running. RedHat itself has already felt the spread of Openshift; the courses and certifications are exceptionally well attended. Although there was initially a hype around containers and Docker and one could fill a whole bullshit bingo card with the buzzwords around containers in some meetings, I see the technology as a positive development. Software development benefits enormously from the increased agility and can significantly increase efficiency in collaboration with methods like SCRUM. What do you think? Let me know what you think. "Docker is practical and can avoid a lot of unnecessary work, but convenience must not lead to careless behaviour." – Tim Berghoff, G DATA Security Evangelist Links At AVANTEC, we deal with container security as part of cloud security: www.avantec.ch/themen/cloud-security/ The article Who still needs VMs today? first appeared on Tec-Bite.