Open Stack

Excerpts from Randall Burt's message of 2014-06-04 17:17:07 -0700:
> 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).
> 

I have made that exact, reasoned argument before, and then later seen
giant swathes of code with things like

if CONF.dont_encrypt:
  ...

The next thing that happens is one by one the production deployments
eventually end up with dont_encrypt because they can't debug anything
and they've all had a multi-hour downtime event while they dealt with
the encrypted database on several levels.

I'm not coddling developers. I'm coddling operators.

It's a different story if you only encrypt the sensitive "leaf" data,
like passwords, credit card numbers, or personally identifying data. The
operator can still have some clue what is going on if they can see the
non-sensitive data.

The design I suggested above isn't really that awkward and will
be infinitely easier to understand for an operator than encrypting
everything.