[Openstack-security] [openstack/castellan] SecurityImpact review request change openstack%2Fcastellan~master~Ia5316490201c33e23a4206838d5a4fb3dd00f527
Hi, I'd like you to take a look at this patch for potential
Author: Alan Bishop <abishop at redhat.com>
Date: Tue Oct 24 14:53:36 2017 +0000
WIP: Support handling legacy all-zeros key ID
This WIP is meant to solicit community feedback. If the approach is deemed
acceptible, I'll update the patch with unit tests and a new commit message.
This patch addresses a specific use case, where a user has encrypted volumes
based on the fixed_key used by Cinder's and Nova's ConfKeyManager. The user
wishes to switch to Barbican, but existing volumes must continue to function
during the migration period.
The code conditionally adds a shim around the backend KeyManager when both
of these conditions are met:
1) The configuration contains a fixed_key value. This essentially signals
the ConfKeyManager has been in use at one time
2) The current backend is *not* the ConfKeyManager
When the shim is active, a MigrationKeyManager class is dynamically created
that extends the backend's KeyManager class. The MigrationKeyManager exists
solely to override two functions:
o The KeyManager.get() function detects requests for the secret associated
with the fixed_key, which is identified by an all-zeros key ID.
- Requests for the all-zeros key ID are handled by mimicing the
ConfKeyManager's response, which is a secret derived from the fixed_key.
- Requests for any other key ID are passed on to the real backend.
o The KeyManager.delete() function is similar:
- Requests to delete the all-zeros key ID are essentially ignored, just as
is done by the ConfKeyManager.
- Requests to delete any other key ID are passed on to the real backend.
All other KeyManager functions are not overridden, and will therefore be
handled directly by the real backend.