Open Stack

Thanks for that Kirill. Optional sounds good. Right now I'm leaning 
towards encrypting the full object model in the database rather than 
selective attributes, I can't think of a reason not to do this and it 
makes things more transparent and straight forward for the user. I've 
added a spec for this at https://review.openstack.org/#/c/469467/ if you 
have a chance to review.

Regards,
-Paul

On 31/05/17 17:59, Kirill Zaitsev wrote:
> As long as this integration is optional (i.e. no barbican — no 
> encryption) It feels ok to me. We have a very similar integration with 
> congress, yet you can deploy murano with or without it.
> 
> As for the way to convey this, I believe metadata attributes were 
> designed to answer use-cases like this one. see 
> https://docs.openstack.org/developer/murano/appdev-guide/murano_pl/metadata.html for 
> more info.
> 
> Regards, Kirill
> 
> Le 25 мая 2017 г. à 18:49, Paul Bourke <paul.bourke at oracle.com 
> <mailto:paul.bourke at oracle.com>> a écrit :
> 
>> Hi all,
>>
>> I've been looking at a blueprint[0] logged for Murano which involves 
>> encrypting parts of the object model stored in the database that may 
>> contain passwords or sensitive information.
>>
>> I wanted to see if people had any thoughts or preferences on how this 
>> should be done. On the face of it, it seems Barbican is a good choice 
>> for solving this, and have read a lengthy discussion around this on 
>> the mailing list from earlier this year[1]. Overall the benefits of 
>> Barbican seem to be that we can handle the encryption and management 
>> of secrets in a common and standard way, and avoid having to implement 
>> and maintain this ourselves. The main drawback for Barbican seems to 
>> be that we impose another service dependency on the operator, though 
>> this complaint seems to be in some way appeased by Castellan, which 
>> offers alternative backends to just Barbican (though unsure right now 
>> what those are?). The alternative to integrating Barbican/Castellan is 
>> to use a more lightweight "roll your own" encryption such as what 
>> Glance is using[2].
>>
>> After we decide on how we want to implement the encryption there is 
>> also the question of how best to expose this feature to users. My 
>> current thought is that we can use Murano attributes, so application 
>> authors can do something like this:
>>
>> - name: appPassword
>>  type: password
>>  encrypt: true
>>
>> This would of course be transparent to the end user of the 
>> application. Any thoughts on both issues are very welcome, I hope to 
>> have a prototype in the next few days which may help solidify this also.
>>
>> Regards,
>> -Paul.
>>
>> [0] 
>> https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties
>> [1] 
>> http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
>> [2] 
>> https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org 
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>