On Jun 4, 2014, at 7:30 PM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Randall Burt's message of 2014-06-04 17:17:07 -0700: >> 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). >> > > I have made that exact, reasoned argument before, and then later seen > giant swathes of code with things like > > if CONF.dont_encrypt: > ... > > The next thing that happens is one by one the production deployments > eventually end up with dont_encrypt because they can't debug anything > and they've all had a multi-hour downtime event while they dealt with > the encrypted database on several levels. > > I'm not coddling developers. I'm coddling operators. > > It's a different story if you only encrypt the sensitive "leaf" data, > like passwords, credit card numbers, or personally identifying data. The > operator can still have some clue what is going on if they can see the > non-sensitive data. > > The design I suggested above isn't really that awkward and will > be infinitely easier to understand for an operator than encrypting > everything.
So, you're simply advocating a more granular approach in which we only encrypt the values for inputs marked as hidden in the interim? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
