Open Stack

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.