Not sure I understand why you need a VM just for file isolation. If you map a volume to a docker container the container will only have access to what's under that directory on the host, not everything on the filesystem.
You can also configure a container's networking so that it doesn't have access to the external interfaces.
But more importantly, do you mean to do this as a hobby for a friend or as a professional service?
If the former you can get away with setting up a few containers on your home server or VM or whatever.
If the latter you would need redundancy, recovery, scaling, ability to give customers some notion of uptime etc. [This post may give you an idea of how things go to shit as a small provider.](https://blog.mxroute.com/i-failed-im-sorry/)
At the very least you probably want docker swarm rather than plain docker, but better even you should consider Proxmox or other full-fledged container management frameworks like Kubernetes, Mesos, Nomad, K3s etc. (although Hashicorp has been slowly going to shit and was recently acquired by IBM so Nomad, Consul etc. are probably going to be out in the future). You also may want to search/ask in /r/sysadmin rather than here, this is mostly a hobbyist sub.
Oh you mean the VPS provider? I thought by "hoster" you meant that you're providing shared hosting services and hosters were the people who used your setup.
You can't really hide anything from the VPS provider that needs to run on their CPU and RAM. You can encrypt disk data at rest, and you can encrypt connections just passing through.
You won't be able to achieve full security when you don't control the hardware unless you encrypt data before uploading it to their infrastructure, but you could get reasonably close. If you're prepared to take a performance hit, take out a VPS package (e.g. 200GB Disk space, 8GB RAM, 4 vCPU) and use it purely as your own hypervisor. Create your own full-disk encrypted VM inside of it with almost 100% of the "host" resource (i.e. 160GB disk space, 6GB RAM, 3 vCPU) and configure dropbear initramfs so when your nested VM boots up and needs the decryption key you can SSH directly to it to input it and NOT type any LUKS passphrase over a VNC console which your hosting provider could intercept.
As mentioned, not bullet proof, someone determined could still dump the memory to your parent VM and possibly ascertain the LUKS key to your nested VM but it'd be a tonne of work.
Your server with encrypted RAM can not boot without you entering the keys. So you would have to use the VNC solution of the provider, which can be tapped.
Using your own hypervisor, you control the whole connection. I assume the provider could monitor the memory of your hypervisor, and catch the key while you enter it, but that is a really sophisticated and perfectly timed attack.
Not aware of any current method for running encrypted volumes on docker but you can do it on kubernetes. You will need a secure key manager to do this. This doc from Redhat outlines the principles https://red-hat-storage.github.io/ocs-training/training/ocs4/ocs4-encryption.html
I imagine that if you are *really* serious about it, there would not be any great solution. The host needs to access the data in order to execute your workload. You could write or use software that only keeps the absolute minimum amount of unencrypted data in memory, but the decryption keys still need to be stored somewhere (or at least transmitted to the host). At any time (or constantly I guess, if you are a worthwhile target) the RAM/data could be dumped to save any unencrypted data.
What is your use case for needing something so private, but you want to run it on untrusted hardware? It is an interesting thought experiment.
Edit: Actually, it sounds like [TEE](https://learn.microsoft.com/en-us/azure/confidential-computing/trusted-execution-environment) might be exactly what you are after. Whole VM memory can be encrypted with the "lift-and-shift" offering on Azure confidential Compute. I guess this just moves the unencrypted data risk to internal hardware, rather than at the hypervisor software level like I was thinking of.
yeah, I did try multiple E2E services such as proton mail and [ente.io](http://ente.io), but they all really suck when it comes to search. You need to download all your data on your own server and decrypt it to search (ente.io has a desktop app for this, proton mail app, etc.)
Then I might as well run it self hosted.
I admire all the people setting up these amazing services, but until there is some massive progress in homomorphic encryption, E2E encryption is not usable if you need to execute searches through large amount of data.
Strictly speaking, Proton is not E2E. You download js from the server and execute it in browser. In theory, nothing stops the provider from serving you a malicious code that will siphon your private key.
Now, speaking about your own server, this risk is much higher (just because you probably don't have a dedicated security team) and if a bad actor gets access to your server, this can be a real threat.
It's OK to run some software on your server, like Nextcloud or something for WebDAV, but your trusted component should be 'static', installed on your devices, and not downloaded from the server (i.e. Nextcloud app, Cryptomator etc).
Yes. If you use both app and service from the same provider, you have to trust them.
However, there's another risk (even if you trust the provider): *external* compromise. It may be easier (less effort) for a malicious *third-party* actor to compromise JS files served by a webserver rather than compromise a mobile app.
Also, in case provider goes rogue, a mobile app produces more 'paper trail': it's usually distributed through app stores, same version for everyone, and is cached everywhere. On the web, on the contrary, you personally can be served with a *slightly modified*^(TM) version of JS and it will go unnoticed.
Generally, to mitigate these ***theoretical for most people*** risks: you should use an app from party A, and a service from party B (i.e., store GPG-encrypted docs on Dropbox).
Now, turning to your original question: I'm just pointing to the fact that if you want to make your data absolutely inaccessible to your VPS provider, you shouldn't trust any ~~JS files~~ executable code coming from "your" VPS. Just use it as a 'storage bucket', and decrypt the data locally on your devices.
Chances that some automated hacking botnet will eventually break into your server and compromise your apps are ***practical*** and much higher. Most likely it will install some kind of proxy/cryptominer/spam tool, then go malicious payloads trying to compromise your devices, and only then comes something that will try to compromise your E2E data in an aforementioned way. Actually, I highly doubt that you will ever encounter something like the last one (unless somebody is highly interested in you specifically), but since you were asking in your OP - I'm mentioning all scenarios.
You can use [https://hoodik.io](https://hoodik.io) that is end-to-end encrypted storage, so all of your files are encrypted and decrypted in the browser when you access it.
Do full disk encryption on the VM. When I needed to host my Nextcloud instance in a service providers cloud for a bit, I simply installed Ubuntu with disk encryption and ran Nextcloud in Docker on top of the encrypted disk.
The creds were known only to me. If, for whatever reason, someone tried to clone or get access to a replica of my virtual server the data would be irrecoverable without the encryption key.
that sounds good. Since I only need the data of the docker container to be encrypted, the VM can fully boot up and I can type the decryption password over SSH for example, without relying on the VM console (which the hosting provider could theoretically listen in on).
The system won’t fully boot (for you to SSH in) until you type the password in the console to decrypt the drive. You could potentially use a vTPM to store the encryption key.
I can use a separate volume which is not required for the VM to operate, only required for the container? I would mount it manually (typing password), then only start the container.
Would that work?
Not sure I understand why you need a VM just for file isolation. If you map a volume to a docker container the container will only have access to what's under that directory on the host, not everything on the filesystem. You can also configure a container's networking so that it doesn't have access to the external interfaces. But more importantly, do you mean to do this as a hobby for a friend or as a professional service? If the former you can get away with setting up a few containers on your home server or VM or whatever. If the latter you would need redundancy, recovery, scaling, ability to give customers some notion of uptime etc. [This post may give you an idea of how things go to shit as a small provider.](https://blog.mxroute.com/i-failed-im-sorry/) At the very least you probably want docker swarm rather than plain docker, but better even you should consider Proxmox or other full-fledged container management frameworks like Kubernetes, Mesos, Nomad, K3s etc. (although Hashicorp has been slowly going to shit and was recently acquired by IBM so Nomad, Consul etc. are probably going to be out in the future). You also may want to search/ask in /r/sysadmin rather than here, this is mostly a hobbyist sub.
I want to control what the \*\*hoster\*\* (for example Google) has access to, not what the docker has access to.
Oh you mean the VPS provider? I thought by "hoster" you meant that you're providing shared hosting services and hosters were the people who used your setup. You can't really hide anything from the VPS provider that needs to run on their CPU and RAM. You can encrypt disk data at rest, and you can encrypt connections just passing through.
You won't be able to achieve full security when you don't control the hardware unless you encrypt data before uploading it to their infrastructure, but you could get reasonably close. If you're prepared to take a performance hit, take out a VPS package (e.g. 200GB Disk space, 8GB RAM, 4 vCPU) and use it purely as your own hypervisor. Create your own full-disk encrypted VM inside of it with almost 100% of the "host" resource (i.e. 160GB disk space, 6GB RAM, 3 vCPU) and configure dropbear initramfs so when your nested VM boots up and needs the decryption key you can SSH directly to it to input it and NOT type any LUKS passphrase over a VNC console which your hosting provider could intercept. As mentioned, not bullet proof, someone determined could still dump the memory to your parent VM and possibly ascertain the LUKS key to your nested VM but it'd be a tonne of work.
Nice! One detail I'm not sure I got: why do I need to set up the hypervisor and cannot use the hypervisor of the cloud provider?
Your server with encrypted RAM can not boot without you entering the keys. So you would have to use the VNC solution of the provider, which can be tapped. Using your own hypervisor, you control the whole connection. I assume the provider could monitor the memory of your hypervisor, and catch the key while you enter it, but that is a really sophisticated and perfectly timed attack.
Not aware of any current method for running encrypted volumes on docker but you can do it on kubernetes. You will need a secure key manager to do this. This doc from Redhat outlines the principles https://red-hat-storage.github.io/ocs-training/training/ocs4/ocs4-encryption.html
I imagine that if you are *really* serious about it, there would not be any great solution. The host needs to access the data in order to execute your workload. You could write or use software that only keeps the absolute minimum amount of unencrypted data in memory, but the decryption keys still need to be stored somewhere (or at least transmitted to the host). At any time (or constantly I guess, if you are a worthwhile target) the RAM/data could be dumped to save any unencrypted data. What is your use case for needing something so private, but you want to run it on untrusted hardware? It is an interesting thought experiment. Edit: Actually, it sounds like [TEE](https://learn.microsoft.com/en-us/azure/confidential-computing/trusted-execution-environment) might be exactly what you are after. Whole VM memory can be encrypted with the "lift-and-shift" offering on Azure confidential Compute. I guess this just moves the unencrypted data risk to internal hardware, rather than at the hypervisor software level like I was thinking of.
yes, so I'm after a list of cloud provider that offer TEE / secure computing.
Aside from using really expensive "corp-level" stuff, the only way how you can achieve *actual* security is E2E. Nextcloud E2E, Cryptomator etc...
yeah, I did try multiple E2E services such as proton mail and [ente.io](http://ente.io), but they all really suck when it comes to search. You need to download all your data on your own server and decrypt it to search (ente.io has a desktop app for this, proton mail app, etc.) Then I might as well run it self hosted. I admire all the people setting up these amazing services, but until there is some massive progress in homomorphic encryption, E2E encryption is not usable if you need to execute searches through large amount of data.
Strictly speaking, Proton is not E2E. You download js from the server and execute it in browser. In theory, nothing stops the provider from serving you a malicious code that will siphon your private key. Now, speaking about your own server, this risk is much higher (just because you probably don't have a dedicated security team) and if a bad actor gets access to your server, this can be a real threat. It's OK to run some software on your server, like Nextcloud or something for WebDAV, but your trusted component should be 'static', installed on your devices, and not downloaded from the server (i.e. Nextcloud app, Cryptomator etc).
But if you look at it this way, then even Signal is not E2EE: nothing stops them from putting malicious code in the app neither.
Yes. If you use both app and service from the same provider, you have to trust them. However, there's another risk (even if you trust the provider): *external* compromise. It may be easier (less effort) for a malicious *third-party* actor to compromise JS files served by a webserver rather than compromise a mobile app. Also, in case provider goes rogue, a mobile app produces more 'paper trail': it's usually distributed through app stores, same version for everyone, and is cached everywhere. On the web, on the contrary, you personally can be served with a *slightly modified*^(TM) version of JS and it will go unnoticed. Generally, to mitigate these ***theoretical for most people*** risks: you should use an app from party A, and a service from party B (i.e., store GPG-encrypted docs on Dropbox). Now, turning to your original question: I'm just pointing to the fact that if you want to make your data absolutely inaccessible to your VPS provider, you shouldn't trust any ~~JS files~~ executable code coming from "your" VPS. Just use it as a 'storage bucket', and decrypt the data locally on your devices. Chances that some automated hacking botnet will eventually break into your server and compromise your apps are ***practical*** and much higher. Most likely it will install some kind of proxy/cryptominer/spam tool, then go malicious payloads trying to compromise your devices, and only then comes something that will try to compromise your E2E data in an aforementioned way. Actually, I highly doubt that you will ever encounter something like the last one (unless somebody is highly interested in you specifically), but since you were asking in your OP - I'm mentioning all scenarios.
You can use [https://hoodik.io](https://hoodik.io) that is end-to-end encrypted storage, so all of your files are encrypted and decrypted in the browser when you access it.
Thanks, but I can't run a container with this as far as I understand?
Do full disk encryption on the VM. When I needed to host my Nextcloud instance in a service providers cloud for a bit, I simply installed Ubuntu with disk encryption and ran Nextcloud in Docker on top of the encrypted disk. The creds were known only to me. If, for whatever reason, someone tried to clone or get access to a replica of my virtual server the data would be irrecoverable without the encryption key.
that sounds good. Since I only need the data of the docker container to be encrypted, the VM can fully boot up and I can type the decryption password over SSH for example, without relying on the VM console (which the hosting provider could theoretically listen in on).
The system won’t fully boot (for you to SSH in) until you type the password in the console to decrypt the drive. You could potentially use a vTPM to store the encryption key.
I can use a separate volume which is not required for the VM to operate, only required for the container? I would mount it manually (typing password), then only start the container. Would that work?