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

Vijendar Komalla vijendar.komalla at RACKSPACE.COM
Thu Jun 5 16:54:58 UTC 2014

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
>> >>> for Heat parameters encryption blueprint
>> >>> 
>> >>> This quick and dirty implementation encrypts all the parameters 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'
>> >>> 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
>> >> is worth the giant pain it causes in debugging, except to say that
>> >> 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
>> >> 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
>> > 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
>> > 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
>> > up Barbican's in-instance tools to access the secrets value. But the
>> > idea is, let Heat worry about being high performing and
>> > 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
>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
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list