The security of container vs virtualization

Editor's note: When it comes to the safety of containers, most people say it's not safe enough to give up the high performance and convenience it brings. The author of this article thinks that Docker has already provided a safe mode, and can be used with all Linux security schemes such as SELinux, as, but many people do not use it well. By comparing bare-metal, VMS and container to buildings, apartments and private rooms, the authors illustrate the problem. Of course, from another point of view, the author only considered the problem of single tenant, the situation of the multi-tenant, container security is still not enough.

Since last year, Linux containers have been at the forefront of technology hype, and various discussions about container safety are everywhere. In most of the published discussions, articles and blogs, the comparison with VMS is unavoidable, whether needed or not. The truth of the story is closer to "containers synch" and "VMs sometimes". Of course, there are also some users who start reassessing VMS after using Docker. In most cases, users are more biased towards performance than security--in a single tenant environment, avoiding the overhead of virtualization is certainly more desirable while using VM lifecycle management.

However, Docker is not an alternative but a complement to those solutions that rely on VMS for security.

In general, I prefer to compare bare-metal, VMS and container to buildings, apartments and private rooms. Linux containers can exist in VMS, and they can also be run directly on bare metal. There may be a few friends in real life who share an apartment, and they use their private rooms separately. But there is no doubt that this is not the same as having one's own apartment. If you want to share an apartment with a few friends, these people must be completely believable to you. Even so, this kind of security can only under certain conditions, and there is a limit.

My wife and I have been married for 12 years and have two children living with us. My wife and I live in a room, and the child lives in another room, and the third is my home Office. Putting children in a separate apartment doesn't make much sense, just as adding a openssh daemon to your own VM separates it from the application.

The children have their own private rooms, the future of which they will not stay in their parents ' beds, but the results are not satisfactory (if the 3-year-old daughter prepares her own apartment, will inevitably trigger a CPS application).

My Home Office is a forbidden area, as I have a custom firewall for this room, but my children will still come in, though not often. Even two-year-olds know that it's the father's space and respect the setting.

Containers, like private rooms, are invaluable in protecting privacy-for some reason, it is often necessary to mix multiple processes on the same host or VM. In a container environment, these processes have been isolated, and the security benefits of VMs have ceased to exist.

Loose isolation between such containers is not a bug, but a useful feature. While we assume that the processes running in the container are running on the same VM, it is good to implement strict, finer-grained access control between these processes.

In practice, even on a host running a single process, running a container can help protect your security. Who can guarantee that we won't run any common processes in the future? such as SYSLOGD, sshd and so on, which are usually run on the host. This is obviously not possible, and here we can assume that a VM will directly load a network server as its initialization process (PID 1).

So what could be the outcome of this process? What can it do? Can it send the original network frame? Can you elevate to root? If there is a setuid-root on the system, can it be elevated? Is it possible to do DAC rewriting, or to mount a filesystem, or do other things that only users with root privileges can do?

Sure, SELinux can be used to protect your process. But I believe many DevOps engineers will selinux disabled, and not many people rewrite their own selinux strategy, and even read SELinux strategies are very few people. Today, how much of the current Linux system uses SELinux as the default security policy for Docker? What are the obstacles here?

Yes, your application can discard these privileges, but you need the apps and developers to do the right thing. Of course, you can also choose to use a box, which is what Docker do.

In other words, even using a VM does not mean that you can run "Chmod-r 777/" on the host. Your system provides the security policies required by the process, but you may not be using them. Docker is the tool that provides this function, to the maximum extent of the Open box.

There is no doubt that the above problems are the key to the success of DevOps, both in terms of tools and culture. For many organizations, "DevOps" is usually "soft ops" (OPS on the software level). In the past, developers have more privileges to build and deploy applications, especially in a VM. This also leads to a separation of concerns, usually hard-ops (Hardware OPS) engineers are only responsible for the health of the hardware and network infrastructure. For those running AWS or GCE services, the hard-ops is outsourced to Google and AWS.

Hard-ops engineers, traditional system administrators, and security engineers, what they used to do is application deployment and help assess security issues. In some institutions, they may still be engaged in such a thing. But there is no doubt that the number of developers using the Self-provisioning-in-a-bubble model is increasing.

Unfortunately, there is not much progress on devsecops (or secdevops). At the same time, as DevOps to the "No Ops" tilt, people's security concerns may be waning.

Docker, as a devops tool, changes this situation by providing a security model for the user and making the model easier and more convenient to adjust. Docker will safely and effectively transfer them to the developer's hands to avoid shooting themselves in the foot.

With Docker, the user will get a rigorous set of features by default, and the ability to get this capability requires only adjusting some command-line parameters. At the same time, compare the previous reading of the Linux system call manual and then the fear of debugging, you only need to set a simple mark at runtime (perhaps in the future, this operation can be more easily done by Dockerfile).

Container security is certainly not superior to an application that uses Sys_setcap () as a good security guarantee, but it does not conflict with any other best practices for a container. It is not inconsistent with VMS, can be a good fit to run. At the same time, it does not conflict with SELinux or as, but also can be used in good collocation. In fact, after you use it, you'll find that all the security solutions that exist in Linux can be done through Docker.