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.batbo...@oracle.com
<mailto:ellen.batbo...@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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
