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" <abis...@redhat.com> wrote: > 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 >
__________________________________________________________________________ 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
