Re: [openstack-dev] [murano][barbican] Encrypting sensitive properties

[Paul Bourke]

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 > 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano][barbican] Encrypting sensitive properties

[Kirill Zaitsev]

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  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev