Open Stack

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