<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.</div><div><br></div><div>As for the way to convey this, I believe metadata attributes were designed to answer use-cases like this one. see <a href="https://docs.openstack.org/developer/murano/appdev-guide/murano_pl/metadata.html">https://docs.openstack.org/developer/murano/appdev-guide/murano_pl/metadata.html</a> for more info.<br><br><div>Regards, Kirill</div></div><div><br>Le 25 мая 2017 г. à 18:49, Paul Bourke <<a href="mailto:paul.bourke@oracle.com">paul.bourke@oracle.com</a>> a écrit :<br><br></div><blockquote type="cite"><div><span>Hi all,</span><br><span></span><br><span>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.</span><br><span></span><br><span>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].</span><br><span></span><br><span>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:</span><br><span></span><br><span>- name: appPassword</span><br><span> type: password</span><br><span> encrypt: true</span><br><span></span><br><span>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.</span><br><span></span><br><span>Regards,</span><br><span>-Paul.</span><br><span></span><br><span>[0] <a href="https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties">https://blueprints.launchpad.net/murano/+spec/allow-encrypting-of-muranopl-properties</a></span><br><span>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html">http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html</a></span><br><span>[2] <a href="https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py">https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/crypt.py</a></span><br><span></span><br><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>