On Tue, Jun 10, 2014 at 05:24:36PM +0000, Vijendar Komalla wrote: > Hi Devs/All, > Does any one have comments/objections for following interim solution? > 1. Add a config option to enable/disable parameter encryption and set > default value to disable > 2. Encrypt parameters that were marked as hidden or encrypt all parameters
Provided it's configurable, and probably defaulted to disabled (or at least disabled for devstack), that sounds OK to me. Obviously you'll have to figure out a way to do this in a backwards compatible way, so we handle existing non-encrypted DB content on upgrade. > IMO, when a template author marks a parameter as hidden/secret, it seems > incorrect to store that information in plain text. Well I'd still question why we're doing this, as my previous questions have not been answered: - AFAIK nova user-data is not encrypted, so surely you're just shifting the attack vector from one DB to another in nearly all cases? - Is there any known way for heat to "leak sensitive user data", other than a cloud operator with admin access to the DB stealing it? Surely cloud operators can trivially access all your resources anyway, including instances and the nova DB/API so they have this data anyway. IMO a bit more context explaining why would be helpful here. Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev