Open Stack

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