<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Alan--</div>
<div> Since a fixed-key implementation is not secure, I would prefer not adding it to Castellan. Our desire is that Castellan can be a best-practice project to encourage operators to use key management securely.</div>
<div> I'm all for consolidating code and providing good migration paths from ConfKeyManager to Castellan.</div>
<div> Can we create a new oslo project to facilitate this? Something like oslo.fixed_key_manager.</div>
<div> I would rather keep a fixed_key implementation out of Castellan if possible.</div>
<div>--Dave</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">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_manager.py and nova/keymgr/conf_key_manager.py<br>
will collapse down to this:<br>
<br>
from castellan.key_manager import conf_key_manager<br>
<br>
class ConfKeyManager(conf_key_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>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>