<div dir="auto">I'm not sure there's a general agreement about removing the fixed key manager code in future. It serves several purposes, testing being the most significant one, though it also covers some people's usecase from a security PoV too where something better might not be worth the complexity trade off. If this work is a backdoor effort to remove the functionality, rather than purely a code cleanup effort then it should definitely be clearly presented as such.</div><div class="gmail_extra"><br><div class="gmail_quote">On 11 Oct 2017 9:50 pm, "Alan Bishop" <<a href="mailto:abishop@redhat.com">abishop@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan)<br>
<<a href="mailto:dmccowan@cisco.com">dmccowan@cisco.com</a>> wrote:<br>
> Hi Alan--<br>
>     Since a fixed-key implementation is not secure, I would prefer not<br>
> adding it to Castellan.  Our desire is that Castellan can be a best-practice<br>
> project to encourage operators to use key management securely.<br>
>     I'm all for consolidating code and providing good migration paths from<br>
> ConfKeyManager to Castellan.<br>
>     Can we create a new oslo project to facilitate this?  Something like<br>
> oslo.fixed_key_manager.<br>
>     I would rather keep a fixed_key implementation out of Castellan if<br>
> possible.<br>
<br>
Hi Dave,<br>
<br>
While I totally take your point about keeping the "deficient" (I'm being<br>
charitable) ConfKeyManager code out of Castellan, I view it as a short<br>
term tactical move. Everyone is looking forward to deprecating the code.<br>
The key (no pun intended) to getting there is providing a migration path<br>
for users (there are significant ones) that have existing deployments<br>
that use the fixed-key.<br>
<br>
Because of the circumstances, I feel there would be resistance to the<br>
idea of creating an entirely new oslo project that; a) consists of code<br>
that everyone knows to be deficient, and b) will be deprecated soon.<br>
<br>
I have another motive for temporarily moving the code into Castellan,<br>
and it pertains to providing a migration path to Barbican. With everything<br>
consolidated in Castellan, a wrapper class could provide a seamless way<br>
of handling KeyManager.get() requests for the all-zeros fixed-key ID,<br>
even when Barbican is the key manager. This would allow users to switch<br>
to Barbican, and still have any get() requests for the legacy fixed-key<br>
be resolved by the ConfKeyManager.<br>
<br>
All of this could be implemented wholely within Castellan, and be totally<br>
transparent to the the user, Nova, Cinder, and the Barbican implementation<br>
in barbican_key_manager.py.<br>
<br>
As a final note, we could add all sorts of warnings any to code added<br>
to Castellan, perhaps even name the file insecure_key_manager.py ;-)<br>
<br>
Alan<br>
<br>
<br>
> --Dave<br>
><br>
> There is an ongoing effort to deprecate the ConfKeyManager, but care<br>
> must be taken when migrating existing ConfKeyManager deployments to<br>
> Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,<br>
> but the process of switching from one key manager to another will need<br>
> to be done smoothly to ensure encrypted volumes continue to function<br>
> during the migration period.<br>
><br>
> One thing that will help the migration process is consolidating the<br>
> two ConfKeyManager implementations (one in Cinder and one in Nova).<br>
> The two are functionally identical, as dictated by the need to derive<br>
> the exact same secret from the fixed_key. While it may seem counter-<br>
> intuitive, adding a ConfKeyManager implementation to Castellan will<br>
> facilitate the process of deprecating them in Cinder and Nova.<br>
><br>
> To that end, I identified a series of small steps to get us there:<br>
><br>
> 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova<br>
> so they are identical (right now their help texts are slightly<br>
> different). This step avoids triggering a DuplicateOptError exception<br>
> in the next step.<br>
><br>
> 2) Add a ConfKeyManager implementation to Castellan. This essentially<br>
> involves copying in one of the existing implementations (either Cinder's<br>
> or Nova's).<br>
><br>
> 3) Replace Cinder's and Nova's implementations with references to the<br>
> one in Castellan. This can be done in a way that retains compatibility<br>
> with the key_manager "backend" (was "api_class") config options<br>
> currently used by Cinder and Nova. The code in<br>
> cinder/keymgr/conf_key_<wbr>manager.py and nova/keymgr/conf_key_manager.<wbr>py<br>
> will collapse down to this:<br>
><br>
>   from castellan.key_manager import conf_key_manager<br>
><br>
>   class ConfKeyManager(conf_key_<wbr>manager.ConfKeyManager):<br>
>       pass<br>
><br>
> Having a common ConfKeyManager implementation will make it much<br>
> easier to support migrating things to Barbican, and that's an important<br>
> step toward the goal of deprecating the ConfKeyManager entirely.<br>
><br>
> Please let me know your thoughts, as I plan to begin proposing patches.<br>
><br>
> Regards,<br>
><br>
> Alan Bishop<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div></div>