From 3581aba6ae4849e5168227bb06d6973ca62a6e39 Mon Sep 17 00:00:00 2001 From: Alan Bishop Date: Fri, 13 Oct 2017 10:49:03 -0400 Subject: [PATCH] Migrate ConfKeyManager's fixed-key to Barbican Implements: blueprint migrate-fixed-key-to-barbican Change-Id: I25f3c841d9f7a678dae649afc1fb2f6702c860ea --- .../queens/migrate-fixed-key-to-barbican.rst | 204 ++++++++++++++++++ 1 file changed, 204 insertions(+) create mode 100644 specs/queens/migrate-fixed-key-to-barbican.rst diff --git a/specs/queens/migrate-fixed-key-to-barbican.rst b/specs/queens/migrate-fixed-key-to-barbican.rst new file mode 100644 index 00000000..1177e14f --- /dev/null +++ b/specs/queens/migrate-fixed-key-to-barbican.rst @@ -0,0 +1,204 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +====================================================== +Migrate ConfKeyManager encryption key ID into Barbican +====================================================== + +https://blueprints.launchpad.net/cinder/+spec/migrate-fixed-key-to-barbican + +Support the transition to Barbican by migrating existing keys associated with +the ConfKeyManager into Barbican. The ConfKeyManager key uses a key ID of all +zeros that's associated with the fixed_key configuration parameter in the +key_manager section of cinder.conf. + + +Problem description +=================== + +The legacy ConfKeyManager is insecure, and the prefered encryption key manager +is Barbican. Using Barbican in new deployments is easy, but switching +deployments from the ConfKeyManager to Barbican is difficult when there are +existing volumes encrypted using the ConfKeyManager. + + +Use Cases +========= + +A user has a deployment based on the ConfKeyManager. They wish to to switch to +Barbican, but there are existing volumes encrypted using the ConfKeyManager. +These existing volumes must continue to function when Barbican is the key +manager. The user needs a migration path to Barbican that doesn't break +existing encrypted volumes. + + +Proposed change +=============== + +This spec proposes that all instances of the ConfKeyManager's key (identifed +by an all-zeros key ID) be replaced with an identical key stored in Barbican. +This is possible because Barbican provides a mechanism for storing existing +encryption keys. + +A cinder-volume thread will be used to search for encryption key ID instances +in the database that match the ConfKeyManager's all-zeros ID. This thread will +be refered to as the key migration thread. + +* The key migration thread will search the volume table for encryption_key_id + entries matching the all-zeros ConfKeyManager key ID. For each matching + entry in the volume table, a new Barbican key ID will be created with the + exact same secret derived from the fixed_key config value used by the + ConfKeyManager. The volume table is updated with the new Baribican key ID. + +* The thread will only migrate keys associated with volumes belonging to that + host. This will avoid contention when there are multiple cinder-volume hosts. + +* The key migration thread will also look for ConfKeyManager keys stored in + metadata tables. Where appropriate, these entries will be updated with the + Barbican key ID stored in the corresponding volume table. Otherwise, a new + Barbican key ID will be created. + +* The key migration thread will be spawned on start-up whenever both the + following conditions are true: + + 1. The ConfKeyManager's "fixed_key" is configured + 2. The key_manager's "backend" (was "api_class") is *not* the ConfKeyManager + +* The key migration thread will generate logs that indicate a key ID has + been migrated to Barbican. It will also generate a log that indicates the + thread has run to completion without finding any key IDs associated with + the ConfKeyManager. + +The user is responsible for deciding when to remove the fixed_key from the +deployment. It is recommended the user use the logs messages described above +to determine when the key migration process has completed. Once the user +removes the fixed_key from the configuration, the key migration thread will +not be spawned on startup. + +The key migration thread will work in conjunction with an enhancement to +Castellan and/or Barbican. During the migration process, cinder services may +still encounter the ConfKeyManager's key ID (all zeros) in the database. This +is not a valid Barbican key ID, and Barbican will throw an error if asked to +provide the key associated with that ID. The enhancement will essentially +intercept requests for the all-zeros key ID, and return the ConfKeyManager's +response. All of this would be totally transparent to the rest of the Cinder +code. In short, the all-zeros key ID will continue to work even with Barbican +as the designated key manager. + +Alternatives +------------ + +Instead of using a separate migration thread, each piece of code that fetches +and uses the encryption key ID could be responsible for migrating the key into +Barbican. However, there are multiple places where the code needs to handle +the key ID, and each instance would need to be updated to perform the +migration. This approach would involve significantly more code change, and +would require more long-term maintenance. + +We could also not migrate keys to Barbican at all, and simply allow the +Castellan-Barbican enhancement to handle requests for the all-zeros key ID. +However, this would require the user retain the fixed_key value in the +configuration, which essentially misses the point of migrating to Barbican. + + +Data model impact +----------------- + +None. Existing database entries that contain the ConfKeyManager's encryption +key ID will be updated with references to a Barbican key ID, but the database +structure will not change. + +REST API impact +--------------- + +None. + +Security impact +--------------- + +This change should be considered a security enhancement in that it facilitates +transitioning existing ConfKeyManager deployments to Barbican. + +Notifications impact +-------------------- + +None. + +Other end user impact +--------------------- + +None. + +Performance Impact +------------------ + +Minimal. The key migration thread will not be CPU intensive, and other cinder +operations will not need to block until the migration thread completes. + +Other deployer impact +--------------------- + +None. + +Developer impact +---------------- + +None. + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + Alan Bishop + +Work Items +---------- + +* Develop code framework for scanning tables for encryption_key_id that needs + to be migrated to Barbican +* Develop utility code for generating new Barbican key ID with ConfKeyManager's + secret +* Add/update unit tests +* Update documentation + + +Dependencies +============ + +Castellan and/or Barbican, will be enhanced to aid the migration process. The +enhancement will allow volumes encrypted with the ConfKeyManager's key ID to +function properly during the migration process. + + +Testing +======= + +- Add and update the unit tests. + + +Documentation Impact +==================== + +The documentation will be updated to state that volumes encrypted using the +ConfKeyManager will continue to function correctly after switching to +Barbican. The user needs to feel comfortable knowing the migration to Barbican +is seamless and automatic. + +The changes will explain the user is responsible for removing the +ConfKeyManager's fixed_key from the deployment, with the recommendation that +the decision to do so be guided by the log messages generated by the key +migration thread. Those message will indicate when keys are still being +migrated, and when the migration process has finished. + + +References +========== + +None.