How Virtuozzo Improves Docker Security for Service Providers

In the business division, Odin * recently announced support for Docker containers in Virtuozzo . This support is part of our strategy for implementing Virtuozzo as the infrastructure foundation for container virtualization platforms that are most suitable for work in environments where security and performance are key requirements.

It is worth noting that container projects such as Docker are sometimes called competitors to our own development. In fact, we work at different levels - Docker handles the management of applications, and we virtualize - including the one used in Docker. As a result, we are often linked by partnerships and collaboration. For example, together with Docker, we are developing system library projects that provide an interface to nuclear container components — this is the Libcontainer project started by Docker (together with Canonical, Google and RedHat), and ours is libct (together with LXC and Google).
Below is an example of the opportunities offered by collaborative technologies.

Docker support inside Virtuozzo adds “containers inside containers” to the core of Virtuozzo Linux, allowing you to create Docker containers inside Virtuozzo containers. This is how additional Docker namespaces appear inside the Virtuozzo virtual container. A similar scenario in hypervisors, such as KVM, works by default - since the kernel of the guest OS and the server core are separated there, the namespaces do not initially overlap. Now it is possible to do the same, adding the advantages of container virtualization, namely: fast launch, instant scaling, high elasticity and performance, equal to the performance of physical equipment.
For service providers and everyone else who needs multi-user mode, this also means that the Virtuozzo container can eliminate the Docker security issues without the performance loss that hypervisors provide. Docker's own delineation tools are very limited — for example, as noted in this article , having access to the Docker command line essentially means having root rights on the server.
Here is an example of a command to get root:

$ docker run -v $PWD:/stuff -t my-docker-image /bin/sh -c \ 'cp /bin/sh /stuff && chown root.root /stuff/sh && chmod a+s /stuff/sh' 

')
The result of its execution will be a copy of the shell in the current directory, with the suid bit set (which allows you to start the shell not on behalf of the current user, but on behalf of the owner of the file - in this case root).

Obviously, in such a configuration it is absolutely impossible to place on the same physical equipment a multitude of potentially hostile users using Docker. Since they will not be isolated from the point of view of physical resources, one user will be able to easily access the data of another and destroy them.

However, this problem is easily solved if Virtuozzo is running on the server. Creating containers Virtuozzo effectively shares server resources, making the server truly multi-user. Clients isolated from each other using Virtuozzo containers can use Docker in the same way as on a physical server, but with the addition of a new level of isolation and resource management (and therefore clients do not compete with each other for physical memory, disk space and processor). As a result, each has its own Docker containers, and the overall performance remains as if they were on a physical server.

Here's an example of why Docker is extremely convenient for users who need to run an application in the cloud. To begin with, let's try running the Docker application on our own laptop:

 $ docker run hello-world Unable to find image 'hello-world:latest' locally Pulling repository hello-world 91c95931e552: Pulling image (latest) from hello-world, endpoint: https://registr91c95931e552: Download complete a8219747be10: Download complete Status: Downloaded newer image for hello-world:latest Hello from Docker. This message shows that your installation appears to be working correctly. ... 

This can be done many times, correcting the code and eliminating the bugs (of course, when it is not hello world, but something more useful) - at some point we make a decision - everything is ready, it's time to release and implement.

Further we do this:

 $ export DOCKER_HOST=tcp://server:2376 DOCKER_TLS_VERIFY=1 

(It is assumed that TLS certificates are already decomposed and Docker is configured to trust them). Server is the address of the server where our application is running in the cloud. Running a fresh copy of the application on it now is already familiar.

 $ docker run hello-world 

Done - the application is running, and, importantly, it hit the server along with the environment and system libraries with which it was debugged and tested - that is, the probability of breaking it with the wrong settings is almost nil.
As a member of the unix docker group inside the Virtuozzo container, each user will still have the opportunity to increase access to root level - but this will be the root of the isolated container, not the root server. That is, the Virtuozzo container remains single-user — but there may already be many of them on the physical server with Docker.
This is just one of the first scenarios supported in Virtuozzo with application containers that we implemented and which we wanted to talk about. There will be others, so stay tuned.

* Under this new brand, a business division of Parallels company has been operating since March 2015, responsible for solutions for service providers

The video below shows clearly how to start Wordpress using Docker inside the Virtuozzo container: