[openstack-dev] [Heat]Heat template parameters encryption

Vijendar Komalla vijendar.komalla at RACKSPACE.COM
Tue Jun 10 17:24:36 UTC 2014


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.komalla at 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" <shardy at 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 <clint at 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 at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list