Open Stack

I tend to agree with you Keith, securing Heat is Heat's problem.
Securing Nova is nova's problem. And I too would expect that those with
admin access to Heat, would not have admin access to Nova. That is why
we split these things up with API's.

I still prefer that users encrypt secrets on the client side, and store
said secrets in Barbican, passing only a temporary handle into templates
for consumption.

But until we have that, just encrypting hidden parameters would be simple
to do and I wouldn't even mind it being on by default in devstack because
only a small percentage of parameters are "hidden". My initial
reluctance to the plan was in encrypting everything, as that makes
verifying things a lot harder. But just encrypting the passwords.. I
think that's a decent plan.

A couple of ideas:

* Provide a utility to change the key (must update the entire database).
* Allow multiple decryption keys (to enable tool above to work
  slowly).

Excerpts from Keith Bray's message of 2014-06-11 22:29:13 -0700:
> 
> On 6/11/14 2:43 AM, "Steven Hardy" <shardy at redhat.com> wrote:
> 
> >>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?
> 
> Having one system (e.g. Nova) not as secure as it could be isn't a reason
> to not secure another system as best we can. For every attack vector you
> close, you have another one to chase. I'm concerned that the merit of the
> feature is being debated, so let me see if I can address that:
> 
> We want to use Heat to launch customer facing stacks.  In a UI, we would
> prompt customers for Template inputs, including for example: Desired
> Wordpress Admin Password, Desired MySQL password, etc. The UI then makes
> an API call to Heat to orchestrate instantiation of the stack.  With Heat
> as it is today, these customer specified credentials (as template
> parameters) would be stored in Heat's database in plain text. As a Heat
> Service Administrator, I do not need nor do I want the customer's
> Wordpress application password to be accessible to me.  The application
> belongs to the customer, not to the infrastructure provider.  Sure, I
> could blow the customer's entire instance away as the service provider.
> But, if I get fired or leave the company, I could no longer can blow away
> their instance... If I leave the company, however, I could have taken a
> copy of the Heat DB with me, or had looked that info up in the Heat DB
> before my exit, and I could then externally attack the customer's
> Wordpress instance.  It makes no sense for us to store user specified
> creds unencrypted unless we are administering the customer's Wordpress
> instance for them, which we are not.  We are administering the
> infrastructure only.  I realize the encryption key could also be stolen,
> but in a "production" system the encryption key access gets locked down to
> a VERY small set of folks and not all the people that administer Heat
> (that's part of good security practices and makes auditing of a leaked
> encryption key much easier).
>   
> >- 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.
> 
> Encrypting the data in the DB also helps in case if a leak of arbitrary DB
> data does surface in Heat.  We are not aware of any issues with Heat today
> that could leak that data... But, we never know what vulnerabilities will
> be introduced or discovered in the future.
> 
> 
> At Rackspace, individual cloud operators can not trivially access all
> customer cloud resources.  When operating a large cloud at scale, service
> administrator's operations and capabilities are limited to the systems
> they work on.  While I could impersonate a user via Heat and do lot's of
> bad things across many of their resources, each of the other systems
> (Nova, Databases, Auth, etc.) audit the who is doing what on behave of
> what customer, so I can't do something malicious to a customer's Nova
> instance without the Auth System Administrators ensuring that HR knows I
> would be the person to blame.  Similarly, a Nova system administrator
> can't delete a customer's Heat stack without our Heat administrators
> knowing who is to blame.  We have checks and balances across our systems
> and purposefully segment our possible attack vectors.
> 
> Leaving sensitive customer data unencrypted at rest provides many more
> options for that data to get in the wrong hands or be taken outside the
> company.  It is quick and easy to do a MySQL dump if the DB linux system
> is compromised, which has nothing to do with Heat having a vulnerability.
> 
> Our ask is to provide an optional way for the service operator to allow
> template authors to choose what data is sensitive, and if the data is
> marked sensitive, it gets encrypted by the Heat system as opposed to
> storing in plain txt.
> 
> I hope this helps.  Vijendar, feel free to take some of this write-up and
> include it in a gerit review of the feature blueprint.
> 
> Thanks,
> -Keith
>