Open Stack

Hi Stan,

Thanks for your input on this.

I'm finding the problem with doing the encryption/decryption on the 
engine side only is that at this point it is too late - the object model 
has already been written into the database at the API layer. I can't 
think how we can change this without moving the data persist logic into 
the engine which would be quite a large change.

If we encrypt just user specified properties on session create, this may 
still work as you outline, but this leads to the problem of how to 
signal to the API which property values are to be encrypted, as metadata 
and contracts are again only parsed once the object model reaches the 
engine.

The only other things I can think to improve this would be to either use 
some form of caching such as memcached, or drop barbican and do some 
form of local crypto that avoids the round trip time to barbican. 
Neither seem ideal.

If you have any other ideas on this or if some of the assumptions I've 
made above wrt the engine are incorrect I'd appreciate your thoughts. 
The current approach where we encrypt the entire object model is 
available as a work in progress at https://review.openstack.org/#/c/471772/.

Thanks again,
-Paul

On 08/06/17 04:09, Stan Lagun wrote:
> Hi Ellen,
> 
> If you want my opinion I wouldn't recommend encrypt all the object model 
> as it can create a lot of issues like this. What I suggest instead is to 
> have special contract
> (say $.secureString()) which does the decryption/encryption right from 
> the engine while all calls to API would result in object model with some 
> encrypted fields. This way
> it would be possible to have this contract only for password and similar 
> properties. I'd also introduce encryptString()/decryptString() yaql 
> functions so that it would be possible
> to do it manually (for example, to store sensitive values in attributes, 
> which do not have contracts). But this can be done later. With contracts 
> encryption would be completely
> transparent to the rest of the code. Also, AFAIK MySQL enterprise has 
> encryption capabilities so that you can make DB with object model be 
> encrypted as well.
> 
> Regards,
> Stan
> 
> 
> On June 7, 2017 at 4:33:54 PM, Ellen Batbouta (ellen.batbouta at oracle.com 
> <mailto:ellen.batbouta at oracle.com>) wrote:
> 
>>
>> Hi Stan,
>>
>> Thanks for your last mail. Today, I am trying it out. It looks 
>> promising but haven't
>> gotten too far due to many interruptions.
>>
>> Onto another issue that Paul and I would like your opinion on. Paul is 
>> a co-worker of mine
>> and he is working on the murano blueprint,
>>
>> https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties 
>>
>>
>> and has posted a spec and code review. The reason we need to encrypt 
>> the object model (or at least some
>> of the attributes) is because our database application contains 
>> passwords and we cannot have these
>> passwords stored in the database in clear text. We must absolutely fix 
>> this and for the Pike release.
>>
>> A short summary (from Paul's code review) is:
>>
>> This commit introduces optional integration for Murano with Barbican 
>> (or any other key manager supported via Castellan). When enabled, all 
>> object model will first be encrypted into Barbican, and a 'secret key' 
>> will be written to the Murano database in it's place. The code is 
>> compatible with mixed (encrypted and unencrypted) databases, however, 
>> environments/sessions created when encrypt_data is on cannot be read 
>> if encrypt_data is subsequently turned off. The complete configuration 
>> required in the api murano.conf to enable this change is as follows:
>>
>> [murano]
>>
>> encrypt_data = True
>>
>> [barbican]
>> auth_endpoint = <keystone_uri>:<keystone_public_port>
>>
>> However, he is running into a performance problem. When listing the 
>> environments, the performance is
>> slow. The Murano code looks up the object model multiple times, which 
>> results in multiple calls to barbican.
>>
>> Is it possible to reduce the number of look ups for the object model? 
>> We will be investigating further.
>> Just wondering if you have an opinion on this.
>>
>> Thank you.
>>
>> Ellen.