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" <[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
