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.
SecurityImpact
Change-Id: Ia5316490201c33e23a4206838d5a4fb3dd00f527
Alan Bishop