On Wed, Oct 11, 2017 at 1:17 PM, Dave McCowan (dmccowan) <dmcco...@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 > 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 ;-) Alan > --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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
