On Thu, Jun 05, 2014 at 12:17:07AM +0000, Randall Burt wrote: > On Jun 4, 2014, at 7:05 PM, Clint Byrum <cl...@fewbar.com> > wrote: > > > Excerpts from Zane Bitter's message of 2014-06-04 16:19:05 -0700: > >> On 04/06/14 15:58, Vijendar Komalla wrote: > >>> Hi Devs, > >>> I have submitted an WIP review (https://review.openstack.org/#/c/97900/) > >>> for Heat parameters encryption blueprint > >>> https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters > >>> This quick and dirty implementation encrypts all the parameters on on > >>> Stack 'store' and decrypts on on Stack 'load'. > >>> Following are couple of improvements I am thinking about; > >>> 1. Instead of encrypting individual parameters, on Stack 'store' encrypt > >>> all the parameters together as a dictionary [something like > >>> crypt.encrypt(json.dumps(param_dictionary))] > >> > >> Yeah, definitely don't encrypt them individually. > >> > >>> 2. Just encrypt parameters that were marked as 'hidden', instead of > >>> encrypting all parameters > >>> > >>> I would like to hear your feedback/suggestions. > >> > >> Just as a heads-up, we will soon need to store the properties of > >> resources too, at which point parameters become the least of our > >> problems. (In fact, in theory we wouldn't even need to store > >> parameters... and probably by the time convergence is completely > >> implemented, we won't.) Which is to say that there's almost certainly no > >> point in discriminating between hidden and non-hidden parameters. > >> > >> I'll refrain from commenting on whether the extra security this affords > >> is worth the giant pain it causes in debugging, except to say that IMO > >> there should be a config option to disable the feature (and if it's > >> enabled by default, it should probably be disabled by default in e.g. > >> devstack). > > > > Storing secrets seems like a job for Barbican. That handles the giant > > pain problem because in devstack you can just tell Barbican to have an > > open read policy. > > > > I'd rather see good hooks for Barbican than blanket encryption. I've > > worked with a few things like this and they are despised and worked > > around universally because of the reason Zane has expressed concern about: > > debugging gets ridiculous. > > > > How about this: > > > > parameters: > > secrets: > > type: sensitive > > resources: > > sensitive_deployment: > > type: OS::Heat::StructuredDeployment > > properties: > > config: weverConfig > > server: myserver > > input_values: > > secret_handle: { get_param: secrets } > > > > The sensitive type would, on the client side, store the value in Barbican, > > never in Heat. Instead it would just pass in a handle which the user > > can then build policy around. Obviously this implies the user would set > > up Barbican's in-instance tools to access the secrets value. But the > > idea is, let Heat worry about being high performing and introspectable, > > and then let Barbican worry about sensitive things. > > While certainly ideal, it doesn't solve the current problem since we can't > yet guarantee Barbican will even be available in a given release of > OpenStack. In the meantime, Heat continues to store sensitive user > information unencrypted in its database. Once Barbican is integrated, I'd be > all for changing this implementation, but until then, we do need an interim > solution. Sure, debugging is a pain and as developers we can certainly > grumble, but leaking sensitive user information because we were too fussed to > protect data at rest seems worse IMO. Additionally, the solution as described > sounds like we're imposing a pretty awkward process on a user to save > ourselves from having to decrypt some data in the cases where we can't access > the stack information directly from the API or via debugging running Heat > code (where the data isn't encrypted anymore).
Under what circumstances are we "leaking sensitive user information"? Are you just trying to mitigate a potential attack vector, in the event of a bug which leaks data from the DB? If so, is the user-data encrypted in the nova DB? It seems to me that this will only be a worthwhile exercise if the sensitive stuff is encrypted everywhere, and many/most use-cases I can think of which require sensitive data involve that data ending up in nova user|meta-data? Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
