[openstack-dev] [cinder][nova][castellan] Toward deprecating ConfKeyManager
duncan.thomas at gmail.com
Wed Oct 11 22:18:05 UTC 2017
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.
On 11 Oct 2017 9:50 pm, "Alan Bishop" <abishop at redhat.com> wrote:
> 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
> > project to encourage operators to use key management securely.
> > I'm all for consolidating code and providing good migration paths
> > ConfKeyManager to Castellan.
> > Can we create a new oslo project to facilitate this? Something like
> > oslo.fixed_key_manager.
> > I would rather keep a fixed_key implementation out of Castellan if
> > possible.
> Hi Dave,
> 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
> in barbican_key_manager.py.
> 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 ;-)
> > --Dave
> > 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):
> > pass
> > 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.
> > Regards,
> > Alan Bishop
> > ____________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev