This post assumes you understand at least a little bit about Tincup. Briefly, Tincup provides Migrations as a Service, which allows enterprises to quickly, securely and with 100% fidelity clone running legacy servers to the cloud.
I designed the entire system. Every line of code, every graphic, every piece of copy - I did all of it. A critical requirement of the core service was that it needed to be super portable & be able to run almost anywhere. It also needed to have complete isolation between customers - any customer that used tincup to clone & store their servers had to have assurance that no other customer could access their images.
There had to be - by design - absolutely no way to leak images across customer logins. This was the genesis of the Tincup Vault, a customer-specific server instance that I would spin up at account creation and where that customer’s images would be stored.
Each customer would have her own Tincup Vault. There could be no leakage because a single customer would ever only have credentials on her own vault.
After having used AWS for years and not being thrilled with their API, I chose to implement this part of the system using DigitalOcean droplets. The DO API is very well-documented - both the organization as well as the use of examples is superior to AWS’ docs.
Without spending too much time on the workflow, I wrote this in bash to allow it to run on-prem if necessary. It’s super portable.
Chroot Jail & SSL Cert
You’ll note that I setup a jail for the user here. This is meant to prevent the customer from doing anything malicious from the vault. Only the stuff that is necessary to run the images is exposed to the jail.
I also setup a Let’s Encrypt certificate for the newly created domain and drop it into the vault server which will be running in the jail.
Anywhere you see ‘tincup…’ keep in mind that you’ll have to substitute in a path that makes sense in your implementation.
Here’s the highly cross-platform worker that I wrote that provisions new customer vaults: