[openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager
abishop at redhat.com
Wed Oct 11 20:49:59 UTC 2017
On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan)
<dmccowan at cisco.com> wrote:
> Hi Alan--
> 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.
> I'm all for consolidating code and providing good migration paths from
> ConfKeyManager to Castellan.
> Can we create a new oslo project to facilitate this? Something like
> I would rather keep a fixed_key implementation out of Castellan if
While I totally take your point about keeping the "deficient" (I'm being
charitable) ConfKeyManager code out of Castellan, I view it as a short
term tactical move. Everyone is looking forward to deprecating the code.
The key (no pun intended) to getting there is providing a migration path
for users (there are significant ones) that have existing deployments
that use the fixed-key.
Because of the circumstances, I feel there would be resistance to the
idea of creating an entirely new oslo project that; a) consists of code
that everyone knows to be deficient, and b) will be deprecated soon.
I have another motive for temporarily moving the code into Castellan,
and it pertains to providing a migration path to Barbican. With everything
consolidated in Castellan, a wrapper class could provide a seamless way
of handling KeyManager.get() requests for the all-zeros fixed-key ID,
even when Barbican is the key manager. This would allow users to switch
to Barbican, and still have any get() requests for the legacy fixed-key
be resolved by the ConfKeyManager.
All of this could be implemented wholely within Castellan, and be totally
transparent to the the user, Nova, Cinder, and the Barbican implementation
As a final note, we could add all sorts of warnings any to code added
to Castellan, perhaps even name the file insecure_key_manager.py ;-)
> There is an ongoing effort to deprecate the ConfKeyManager, but care
> must be taken when migrating existing ConfKeyManager deployments to
> Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
> but the process of switching from one key manager to another will need
> to be done smoothly to ensure encrypted volumes continue to function
> during the migration period.
> One thing that will help the migration process is consolidating the
> two ConfKeyManager implementations (one in Cinder and one in Nova).
> The two are functionally identical, as dictated by the need to derive
> the exact same secret from the fixed_key. While it may seem counter-
> intuitive, adding a ConfKeyManager implementation to Castellan will
> facilitate the process of deprecating them in Cinder and Nova.
> To that end, I identified a series of small steps to get us there:
> 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
> so they are identical (right now their help texts are slightly
> different). This step avoids triggering a DuplicateOptError exception
> in the next step.
> 2) Add a ConfKeyManager implementation to Castellan. This essentially
> involves copying in one of the existing implementations (either Cinder's
> or Nova's).
> 3) Replace Cinder's and Nova's implementations with references to the
> one in Castellan. This can be done in a way that retains compatibility
> with the key_manager "backend" (was "api_class") config options
> currently used by Cinder and Nova. The code in
> cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
> will collapse down to this:
> from castellan.key_manager import conf_key_manager
> class ConfKeyManager(conf_key_manager.ConfKeyManager):
> Having a common ConfKeyManager implementation will make it much
> easier to support migrating things to Barbican, and that's an important
> step toward the goal of deprecating the ConfKeyManager entirely.
> Please let me know your thoughts, as I plan to begin proposing patches.
> Alan Bishop
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev