[Feature enhancement] Rockstor config backup encryption with passphrase

[MFlyer]

While producing documentation for a Watchguard firewall config backup/restore procedure I realized we miss any kind of security over Rockstor config backups

Reason pushing me to add this feature: Rockstor backup file can have sensible data like AD Credentials/Rockstor credentials

Mirko

[daniel-illi]

For me encryption of the backup files is not necessary as the files are created locally on the rockstor system. Only the root/admin user should have access to the backup files. If I want to download and archive a backup file, I can always encrypt the file myself.

So from my point of view this feature enhancement just increases the complexity of the backup functionality without real benefit.

An alternative to encryption could be an option to omit passwords and other sensible values from the backup file. On restore of a backup file a form could be presented to fill in the missing values.

But for me the functionality is good as it is, I would just add a notice/warning in the config backup documentation so the admin user is aware of the sensible data in a config backup file. Let the admin user decide himself how to best protect the data.

[Hooverdan96]

Two opinions on both ends of the spectrum. @phillxnet, @FroggyFlox if we consider the documentation route, we could close this and add it as an issue over in the docs repo.

[phillxnet]

@Hooverdan96 Thanks for attending to this issue, after so long. Much appreciated.

@FroggyFlox I've gone in @Hooverdan96 & @daniel-illi general direction re:

we could close this and add it as an issue over in the docs repo.

I'm not keen on encrypting the config back-up files myself: mainly on the grounds already indicated by @daniel-illi. If for example we implement an encryption mechanism using our new GNUPG root key, and folks have a system drive failure: we require them to have backed-up the auto created PGP key also. That's a tall order and any inclusion in download negates the added security anyway. Lets keep this simple as we have yet to 'attract' the size of development team required to support any more complexity that we already have. There there is always a loss to the use if things get too complicated.

I strongly prefer the doc route here, re sensitive configuration data contained in the associated files. We could further indicate the recent addition of our rpm enacted 'back-up' mechanism to further inform folks of where these files are copied during an rpm update.

Closing as
superseded by rockstor/rockstor-doc#465