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" <[email protected]> wrote: >On Thu, Jun 05, 2014 at 12:17:07AM +0000, Randall Burt wrote: >> On Jun 4, 2014, at 7:05 PM, Clint Byrum <[email protected]> >> 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 >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
