Not intent to argue.
On the contrary, we are fully agree here and we cannot recommend giving
different users access to containers on one machine. You are exactly right that in multi-tenant environment additional VPS-based isolation is required. Alternative is to run Docker containers in Virtuozzo (as Virtuozzo containers). But we don't have any of these solutions at the moment, so unfortunately we cannot yet claim Docker support for multi-tenant environments, single-tenant only for now.
You don't need to introduce the whole solution. That would be very complex, and I'm sure that every vendor wants to use his existent virtualization solution, either its Xen, KVM, VmWare, others. Building support for all of them would require a significant control panel re-write just for virtualization, of course, that is of out the question as Plesk is not a VM control panel and never was.
So the simple, quick fix is let the extension connect more than one remote server vs the current one limitation. That way, providers using Plesk can use whatever virtual platform they want to host docker machines, and Plesk just uses those systems to provision the containers. Plesk only has to see and manage the end users containers, so where they are running doesn' matter as long as the OS is supported, the remote system can be virtual machine, or physical one.
Plesk customers still need to license the extension per Plesk server anyway, because if the client can manage his container from Plesk, that would only apply to dockers connected to that Plesk system. So in another Plesk server, if you want to offer docker, you would need the extension again. If you offer something based on Dockers on one server, you probably want it on all of them, same as the language case, consistency.
By letting your extension connect to multiple systems, you now have multi-tenant support out of the box. How the provider uses those Docker systems and what platform they prefer, and what other Docker tools they use on them to manage or complement the solution, that is another story, and probably each provider will do it differently. Nobody expects Plesk to do it everything.
From the user side, as the first step, implementing the option for users to provision particular docker templates (allowed on his plan), then letting them do basic functions like start, stop and see resources would be more than enough for most customers.
And this would also be secure, because all Dockers launched by that Plesk customer, is configured to only be provisioned on one particular remote Docker system. That way, if the customer causes significant problems regarding performance or security, he is isolated on that remote server. That means you still need one VM per customers, but at least Plesk can claim now multi-tenant support as well and the one VM per customer is true regardless if you are using Plesk or not. And it will be like this for some time.
Now the customer Dockers images are contained in that system. He can't overprovision resources and one compromised image, means only that customer is affected.
There is only 1 single tricky part there. How the extension or Plesk servers connect to those system. You can should assume this:
1. Customers A has Docker VM B configured.
2. Customers A launches Docker systems. One of that gets compromised.
3. Attacker escalates root privileges. He is now contained to that Docker VM B system. But we don't want the attacker getting now access to the Plesk server trough the extension which is connected to that system.
This is quite easy to fix. The extension should never store any logins or sensitive settings on the managed Docker system. All remote calls are done from the Plesk server to the remote system, not the other way around. This way, attackers can never use the extension to gain access to the Plesk server to which its connected or other Docker system that the extension is managing.
Facebook
Twitter
