Hi Devs/All, Does any one have comments/objections for following interim solution? 1. Add a config option to enable/disable parameter encryption and set default value to disable 2. Encrypt parameters that were marked as hidden or encrypt all parameters
IMO, when a template author marks a parameter as hidden/secret, it seems incorrect to store that information in plain text. Thanks, Vijendar On 6/5/14 11:54 AM, "Vijendar Komalla" <vijendar.koma...@rackspace.com> wrote: >I am not sure when Barbican would be stable/ready. As an interim solution, >what do you guys think about having a config option to enable/disable >parameter encryption (along with my current implementation)? > > > >On 6/5/14 4:23 AM, "Steven Hardy" <sha...@redhat.com> wrote: > >>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 > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
