[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
Support handling legacy all-zeros key ID
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
- Requests for the all-zeros key ID are handled by mimicing the
ConfKeyManager's response, which is a secret derived from the
- 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
All other KeyManager functions are not overridden, and will therefore be
handled directly by the real backend.