On 6/11/14 2:43 AM, "Steven Hardy" <sha...@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
>not been answered:
>- AFAIK nova user-data is not encrypted, so surely you're just shifting
>  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
>  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.


OpenStack-dev mailing list

Reply via email to