Open Lennie opened 9 years ago
yasker
commented
9 years ago Thanks @Lennie . We were looking into various ways of encryption, includes dm-crypt provided by device mapper. Your way is more generic and easier to understand. We would looking into this.
Lennie
commented
9 years ago Well, you could combine the 2 ideas dm-crypt and the encrypted-with-public-key method.
If you use dm-crypt for normal operations to encrypt your volume data on the machine running Docker/convoy. To make sure when you stop using the machine your data can't be read from the disk.
If you can snapshot the encrypted data instead of the unencrypted data then you can still safe the encryption key on the backup location with the encrypted data.
Do you have some kind of meta-data or magic number on the backup location yet ? Because it looks like you might end up with different types of backups. ;-)
The real question is: where do you keep your encryption key for when the machine running Docker/convoy is rebooted (you'll need to supply an encryption key when you start up or you can't get access to your volumes).
My first thought would be to keep the key in HashiCorp Vault (stored in Consul) on an unencrypted volume.
And use a Vault app-id for every machine to bootstrap getting access to it's keys.
https://vaultproject.io/docs/auth/app-id.html https://news.ycombinator.com/item?id=9454041
That way when all machines at a availability zone (datacenters) have been shutdown, you only need to specify the unseal password of Vault ones and all machines can mount their volumes and start their containers.
Best is of course to have multiple availability zones (datacenters) and have each zone be able to bootstrap itself by connecting to at an other zone. That bootstrapping would be getting the unseal password for Vault of it's own location stored at a Vault at the other location. Again by using an app-id.
This is a feature request for encrypted backup.
When you encrypt/store at a service like s3 would be great if you could also encrypt the data before it's send to that service.
Here is my suggestion of how it should work: You generate a private/public keypair.
When doing the backup the only thing you give it is the public key. The host generates a 'encryption-key' used for encrypting the data and uploads a key-file. The keyfile is the encryption key but encrypted with the public key.
This means when you want to restore the data you need to specify the private key (encryption key).
The private key can be kept offline and the server encrypting the data doesn't need to have that key and a new encryption key can be generated any time you need a new key (you could even do that every time you upload new data and then removing then losing the encryption key when the process is stopped on the server doing the uploading).