Open Stack

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