On 6/11/14 2:43 AM, "Steven Hardy" <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
